Package Principles

In this post I will be talking about the first 4 packages principles. In this context a package is a binary deliverable like a .jar file, or a dll as opposed to a namespace like a java package or a C++ namespace.

The 4 principles are:

• The Release Reuse Equivalency Principle
• The Common Closure Principle
• The Common Reuse Principle
• The Acyclic Dependencies Principle

The Release Reuse Equivalency Principle (REP)

The granule of reuse is the granule of release. Only components that are released through a tracking system can be effectively reused. This granule is the package. Reusing is not the same as copying code from somewhere else. If you copy code from someone or somewhere, you now own this code. If the original author finds a bug and fixes it, you have to do it too and find about it yourself.

When you reuse code, this means that you don’t have to look at the source code, you are not the author of this, but the customer. The author is responsible to maintain this code and fix anything that comes wrong with it and you should only have the task to update it, now this is reusing code.

The Common Closure Principle (CCP)

Classes that change together are packaged together. The classes in a package should be closed together against the same kinds of changes. A change that affects a package affects all the classes in that package. This comes in hand with OCP (Open Closed Principle). If you make a change it is better to change a certain package instead of changing all the packages or if you have all the classes in one single package then every time something change you will have to release the whole project.

The way to go here is to separate the classes in packages and in these packages put the classes that are bound together or that are likely to change together. This way, when you have to make a change it will occur only in one package and you will only need to release this certain package instead of the whole project.

The Common Reuse Principle (CRP) Acyclic

Classes that are used together are packaged together. The classes in a package are reused together. If you reuse one of the classes in a package, you reuse them all. This principle helps us decide which classes should be placed together into a package. Generally reusable classes collaborate with
other classes that are part of the reusable abstraction. The CRP states that these classes belong together in the same package.

This also helps developers when updates to a certain class or package arrive. The reason that they belong together is that when a developer decides to use a package, a dependency is created upon the whole package. From then on, whether the developer is using all the classes in the package or not, every time that package is released, the applications that use it must be revalidated and rereleased. If a package is being released because of changes to a class that I don’t care about, then I will not be very happy about having to revalidate my application. That’s why we want to make sure that when I depend upon a package, I depend upon every class in that package. Otherwise I will be revalidating and redistributing more than is necessary, and wasting lots of effort.

The Acyclic Dependencies Principle (ADP)

The dependency graph of packages must have no cycles. The dependency structure between packages must be a directed acyclic graph (DAG). That is, there must be no cycles in the dependency structure. It is pretty common in big teams that you left the office with your code working but the next day it doesn’t anymore because someone changed it. In small teams this is not much the case but with bigger one it is a pretty common scenario.

What we should do is separate the project in packages and assign small teams to each package. They will work on the package and release a new version for the whole team or company to use it. The other teams decide if they want to update the version or not in a certain time. This helps to focus on each task or feature and keep things in motion while working correctly at the same time and also removes more code to watch out for.