One of the fundamental principles of object technology is that the internals of an object are private to that object and may not be accessed or even examined from outside the object.
Encapsulation is a simple yet reasonably effective building tool. It is a way of packaging information. Encapsulation allows the pro-grammer to present clearly specified interfaces around the services they provide. The programmer can decide what should be hidden and what is intended to be visible.
Some advantages of encapsulation are:
• Managing complexity
• Managing change
• Protecting data
Message : The communication media of objects.
Subclass : A class inheriting another class’s properties.
Data hiding : Protecting data by preventing direct access to it. This is done by making the data, private or pro¬tected members of a class.
Abstraction
Abstraction refers to the act of representing essential features with¬out including the background details or explanations. It is the art of concentrating on the essential thing and ignoring the non-essential things.
Classes that use the concept of data abstraction are known as “abstract data types”. Abstract data types are achieved by making certain variables and methods in a class as private. Abstraction makes an objects look either unique, similar to or different from other objects depending on viewers.
For example, people do not think of a computer as a set of thousands of individual parts. They can ignore the details of how the CPU, Monitor and Keyboard works.
Encapsulation
November 29th, 2008 | Internet
1 comment so far ↓
You didn’t give the definition of a rational for the benefit of encapsulation.
The International Organisation for Standardization defines encapsulation as, ‘The property that the information contained in an object is accessible only through interactions at the interfaces supported by the object.’
Thus, as some information is accessible via these interfaces, some information must be hidden and inaccessible within the object. The property such information exhibits is called information hiding, which Parnas defined by arguing that modules should be designed to hide both difficult decisions and decisions that are likely to change.
Note that word: change. Information hiding concerns potential events, such as the changing of difficult design decisions in the future.
Consider a class with two methods: method a() which is information hidden within the class, and method b() which is public and thus accessible directly by other classes.
There is a certain probability that a future change to method a() will require changes in methods in other classes. There is also a certain probability that a future change to method b() will require changes in methods in other classes. The probability that such ripple changes will occur for method a(), however, will usually be lower than that for method b() simply because method b() may be depended upon by more classes.
This reduced probability of ripple impacts is a key benefit of encapsulation.
Consider the maximum potential number of source code dependencies (MPE - the acronym is from graph theory) in any program. Extrapolating from the definitions above, we can say that, given two programs delivering identical functionality to users, the program with the lowest MPE is better encapsulated, and that statistically the more well-encapsulated program will be cheaper to maintain and develop, because the cost of the maximum potential change to it will be lower than the maximum potential change to the less well-encapsulated systém.
Consider, furthermore, a language with just methods and no classes and hence no means of information hiding methods from one another. Let’s say our program has 1000 methods. What is the MPE of this program?
Encapsulation theory tells us that, given a system of n public nodes, the MPE of this system is n(n-1). Thus the MPE of our 1000 public methods is 999,000.
Now let’s break that systém into two classes, each having 500 methods. As we now have classes, we can choose to have some methods public and some methods private. This will be the case unless every method is actually dependent on every other method (which is unlikely). Let’s say that 50 methods in each class is public. What would the MPE of the systém be?
Encapsulation theory tells us it’s: n((n/r) -1 + (r-1)p) where r is the number of classes, and p is the number of public methods per class. This would give our two-class systém an MPE of 499,000. Thus the maximum potential cost of a change in this two-class systém is already substantially lower than that of the unencapsulated systém.
Let’s say you break your systém into 3 classes, each having 333 classes (well, one will have 334), and again each with 50 public methods. What’s the MPE? Using the above equation again, the MPE would be approximately 482,000.
If the systém is broken into 4 classes of 250 methods each, the MPE will would be 449,000.
If may seem that increasing the number of classes in our systém will always decrease its MPE, but this is not so. Encapsulation theory shows that the number of classes into which the systém should be decomposed to minimise MPE is: r = sqrt(n/p), which for our systém is actually 4. A systém with 6 classes, for example, would have an MPE of 465,666.
Leave a Comment