Table of Contents
In this article I’d like to open your eyes on code encapsulation and hopefully you will enjoy the 5 tricks I will give you when it comes to hiding your code.
A few years ago, when I was still a college student during my senior year, I had one of the most thrilling and eye-opening experiences at my first ever real job as an intern in the software department in a R&D company of a chemical sector.
The company, with a battery of patents in the back pocket, would design and manufacture complex equipment for chemical analysis. Equipment with a price tag of a Ferrari, yet only a two-digit number of them shipped every year. Because of its exhaustive testing and flexibility to meet final customer specification, and the need of a manual build for most of the parts.
And there I was held in a meeting, because of a breakdown of one of the equipments, with pictures of the internal parts sent by the customer, documentation and reports on that particular unit, and the readings of the last weeks of all the sensors the machine had. A protocol meeting, before sending the repair team. It wasn’t my first meeting, yet this was different, as the founder of the company was presiding it. One of the brightest persons I’ve ever met.
After a long discussion, in which all sort of suppositions were made, and every pixel of each photograph checked, the word finally was for the boss, that barely spoke during the whole thing. The room went quiet, and all gazes pointed to him. Completely silent, with his arms crossed, he slowly leant back in his chair, and after a pause, said:
“This is not what our customer wants. The customer wants to open the side cover, check a few lights, find the broken part, remove it, order a new one, install it back and make it work again. It needs to be more modular.”
That simple sentence gave me a lot to think of. That is the behaviour we expect of more and more things that surround us. Think of your computer per instance, and how easy it is to upgrade it. Probably soon enough same will happen with smartphones. And this happens not only with your hardware, but also with your code. With a good code encapsulation, with classes of high cohesion between data and behaviour, it’s easier to read and extend.
Probably most of you have seen some old spaghetti code such as an endless PHP file that prints html and JavaScript, or some more modern one using a MVC framework, like Laravel for example, with controllers of thousands of lines and endless functions. To maintain such code can be a real nightmare. But how to avoid falling in these situations? My advice is to always try to hide your code as much as you can. Hide code details and internal complexity. Make it modular. Convert it to separate black boxes, each one with a clear purpose. It will make it easier to substitute one module by another, and build new functionality re-using existing components. But how exactly?
5 tricks for code encapsulation
1- Hide class attributes, make them private.
Use a well-defined public interface instead. If others are aware of the implementation details of your class, and need to access your attributes, then there is logic that should’ve been encapsulated in your class spread across only-god-knows where. Any change in that class requires to review all it’s uses.
Therefore, instead of:
if(user.admin || user.moderator || user.editor){
…
}
How about:
if(user.canEdit()){
…
}
2- Hide code details inside a new function.
Have a piece of code that repeats in multiple places? Hide code details inside a new function. Use the function instead. With code encapsulation, you keep your code DRY. It will be easy to reuse later, and the refactor and maintenance will be easier.
3- Hide the state.
Don’t use global variables, as it will break encapsulation and make the sections that use them dependent, as they would rely on the state of those variables.
4- Break them into smaller sections.
Large methods with nested sections and comments? Break them into smaller ones, extract code and hide your code in private methods. Normally a comment in your code would be a good name for a private function. Reviewing a function of 500 lines can make a developer cry. Reviewing a function that calls 5 small functions with self-describing contracts, is more pleasant.
5- Give your methods only one job.
If a method has a single responsibility, it will keep it short and focused on a single task, and the hidden code it contains behind the interface of the class. If you can’t give only one responsibility to a function, then the class has low cohesion and it should be separated into two different ones.
These simple tricks will help you have a more flexible code. In other words, always keep the cohesion high, and the coupling low. The first one will assure that the data and behaviour are well placed in a class, and the methods perform all the logic using only and most of the data inside the class. The second will ensure that the interdependence of the modules won’t be a problem when modifying or reusing code.
