This post is the result of a discussion in class which revolved around the concepts of polymorphism, encapsulation, abstraction and inheritance. The concepts of polymorphism and encapsulation eluded my group’s ability to elaborate beyond the definition of the word in a dictionary. Trying to explain such concepts by this method would be over simplistic and not helpful in the computer science context, so I decided to research it and write a blog to educate myself on at least one of the terms. The term I chose was encapsulation because I believe it to have ephemeral properties harder to describe than the others.
In the dictionary some explanations of the word encapsulation are interesting. One of the examples talk about setting a permanent cover over contaminated soil. I myself tend to think of encapsulation as a form of nesting –not in the recursive sense, but in a sense, attributes can be placed at different levels inside other objects and so on.
The aforementioned nested idea says that encapsulation is used to bundle attributes of an object and control access to it. It does that by using access modifiers to control access to classes. An example would be the private access modifier –you can create a private variable in an object and then decide which type of modifications are allowed and how these modifications would work. Once those private variables are created, they can be initialized indirectly by a constructor, but they cannot be accessed directly outside their class. If access is needed, it must be granted in the form of a setter and or getter.
This can be very useful if the information of an object is important and changing it or using invalid arguments would cause undesirable behaviors to the class.
A getter can give access to a variable of importance if needed for any reason, but write access needs to be denied.
A very trivial example would be a constant found that is very useful but should never change, you may need access to it numerous times, but every time you access it you expect it to be the same, and you may not necessarily know what this value should be.
A setter can also be a way to control access making sure that any change is done purposefully and not accidentally or by side effect during the execution of a program or a task. Some behavior of an arbitrary object may need to be changed from the outside but that’s a hard decision to make, and I believe it would involve investigating the functionality of the object in the context it was meant to execute.
Looking at the small portions of code we usually work on makes it difficult to understand the necessity for encapsulation. But in large environments outside the boundaries of what we can see or are working currently, there can be countless opportunities to fail from not utilizing good practices for encapsulation.
Encapsulation is like the member of a melodramatic story that you only miss when it’s too late.
[please feel free to point things that are off the mark, missing and or incomplete statements]
From the blog CS@Worcester – technology blog by jeffersonbourguignoncoutinho and used with permission of the author. All other rights reserved by the author.