What constitutes encapsulation?

[Simon Cockayne]

Hi,

I understood "encapsulation", in a nutshell, to mean private members **and** public getter and setters.

I found a mock answer saying "If a class's instance variables are marked private, the class canbe said to be encapsulated".

Any thoughts?

Cheers,

Si.

[marc weber]

Accessor and mutator methods are common, but are not required for encapsulation.

I would add that if a class is not tightly encapsulated, then none of its subclasses are. Also, a class is not tightly encapsulated if it returns a reference to an internal, mutable object. (However, it may return a reference to an immutable object, or to a copy or clone of an internal object.)

[Tony Morris]

Encapulation is the most poorly understood OO concept.
Academics will quickly tell you that public data fields violate encapsulation and that there is nothing more to it. Engineers will tell you that public data encapsulation is some silly concept they learnt at school. I certainly don't feel I'm going to give the topic justice on this forum - I've even proposed writing a 120 page Dissertation about it (I'll let you know if you like how it goes)! However, encapsulation is of paramount importance in software design. In fact, encapsulation is perhaps the most prevalent metric when determining the quality of software (quality is something the client does not see and is unrelated to the metric of "meeting requirements").

In the context of Java, consider the following assertions:
- Non-private constructors violate encapsulation
- Non-final classes violate encapsulation (yes that's right - the protected and abstract modifiers are evil!)
- A protected data field violates encapsulation
- A non-private data field of a type that is mutable (such as an array) violates encapsulation.
- All violations of encapsulation are of the same magnitude - you can't "violate it more this way than that way"
- The lack of access modifiers means that encapsulation cannot be fully enforced at times (C# makes efforts to fix this)
- The Java language intrinsically violates encapsulation since it forces the inheritance of implementation (specifically, java.lang.Object).

I realise these assertions (which by the way, are incomplete) will raise more questions than provide answers, but I do hope to one day give them the full explanation that they deserve.
[ April 06, 2005: Message edited by: Tony Morris ]

[Animesh Shrivastava]

Tony,
By ur assertions it means that the class which cannot be reached from outside is well encapsulated. That means the class is on its own.

As far as i know Encapsulation according to OO concept says that hiding the internal details about the class. The only way to access these would be thru some kind of interface. So it may mean to have all private data members and the interface through which we may access it would be the methods which act on the variables. These methods would be public to all. All the operations to be done on the variables of the class should be done using those methods.

[Mohan Mani]

Can we say all JDBC classes are well encapsulated, since we are accessing the method of those classes only through "Connection Interface".

Regards
Mohan M

[Tony Morris]

There are no JDBC classes - they are mostly interfaces.
The DriverManager gives you a handle to the underlying implementation, which is exposed through those interfaces. This is not an example of encapsulation.

[Parameswaran Thangavel]

hi tony
In scjp will they ask to point out some examples if so then please give us on good examples on encapsulation

[marc weber]

The SCJP 1.4 exam will likely ask you to identify some very basic characteristics of encapsulation. However, the questions are not likely to go beyond what I mentioned above.