Design of Package Principle
Designing with Packages
How to design package?
What is design package principles? which are they?
Let’s Start…
Granularity:
(granule means small piece)
Basically, it used for large application.It divide large application into small pieces/parts.
Packages:
Package is used as containers for a group of classes. By grouping classes into packages we can design the highest level of abstraction.The main goal is that, partition the classes in your application according to some criteria, and then allocate those partition to package.
But it creates large number of questions.
- What are the best partitioning criteria?
- What are the relationships that exist between packages, and what design principles govern their use?
- Should packages be designed before classes (Top down)? Or should classes be designed before packages (Bottom up)?
- How are packages physically represented? In C++? In the development environment?
- Once created, to what purpose will we put these packages?
Flow of Package:
Project->Module->Package->Classes->Methods.
The Reuse/Release Equivalence Principle (REP) states that:
The granule of reuse is the granule of release. Only components that are released through a tracking system can be effectively reused. The granule is the package.
— The “Granularity” paper by Bob Martin (Uncle Bob)
It’s essentially saying that whatever can be released together can be packed together. The consumer of the package doesn’t need to care about related files elsewhere. Everything inside the package should be related enough to be able to be consumed separately from the rest of the system.
Despite what it looks like, REP is not applicable only to systems that are intended to be released to the public.
In the Customer Service application, there’s only a single team responsible for maintaining every JavaScript file, CSS file, and tests. However, if you separate the pieces that could be released, then you can group the base-appin a separate package and the tests with each of their related files, not in a separate test directory.
REP makes the distribution of responsibilities and scaling much easier.
Besides, you can publish the whole directory as an npm package if someday you want to make it available to the public.
It makes sense to pack together whatever can be released together.
If you look carefully, there’s a pattern here.
If you organize your directories by feature, instead of by language or technology, and respect the package cohesion principles, you’ll be able to understand what can be reused (CRP), what can be changed (CCP) and what can be released separately as necessary (REP).
That allows the File System to be more comprehensible.
The Common-Reuse Principle helps you identify how files are reused together.
The Common Closure Principle helps you identify how files are enclosed together.
The Reuse/Release Equivalence Principle helps you to identify how files are grouped by the possibility of being released.
Thanks for reading,
Vaibhav Bhagare
Full Stack developer (VarStreet Software)
