Code encapsulation

Eder Tassin
4 min readDec 2, 2020
Explanatory graph of methods and variables within classes

Classes in an object-oriented language are the solution that offers this programming paradigm to the concept of Abstract Data Type (ADT) pursued during much of the history of software in order to simplify the programming process and make affordable applications increasingly large and complex. On the other hand, the concept behind ADT’s is encapsulation.

Structured programming introduces subroutines (functions and procedures) in order to address large problems by subdividing or partitioning the problem into smaller problems. But this subdivision is made from the functional point of view, that is, it is described a big algorithm in function of a set of smaller algorithms that, to be possible, has own entity. A routine has own entity when it is independent of the rest and reusable. The reuse of code is a highly desirable feature because it not only reduces the cost of programming but also provides:

Reliability: As routines are used they are more reliable.
Efficiency: By taking care of a subroutine independently from the rest (it can even be implemented by a different team of programmers) it is easier to dedicate additional effort to make it as efficient as possible.

Object-oriented programming takes a giant leap in this direction by bringing together or encapsulating both attributes and functionality in a single code entity. The partitioning or decomposition of the problem is no longer done only from a functional point of view but goes beyond. The objects arise from the need to model the software design problem from the point of view of the entities that compose it and from its classification into different types or classes. Basically this is the idea under which an ADT is defined and classes are, today, one of its best approaches.

The use of routines in the implementation of a program allows a certain degree of abstraction since to use a subroutine is not necessary to know how this routine solves a problem but only to know which problem it solves and which is its interface. The interface of a routine is given by its input and output arguments, ie, what data and what type are those that must be provided to the routine to solve the problem and what data and what type are those who return. It can be said that the routines “encapsulate” in its interior the resolution algorithm. Associated with the concept of encapsulation is that of “visibility”, which is given by its interface or what you want to make known and accessible from another part of the code.

Object-oriented programming obviously includes the same type of encapsulation at the method level as that provided by structured programming with subroutines. However, it takes the encapsulation of code to a higher level of abstraction, the level of abstraction provided by the classes, which can encapsulate both attributes of the entities as well as the behavior associated with them. The interface in the case of the classes can be given by the prototype of some of its methods and by some of its attributes. The interface of a class should be well defined before its implementation only by that subset of methods that the class “wants” to offer to the rest of the entities and that define the services that any of its instances offers.

The set of attributes and methods that you want to remain “hidden” is, of course, up to the programmer. However, there are mechanisms, such as Java, to provide different levels of accessibility to the members of a class and, thus, build an appropriate interface with which other objects of the application can interact with the objects of that class allowing accessibility to some members and preventing others. As a general rule, and in order to carry out adequate programming as close as possible to object-oriented programming, the interface should consist only of the prototype of a subset of methods. It should not include certain methods that have been implemented when subdividing a complex algorithm into small algorithms (structured programming), and never by the attributes, which should be “encapsulated” in the class.

We can see in the image below an example of what we have been talking about:

Thanks for reading ♥

--

--

Eder Tassin
0 Followers

Full-stack developer in training Twitter: @edertassin