Which option best fits the definition of encapsulation ?

Question

Hi Folks,
In this test question :
How can you implement encapsulation.
A) By making methods private and variable private
B) By making methods are public and variables as private
C) Make all variable are public and access them using methods
D) Making all methods and variables as protected
What could be the answer ?
I guess making variables private and accessing them with methods with appropriate access levels would be the way to go for encapsulation.But I am not able to relate any of the options with that.
I would appreciate if I receive some feedback on this.
Thank you for your consideration.

Answer 1

Surely to answer this question you must first state the definition of encapsulation to which you subscribe and then evaluate each of the answers in terms of that definion.
So, which definition would you like to use?
Some would say that using a standardised definition might help; and fortunately the International Organisation for Standardization has published just such a definition in its standard: Open Distributed Processing, ISO/IEC 10746. There, they define encapsulation as:
"... the property that the information contained in a modelled entity is accessible only through interactions at the interfaces supported by that modelled entity."
You may or may not agree with the ISO on this, but let's run with their definition and see where it gets us, shall we?
Firstly, encapsulation concerns accessibility, and on this point, your alternatives are clearly and crisply distinguishable. This is good.
Secondly, the, "Information," referred to here is not just data: it also includes behaviour, i.e., methods. Thus it makes little sense to distinguish between data-encapsulation and method-encapsulation; both a method and a variable can be a point of access of an class. This somewhat cheapens all the alternatives given in your test, which is not good.
Thirdly, encapsulation is not binary: it is not usually a yes/no answer; so we will almost certainly have degrees of encapsulation and thus can rate the answers given in your test on this gradient.
Fourthly, it can be shown, if you begin with the above definition, that encapsulation's benefit is in minimising the number of potential dependencies with the highest probability of modification event propagation. Thus we can also rate the answers given in your test by asking how each exposes classes to such potential dependencies.
Lastly, some of the answers you've been given are wonderfully vague, so we'll have to watch our step; frankly, some of them, because of their vagueness, are discountable for reasons that go beyond encapsulation and deep into the realm of common sense.
Let's take a look at the answers, though before we do, we must decide whether the answers pertain to a specific, single class or to all classes in our system: we shall presume the latter, that these answers concern a general approach to programming, rather than advising on a single class's design (it actually makes a difference).
"A) By making methods private and variable private."
Well, by making all methods and variables private you will effectively deny all access to information stored in all classes: this would make all your classes unusable, which makes the question of any of their properties a moot point.
"B) By making methods public and variables private."
(The vagueness begineth: it's presumed that this implies making all methods public.) This would give access to the information of all the classes via all their methods, which means that none of their behaviours are information-hidden, even though all their data is information-hidden. This is better than (A) but not an ideal way to design a system: given that all methods in all classes are accessible, then potential dependencies may form on all of them and thus changing any method could potentially ripple to all other classes in the system: a deeply costly prospect.
"C) Make all variables public and access them using methods."
This makes all data accessible and some unspecified subset (perhaps all) of behaviours accessible in all classes. This would seem to offer more accessibility than (B) and so would offer a greater modification event propagation probability than (B). This thus seems less satisfactory than (B).
"D) Making all methods and variables protected."
Protected accessibility is theoretically problematic, but it implies that there are at least some clients that have full access to all classes, with the consequent costly modification event propagation probability. This alternative, however, is discountable for reasons that lie beyond encapsulation, as it implies that the only way that classes in different packages could communicate is if the classes are subclasses of one another; it's almost impossible to imagine a semantically coherent system in which all these classes were subclasses of one another, so this alternative can be rejected on the grounds of implausibility (if not silliness).
So, if we go with ISO above, then we're left with the following alternatives in order of decreasing appropriateness: B, C, D and A.
So B would be my answer, though I'd have to swallow hard to write it.
For more on encapsulation according to the ISO, see, "How to encapsulate software (Part 1)," here:
http://www.edmundkirwan.com/encap/overview/paper7.html
Regards,
Ed.