|All reviews||Principles of Package Design||Latest reviews||Best sellers ranking|
Principles of Package Design
Software development books
January 24, 2015
Week: Not ranked All time: 396
wagontrader.comThis book contains two major parts: class design based on the SOLID design principle and package design with an emphasis on cohesion and coupling.
While the book does provide a lot of useful information, it still requires some editing and presentation work, so I have to consider it as a work in progress instead of a book ready for publication.
To this reader, it felt like the author applied the principles for class and package design to writing this book, while great for package design, not so good for publication design in my opinion.
As I have previously stated, this book does have a lot of useful information for both class and package design.
The first part contains a basic introduction into class design and introduces us to the SOLID design principle.
Each of the following chapters discusses in detail what each part of the acronym SOLID stands for, providing examples that violate the principle and the steps necessary to make the example compliant.
S is for Single Responsibility Principle. Each class should be limited to one responsibility.
O is for Open/Closed Principle. A class should be open for extension and closed for modification.
L is for Liskov Substitution Principle. A sub-class should be a good replacement for its parent class.
I is for Interface Segregation Principle. A class should only contain a limited number of methods, defined by an interface, that are useful to the user of the interface.
D is for Dependency Inversion Principle. Depend on abstraction and not concretion.
In the second part we use the class design principles as a foundation to understanding how they relate to the 6 principles of package design.
As with the first part, the second part looks at package designs which violate the principle and what we can do to improve them so that they follow the principle.
The first three principles deal directly with package cohesion, how all the parts fit into a well designed package.
The first principle is the Release/Reuse Equivalence Principle. A package should contain as much code as can reasonably be reused by the client and maintained by the maintainer.
The second principle is the Common Reuse Principle. Keep your packages lean and on task by deciding which classes belong in which packages.
The third principle is the Common Closure Principle. Packages should contain classes that are affected by the same change, where classes not affected should be in a different package.
The final three principles, four through six, deal directly with coupling package dependencies.
The fourth principle is the Acrylic Dependencies Principle. All package dependencies should follow an acrylic directed graph and not cycle back to the root graph.
The fifth principle is the Stable Dependencies Principle. Choose dependencies on packages that are relatively stable.
The sixth principle is the Stable Abstractions Principle. Depend on abstract packages since they are more flexible and therefor more stable.
Designing well functioning packages requires a lot of forethought in how that package will be reused and updated, as well as considering the stability of packages you will depend upon.
It can be hard to accomplish, if it was easy everyone would do it, however applying some solid principles will make your task much easier and you will be much more likely to succeed.
There will always be a discussion on what the best approach is to releasing a complete set of classes, known as a package.
In this book, Principles of Package Design, you will learn about a workable approach starting with class design through release and into updating.
Therefore this book is recommended to all developers that are willing to learn how create well designed packages following well established principles.
No comments were submitted yet.