REP Explained In Pictures

A few weeks back, I started explaining the Component Principles, guidelines for splitting up classes into deployable components. 

I wasn’t entirely happy with my explanations. I’ve decided to explore the Component Principles in pictures. We are visual creatures and tend to understand concepts represented in imagery more intuitively. 

Today I’ll use pictures to explain the Reuse/Release Equivalence Principle (REP).

The REP is one of three principles formalising how we should compose classes into components. As per Uncle Bob, the Reuse/Release Equivalence Principle states 

“The granule of reuse is the granule of release.” 

In other words, we ought to organise our components so that what is in them can be released and reused as a unit. 

OK, let’s check out those helpful images. 

Say we have a small program made up of classes. These classes follow the SOLID Principles—they are small, do one thing, are easy-to-understand and easy-to-change. It makes no sense to consider the Component Principles when the SOLID Principles are not adhered to.

Our application comprises distinct presentation logic classes, business logic classes, data access logic classes and common utility classes.   

So how could we deploy this system? 

The most straightforward, basic arrangement is the single executable file:

Does the single executable violate the REP?

Certainly not. Reuse and release are aligned—it’s released as a single executable file, and we can reuse it as such too: By deploying it onto several computers.

Another REP-consistent arrangement might be that of packaging up classes for each logic area:

Here we have another set of components that make sense. Each component can be independently deployed and reused. In particular, a common utility component could be useful in another program. 

We might learn more from REP violations. How about these components:

The utility component is still reusable since it contains useful and common utility classes. However, now it also includes a presentation logic class specific to this application! A utility component used on another project, yet including specific logic from this system, is likely to cause head-scratching by perplexed developers. 

Since we have split the presentation logic across the utility component, we must redeploy this utility component every time we make changes to the presentation logic class inside it. 

The other two components split the business logic between themselves. Whenever we make changes to business logic, we will need to redeploy both components. Suppose we invariably have to deploy two components together. In that case, they are tightly coupled and should probably be one component—or multiple components but arranged so that their internal classes make more sense. 

That was an overly simplified depiction of how the REP works, but I hope that the pictures provided some insights.