Design Principle: Encapsulate what changes


Encapsulate or isolate the parts of your system that change more often.

We can accomplish isolation in many different ways.  For example, we can simply separate out the parts of the code (or objects) that are likely to change into separate classes.

Another option that comes to mind is configuration files (or any type of external configuration).  These can include data (like a copyright notice) that might change depending on the deployment, as well as feature switches, or information on which style of a class to load.


Shouldn’t I keep the behaviors of an object together in one class, rather than separating it out?

Yes.  However, isolating the parts that change doesn’t need to mean that your object doesn’t define what behaviors it has.

We use helper methods all of the time.  Sometimes it is to perform a calculation that we need to perform in many different places.  When we use a helper class to do some of this work, we will define a method on our object of interest, and have it simply call through to our helper.

For Example:

public class InterestingObject {
   private HelperObject helper;
   public InterestingObject(HelperObject helper) {
      this.helper = helper;

   public void interestingFunctionality() {

public class HelperObject {
   public void interestingFunctionality() {
      // some interesting functionality here

When working with our InterestingObject, we now know that it has interestingFunctionality.  When working with that object, we don’t need to care that there is a helper object that is implements that functionality.

Why does it matter if I change some parts of a class more often than other parts?

First of all, making modifications to a class violates the open/closed principle which states that we should have our classes open to extension but closed to modification.  Granted, it is not always possible to follow this principle.

Imagine you have a class that has behaviors.  In that class, you will likely have some instance variables that you share in several methods.  Now, imagine that you need to change the data structure for one of those variables because you need it in a more convenient form for a new calculation.  In order to switch that data structure, you will need to touch all of the methods that use that data.  If, however, that method lived in a different object it would be free to use a new data structure to do the computation, as long as the API remained the same and it could still return the same type of object/data structure.

What I am getting at with all of those words is that methods inside a class can often be tightly coupled with one another, and that is ok.  However, when you need to touch one, you often have to touch others.  If you have those methods in separate classes, you can often get away with making a change just to the methods in question without having to touch the calling code.

What is all of this work really buying me?

Ideally this is buying you a safety net.  It is allowing you to ensure that the changes you make are only going to impact a small piece and only the piece that you intend.

If you have pulled out some things into a configuration file or table, you can often make changes to your application without even having to rebuild it.  Just make a change to the configuration and restart and viola!