Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I find the encapsulation concept a bit confusing. So far I have read that the members of the class should be private and any access to private members must be through getter and setter methods, which are public. Are these the only properties which define a properly encapsulated class?

If yes, what about protected class members? We can access protected members in the same package through an object reference — are classes containing protected members improperly encapsulated?

Please give clarification.

share|improve this question
2  
"members of the class should be private and any access to this private members must be through getters and setters methods which are public" - No. That's like stating "medical care is covering everyone's limbs in bandages". –  delnan Oct 19 '11 at 17:34

2 Answers 2

up vote 6 down vote accepted

Encapsulation is properly defining access to the members of an object and protecting the internal state of the object.

The first part, defining access, is done through the access specifiers (public, private, protected, and so on). Typically, a well encapsulated class limits access as much as possible. If only the current class (or an instance of that class) needs access to it, make it private. If subclasses also need access to it, then it's a protected member. Note that this applies equally to variables and methods.

The second part is to protect the internal state of the object from ever being invalid. This is one of the driving factors behind accessor and mutator methods. You can use these methods to always ensure the validity of the state of the object. For example, if you have a member variable that can only contain specific values, you can validate before changing the state of the object if you require the use of mutator methods, but can't with a public variable.

share|improve this answer
2  
This is also one of the driving factors behind not having access and mutator methods, unless there's a reason, relevant to the behavior of the class, to expose a data member. –  David Thornley Oct 20 '11 at 20:51

Depending on who is teaching that concept, encapsulation can have soooo many definitions that it is essentially a buzzword to be defined with a tens of other buzzwords, sometimes even going to the ridiculous statement like your reported "So far i have read that the members of the class should be private and any access to this private members must be through getters and setters methods which are public".

The need of encapsulation typically arise when you represent an object by aggregating a number of components whose values are each other related, and hence cannot be changed each other independently, without making the object invalid or clueless or meaningless or pantless or whatever you want to call it. In those case you -an only you- assume the responsibility to manage those subvalues, making those component hidden (or unaccessible ... is much a matter on how the language works), and providing the aggregate with public methods that modifies the inner values properly.

-Edit- Everything else is just "purism over-construction" that doesn't really implement anything, apart ... satisfying OOP zealot teachers.

-Edit- P.S.: I have to sorry to all OOP teachers, but 30 year of experience in the industry makes me really wonder abut the damages of certain "uncritical" way to teach "rules" rather than concepts and relations between them! You can downvote, if you want, but I would like to see a practical demonstration I am wrong! The world is full of (really bad) books teaching bad things like

class A
{
private:
   int x;
public:
   void set_x(int x_) { x=x_; }
   int get_x() const { return x; }
};

That didn't encapsulate anything, since it lets you do anything you want with x.

share|improve this answer
1  
Strangely enough, this is still downvoted (while being quite correct) ;) To add, one can expose even the (interrelated) internals of a class' instance, if he obliges the user of the class to maintain respective relationships "by hand" -- it's nothing (conceptually or practically) wrong with having such a contract. But if the object can fulfill the same role with less being known about its proper usage (i.e. conforming to a "smaller" contract), that makes it possible to change the internals w/o changing the client code. That's one thing about encapsulation. –  mlvljr Jun 3 '12 at 8:03
    
Another thing is, using several objects together is plain easier when their contracts are more compact -- since the (conceptual) complexity of the code is a "multiplication" of the complexities of those contracts. Of course, in each context there is a limit on "encapsulation level" of the objects involved -- you must still be able to fulfill the given task in the client code, or the (perfectly encapsulated) objects/classes used are ..useless. –  mlvljr Jun 3 '12 at 8:09

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.