In plumbing the concept of coupling is profoundly important in cases where two different sizes pipes must be joined or there needs to be the ability to break the joint later to do something with both ends free.
In programming the concept of coupling is more strict. Close coupling is mostly bad; because when we have to change something, we wind up having to change way more than just the thing we wanted to focus. All changes in programming open the possibility for a bug.
Have you seen this?
- This original design called for four components working together to get three separate back-end end points to persist the data.
- Each component was developed to "follow Single Responsibility", only it knew about validation and only it showed the Save button when things were valid.
- The fourth component, a Buttons component had Edit, Save, Delete icons, that all fired a clicked event when pressed. The event also sent the row of data when used in a grid. Their visible states were controlled by the consumer.
Layout Changes Arrive
- The product owner wanted changes to the flow and layout.
- The new work flow was that the save buttons had to be moved from each component to a more global parent container. The save button to show in one location to save all three component changes.
Observations
85% of the changes were merely moving the components around into the layout desired, but the state of each of the components had to change due to the flow changes.
- Component A was developed to handle editing existing records as well as handling new records. But now, in the new main screen the change was to only handle new records, with pre-filled fields and rapid fire data entry.
- This same new requirement was true for the other two components.
The Only Challenges
The only challenges to show up was the GUI level state changes that were done on the code side.
- After Component A was filled in, the Save button would only appear when all fields were valid.
- Component B would only show after Component A was Saved.
- Finally after all components were filled in the application would navigate to the URL with the proper ID to display the result.
Those were the only changes required to be changed.
Fine Tune Responsibilities
Could the changes have been more simple?
- No component should have a responsibility to navigate solely based on a state change. The function should be contained in it's parent component container. This is a state change to another component within the current component. It is what is known as close coupling.
- Any button components click actions should most likely be contained in the parent container. Why? It allows for rapid change of button click logic in parent container instead of each child container.
- Think of a main container component as a pseudo controller which handles the work flow of all children. Each child then only handles it's very specific state and flow which is more closely aligned with a pure View component. It displays one or a single set of data and only focuses on that data. Absolutely no workflow is contained here which specifies a change to another component.
Result
- When the workflow and presentation specs. change, which they will. The changes become absolutely simple to do, and most important are done in record time.
Summary
No matter how hard we try to follow the all important Single Responsibility principal we seem to be more than able to tie in close coupling in some manner. The less we Close Couple the easier a refactor will become. Follow the fine tuning guidelines above and we are all set to refactor with almost zero impact.
JWP2020
Top comments (0)