DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations

Keep Calm and Hide Your Code: Code Encapsulation

Encapsulating your code is key to keeping it clean and reusable. These quick hints include adhering to the single-responsibility principle and hiding the state.

Roman Predein user avatar by
Roman Predein
·
Jan. 30, 17 · Opinion
Like (25)
Save
Tweet
Share
19.56K Views

Join the DZone community and get the full member experience.

Join For Free

In this article, I’d like to open your eyes on code encapsulation and, hopefully, you will enjoy the five 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 research and development company in the 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 the exhaustive testing and flexibility needed to meet final customer specifications and the need to manually build for most of the parts.

I was held in a meeting because of a breakdown of one of the devices, with pictures of the internal parts sent by the customer, documentation, and reports on that particular unit, and the readings of the last weeks from all the sensors the machine had. It was 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 over it — one of the brightest people I’ve ever met.

After a long discussion, after all sorts of suppositions were made, after every pixel of every photograph was checked, it was the boss' turn to speak. He'd barely spoken during the whole meeting. The room went quiet, and all eyes pointed to him. Completely silent, with his arms crossed, he slowly leaned back in his chair. After a pause, he 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 about. That is the behavior we expect of more and more things that surround us. Think of your computer, for instance, and how easy it is to upgrade it. Probably soon enough, the same thing will happen with smartphones. And this happens not only with your hardware, but also with your code. With good code encapsulation, with classes of high cohesion between data and behavior, it’s easier to read and extend.

Most of you have probably seen some old spaghetti code such as an endless PHP file that prints HTML and JavaScript, or some more modern one using an MVC framework, like Laravel, for example, with controllers of thousands of lines and endless functions. Maintaining such code can be a real nightmare. But do you avoid falling into 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 with another and build new functionality re-using existing components. But how exactly?

5 Tricks for Code Encapsulation

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 you to review all its uses.

Therefore, instead of:

if(user.admin || user.moderator || user.editor){
    …
}


How about:

if(user.canEdit()){
    …
}


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.

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.

Break Them Into Smaller Sections

Have 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 five small functions with self-describing contracts is more pleasant.

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 will be 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 behavior 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.

code style Encapsulation (networking)

Published at DZone with permission of Roman Predein. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • [DZone Survey] Share Your Expertise and Take our 2023 Web, Mobile, and Low-Code Apps Survey
  • How Elasticsearch Works
  • Introduction to Container Orchestration
  • Practical Example of Using CSS Layer

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: