Perhaps the most important factor to be used in decomposing modules is to identify secrets that modules should hide from the rest of the system. Encapsulation is the way to write cleaner code with more flexibility.

I am writing this article to explain different ways of encapsulating the modules that you can use in writing new code or even refactoring.

ENCAPSULATE RECORD

This is why I often favour objects over records for mutable data. With objects, I can hide what is stored and provide methods for all three values. The user of the object doesn’t need to know or care what is stored and what is calculated. This encapsulation also helps with renaming: I can rename the field while providing methods for both the new and the old names, gradually updating callers until they are all done.

ENCAPSULATE COLLECTION

I like encapsulating any mutable data in my programs. This makes it easier to see when and how data structures are modified, which then makes it easier to change those data structures when I need to. Encapsulation is often encouraged, particularly by object-oriented developers, but a common mistake occurs when working with collections. Access to a collection variable may be encapsulated, but if the getter returns the collection itself, then that collection’s membership can be altered without the enclosing class being able to intervene.

REPLACE PRIMITIVE WITH OBJECT

Often, in the early stages of development, you make decisions about representing simple facts as simple data items, such as numbers or strings. As development proceeds, those simple items aren’t so simple anymore. A telephone number may be represented as a string for a while, but later it will need special behavior for formatting, extracting the area code, and the like. This kind of logic can quickly end up being duplicated around the code base, increasing the effort whenever it needs to be used.

REPLACE TEMP WITH QUERY

One use of temporary variables is to capture the value of some code in order to refer to it later in a function. Using a temp allows me to refer to the value while explaining its meaning and avoiding repeating the code that calculates it. But while using a variable is handy, it can often be worthwhile to go a step further and use a function instead.

EXTRACT CLASS

You’ve probably read guidelines that a class should be a crisp abstraction, only handle a few clear responsibilities, and so on. In practice, classes grow. You add some operations here, a bit of data there. You add responsibility to a class feeling that it’s not worth a separate class — but as that responsibility grows and breeds, the class becomes too complicated. Soon, your class is as crisp as a microwaved duck.

INLINE CLASS

I use Inline Class if a class is no longer pulling its weight and shouldn’t be around anymore. Often, this is the result of refactoring that moves other responsibilities out of the class so it is little left. At that point, I fold the class into another — one that makes the most use of the runt class.

HIDE DELEGATE

One of the keys — if not the key — to good modular design is encapsulation. Encapsulation means that modules need to know less about other parts of the system. Then, when things change, fewer modules need to be told about the change — which makes the change easier to make.

REMOVE MIDDLE MAN

I talked about the advantages of encapsulating the use of a delegated object. There is a price for this. Every time the client wants to use a new feature of the delegate, I have to add a simple delegating method to the server. After adding features for a while, I get irritated with all this forwarding. The server class is just a middle man, and perhaps it’s time for the client to call the delegate directly.

SUBSTITUTE ALGORITHM

Refactoring can break down something complex into simpler pieces, but sometimes I just reach the point at which I have to remove the whole algorithm and replace it with something simpler.

To Conclude

Encapsulation is part of writing clean code, you will have the control of your data and how they behave in your app, it doesn’t matter you are using Classes or Functions to write them down, the important part is to develop it using these methods.

Further down the line, you will need to go to refactor and review your code, use these methods to make the code more understandable and flexible for future changes.

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. — Martin Golding

Enjoyed the article? Follow me!

Have an opinion or comment? Type it!