Last month, I discussed some of the package design principles based on reuse and granularity of different classes that reside in one or more packages. The main point of the discussion was that the decision of placing different classes in same or different packages not only depends on the relationship of those classes but also on the change-impact relationship between those classes.
Continuing the discussion, in this article we will see more on the change impact relationship and how to take them into account when designing the package relationship. The two main principles governing this change-impact relationship between different packages are:
- Stable Dependencies Principle (SDP)
- Stable Abstraction Principle (SAP)
The classic definition of stability is “difficult to move or change”. Although stability in your career may be a good thing, stability in package design is not. This is because a stable package, according to the definition, is difficult to change. Why is it bad if we cannot easily change a package? Because a change in any package might impact or break so many other packages that are package dependent on upon it.
In this case, any change in package “gui” is likely to impact package “trader” and “registration” packages and similarly any other package that depends on “gui” package. This makes the “gui” package hard to change. In this scenario, the “gui” package is called “stable”.
If you are a good application programmer, at this point, you are ready to challenge me with this example. You will argue that “Aha!” if the “trader” and “registration” packages only use some abstract classes or interfaces from the “gui” package then they are not tightly coupled with the implementation and we can always change the implementations without breaking any of the clients.
Precisely that is the point. Congratulations, you have attained this knowledge through your years of experience. For readers, who still want to know how we can avoid such syndromes of stability, read on to the next sections to get an answer.