Noback - Principles of Package Design Creating Reusable Software Components

This book assumes you are a developer writing object oriented code every day. Asyou design new classes, you constantly ask yourself (or your co-worker): doesthis method belong here? Is it okay for this class to know about ? Do I haveto define an interface for this class? Is it important to the other class that Ireturn an array? Should I return null or false?

While you are working on a class, there are many design decisions that you haveto make. Luckily there are also many wise people who have written about classdesign, whose ideas can help you make those decisions. Think about the SOLIDprinciples, the Law of Demeter, design patterns, concepts like encapsulation,data hiding, inheritance, composition. If you like to read about these subjects,you will know much about them already. But if you dont then you may still applymany of these principles just because you have some kind of programmersintuition for them.

So you know your way around classes. The classes you produce make sense: theycontain what you would expect them to contain, no more, no less. You can look atthe code of a class and see what it is supposed to do. But now some of thosewell-designed classes start to cluster together. They form little aggregates ofcode that cover the same subject, do something in a similar way, or are coupledto the same third-party code. They belong together, so you put them in the samedirectory, or in the same namespace. In other words you are creating packages*of them.

And just like you are very conscious about the way you design your classes, youimmediately start asking yourself some questions about the design of thepackages you create: can I put this class in the same package, or does itdeserve a new package? Is this package too big and should it be split? Is itokay if package A depends on package B?

Unfortunately, many developers dont have definitive answers for thesequestions. They all use different rules when it comes to package design. Thoserules are the result of discussions on GitHub, or worse: they are based on gutfeelings of the lead developers of well-known open source projects. But guessinghow to do package design is not necessary at all. We dont have to inventpackage design principles ourselves again and again. We can stand on theshoulders of giants here.

One of those giants is Robert C. Martin, a person I very much admire because ofthe clarity and strength with which he speaks about the principles that shouldgovern your work as a software developer, both with regard to the quality ofyour code,as well as the quality of you as a human beingwho creates software.

Robert wrote about package (or component) design principles on severaloccasions. I first learned about these principles when reading the articlesavailable for download atbutunclebob.com.Then I watched some of his videos about component design oncleancoders.com in which he explained the sameprinciples again, but in a more urgent manner.

These package design principles are actually not difficult to understand (infact, they are much more straight-forward than the SOLID principles of classdesign). They provide an answer to the following questions:

• Which classes belong inside a package and which dont?
• Which packages are safe to depend on and which arent?
• What can I do for my users to enhance the usability of a package?
• What can I do for myself to keep a package maintainable?

The discovery that there exist such clear answers to these questions has led meto undertake this effort: to learn more about these package design principles asexplained by Robert Martin, then to explain and discuss them in a broader way.

I think that to learn about these package design principles will be of great useto you. If you have never created a package before you will know from the startwhich principles should govern your package design decisions. And if you havealready created a few, or even many packages, you will be able to use the designprinciples to fix design issues in existing packages and make your next packageeven better.