Packages : opposing forces of reusability and developability

Question

In choosing the classes to group together into packages, we must consider the opposing forces involved in reusability and developability. Balancing these forces with the needs of the application is nontrivial. Moreover, the balance is almost always dynamic. That is, the partitioning that is appropriate today might not be appropriate next year. Thus, the composition of the packages will likely jitter and evolve with time as the focus of the project changes from developability to reusability.

From : Agile software development : PPP

What are these opposing forces of reusability and developability?

Answer 1

It is about getting your dependencies straight. If you need some new functionality, you always have a choice to either keep it private to your problem domain code or put it in a package with general support stuff that is accessible to all. If you keep it private, it is yours. You can change, fix, extend it whenever you like and you can be sure you will not break any code you do not know about. That is very "developable" but it is not reusable. If you need the same thing in your next project, you will have to copy the code to the package you are working on at that moment. Or decide to move the code to the general support stuff package after all, which would be an example of the evolving composition the book talks about.

Once code is in a reusable library, you will have lost some developability. You will have to be very careful when changing anything about it because you may break a client. If there is an error in it, you may not even be able to fix it because client code may depend on it. It has become "legacy".

Sometimes being able to change/fix something in a central spot, knowing it will effect everything at once, can be great. And sometimes it can be a curse. Making the call on the way to go is the non-trivial task your book is talking about.