CCP Explained In Pictures

Previously we delved into the Common Closure Principle (CCP) and how it helps us group classes into components. Components are the unit of deployment, often binary files but not always (e.g. DLL, JAR, GEM, JS , etc.)

Here is my attempt at explaining the CCP, one of the Component Principles, in pictures. I believe that explaining the Component Principles with images will be insightful. The last time when we touched on the Component Principles, I depicted the REP in pictures. Today I will do the same for the CCP.

Refreshing our minds, the definition for the Common Closure Principle is: 

Gather together into components those classes that change for the same reasons and at the same times. Separate into different components those classes that change at different times and for different reasons.

OK, let’s get started.

Say you are the programmer of a small desktop application. Initially, the program is tiny, and it seems reasonable to deploy it as a single executable. There will be no objections to that.

Over time, product owners are requesting you implement additional features. You implement these, and in doing so, the codebase for the desktop application grows. You are a decent developer and follow the SOLID Principle when designing your classes. You find that your classes divide into three categories: Presentation Logic (PL), Business Logic (BL) and Data Access Logic (DAL). There are also a collection of utility classes that perform common functions for the other categories. The utility classes you have created are so useful that other developers in your organisation would like to use them. In turn, they have utility code that would be useful for you to have in the desktop application codebase.   

Inclusion of the external utility code will mean that the utility classes will change for a different reason than the application-specific code in the PL, BL and DAL. In this instance, the CCP encourages us to extract the utility classes into a separate component. 

As time goes on, users are requesting a web interface for the application. Fair enough. How would you package up the application into components for deployment given this change to the presentation logic? 

If classes A & B are web-specific, while classes C, D, E & F contain desktop presentation logic, as shown in the image, then how would you divide up these classes into components? Remember, this division should

1. make sense, and
2. should separate classes that change for different reasons.

What is your answer? Please send me your ideas. I am curious as to how you would aggregate the classes into cohesive components.

I’ll reveal the answer tomorrow.