Abstract VS Encapsulation

[_uj]

Who won the first round?

I did but as nobody seemed willing to surrender to my genius I had to put in an entry also in the second round.

As much as I like your definitions, that sounds like a bold claim. On what grounds do you say that they are "the definite definitions" with respect to OO programming instead of merely being your definitions?

It was a joke because unfortunately there are no definite definitions. Not even OO itself has a widely agreed upon definition.

To be bold, I think my definitions come very close to what many seasoned programmers could agree with. I've polished on them over a period of ten years since I went from C to Java and now to C++. I'm very proud of them so here they are again:

* Encapsulation is the idea of separating type and implementation from each other so they can be considered separately. The type is the outside view of an encapsulated entity. Hidden inside resides the implementation, a specific realization of the type.

* Abstraction is the process of defining a type. The type is used to declare variables which hold data and therefore a type is also called a data abstraction.

But, as always, I wellcome critisism of course.

[TheCPUWizard]

There is a distinct REVERSAL in the terms....

When you encapsulate something your are taking something tangible and moving into something (and usually controlling access)

Encapsulate - to enclose in or as if in a capsule

On the other hand when you create an abstraction, you are REMOVING the details (implementation) and retaining only the concepts.

Abstraction- to consider apart from application to or association with a particular instance

Therefore ....

if you start with an abstraction and move into implementation then you can utilize encapsulation to hide the details.

if you start with an implementation (that may or may not utilize encapsulation) and remove the details, then you are left with an abstraction.

[_uj]

There is a distinct REVERSAL in the terms....

When you encapsulate something your are taking something tangible and moving into something (and usually controlling access)

On the other hand when you create an abstraction, you are REMOVING the details (implementation) and retaining only the concepts.

I don't think encapsulation and abstraction are related in that way. It's not like you can do encapsulation separated from abstraction, or abstraction separated from encapsulation.

Instead encapsulation requires abstraction. Abstraction is what creates the border around what's being encapsulated, namely minute details.

So this idea that there's a REVERSAL beween encapsulation and abstraction is wrong. Encapsulation requires abstraction.

Therefore ....

if you start with an abstraction and move into implementation then you can utilize encapsulation to hide the details.

if you start with an implementation (that may or may not utilize encapsulation) and remove the details, then you are left with an abstraction.

In my world encapsulation is the goal. Abstraction is the means by which it's accomplished. It defines the divide between the type and the implementation.

[TheCPUWizard]

So this idea that there's a REVERSAL beween encapsulation and abstraction is wrong..

My reversal, I meant (and though I explained) the difference in Direction of the process (English language semantics). Very similar to the was tenses are used with verbs.

To encapsulate something requires having two distinct (real) entities, and placing one within the context of another.

To abstract something requires having at least one "real" thing, and distilling information out of it.

You could look at this sequence

1) Have a concept of an entity (this is an abstraction)
2) Create a concrete class which exposes ALL of the capabilities of this entity
3) Modify the concrete class to enclose some of the functionallty which can not be invked directly from extrernal source.

Abstration is going from 2 back to 1. Encapsulation is going from 2 to 3. Opposite directions in the process.

Encapsulation requires abstraction.

There I have to disagree. Encapsulation does not require ANY abstraction what so ever. It is merely the act of placting something inside of something else. Consider three classes that are not directly related and are at the global scope. Put them into a namespace. You have not encapsulated them, but have NOT abstracted (removed) any aspect of the class.

[laserlight]

I did but as nobody seemed willing to surrender to my genius I had to put in an entry also in the second round.

Nah, the first round ended in November 2007 (yes, advika resurrected the thread) without your participation

Encapsulation does not require ANY abstraction what so ever. It is merely the act of placting something inside of something else. Consider three classes that are not directly related and are at the global scope. Put them into a namespace. You have not encapsulated them, but have NOT abstracted (removed) any aspect of the class.

Would I be correct to say that you included an extra not by accident? That is, you intended to write: "You have encapsulated them, but have NOT abstracted (removed) any aspect of the class."

I think that there is a miscommunication here due to two notions of encapsulation. One follows directly from the dictionary definition, and thus defines encapsulation as the placement of some entity in another entity. The other extends this with respect to object oriented programming, and it is this second notion of encapsulation that is inherently tied to abstraction, because it is about encapsulation of implementation, not encapsulation in a general sense.

Consider what Scott Meyers' wrote in his article on How Non-Member Functions Improve Encapsulation:

Encapsulation is a means, not an end. There's nothing inherently desirable about encapsulation. Encapsulation is useful only because it yields other things in our software that we care about. In particular, it yields flexibility and robustness. Consider this struct, whose implementation I think we'll all agree is unencapsulated:

struct Point {
    int x, y;
};

The weakness of this struct is that it's not flexible in the face of change.

So, to make the struct flexible in the face of change, we remove the implementation details from the interface. This removal of details is abstraction. Yet Meyers talks about encapsulation instead of abstraction (by name), because the encapsulation of implementation is the removal of details.

[TheCPUWizard]

Would I be correct to say that you included an extra not by accident? That is, you intended to write: "You have encapsulated them, but have NOT abstracted (removed) any aspect of the class."

I think that there is a miscommunication here due to two notions of encapsulation.Consider what Scott Meyers' wrote in his article on How Non-Member Functions Improve Encapsulation:

So, to make the struct flexible in the face of change, we remove the implementation details from the interface. This removal of details is abstraction. Yet Meyers talks about encapsulation instead of abstraction (by name), because the encapsulation of implementation is the removal of details.

The implementations details still exist, they are what is encapsulated. What is left exposed is the abstraction.

Using the sample..

ORIGINAL:

class Point { public: int X; int Y };

Now the abstraction...

class Point
{
public : 
   int GetX();  void SetX(int);
   int GetY();  void SetY(int);
}

Now the Encapsulation

private:
   int m_X;  // ++ implementation of GetX and SetX
   int m_Y;  // ++ implementation of GetY and SetY

If we look at this psuedo graphically:

InterfaceOnly   <--------   Original   ------>  ImplementatioOnly

We have split the original. The creation (moving to the left) of the interface is abstraction. The creation (moving to the right) of the implementation is the encapsulation.

Left and Right are "reverse" directions spacially....

[laserlight]

The implementations details still exist, they are what is encapsulated. What is left exposed is the abstraction.

Yes, that is why I say "remove the implementation details from the interface".

We have split the original. The creation (moving to the left) of the interface is abstraction. The creation (moving to the right) of the implementation is the encapsulation.

However, notice that they come as a pair: the encapsulation would be useless without the abstraction. In my opinion, this supports the notion that with respect to object oriented programming, abstraction and encapsulation are very much related. It also seems to me that people would then use "encapsulation" when they mean this abstraction + encapsulation pair.

Left and Right are "reverse" directions spacially....

That seems more like a product of the illustration than something inherent in the concept. I feel that it would be more accurate to say that they complement each other rather than that one is the "reverse" of the other.

[TheCPUWizard]

Yes, that is why I say "remove the implementation details from the interface".


However, notice that they come as a pair: the encapsulation would be useless without the abstraction. In my opinion, this supports the notion that with respect to object oriented programming, abstraction and encapsulation are very much related. It also seems to me that people would then use "encapsulation" when they mean this abstraction + encapsulation pair.


That seems more like a product of the illustration than something inherent in the concept. I feel that it would be more accurate to say that they complement each other rather than that one is the "reverse" of the other.

They definately MAY come as a pair, but none of the definitions of complement really apply.

Abstraction is the moving out of (extraction) of information, Encapsulation is the moving in. Going from Abstract to Concrete to Concrete with Encapsulation is a "one direction" process.

Looks like we will just have to agree to disagree on this semantic issue.

[thomus07]

sounds like "abstraction helps encapsulation"

[TheCPUWizard]

sounds like "abstraction helps encapsulation"

Not necessarily...

CODE1

class C
{
   public:
      int X;
};
void F(C &c)
{
   ++c.X;
}

CODE2

class C
{
   public:
      int X;
      void F()
      {
         ++X;
      }
};

"Code2" encapsulates the functionallity of "F" within "C". But there is absolutely no abstraction.

CODE3

typedef void (*pfnFunc)(int &x);

void F(int &x) { ++x;}

pfnFunc  pF = F;

pfnFunc is an an abstraction of any function which takes a integer by reference. There is absolutely no ecapsulation.

This is why my previous post said that MAY occur in tandem, but are not required to be related.

[thomus07]

Your example makes sense.

Adhering to the topic, we concentrated our discussion relating encapsulation and abstraction. I think, if we separate the problem into encapsulation and then abstraction, we would be more clear.

If we understand each concepts separately and then if we relate to anything, we would be more clear.

I think most of us have an understanding of encapsulation.

Please can you make your input for abstraction, without relating to encapsulation (or any other concept.)

[laserlight]

I wanted to agree to disagree and leave it there, but it looks like I cannot resist

"Code2" encapsulates the functionallity of "F" within "C". But there is absolutely no abstraction.

There is, since C is an abstraction. If C is not an abstraction, then I would argue that there is no encapsulation of implementation, so in an object oriented sense, there is no encapsulation.

This is why my previous post said that MAY occur in tandem, but are not required to be related.

I agree, if we are talking about abstraction and encapsulation as a general programming ideas, but I disagree if we are talking in terms of object oriented programming. Hence, in terms of object oriented programming, the term "complement" does apply since they are parts of a whole (the process of "moving" both "inwards" and "outwards", as you put it).

[exterminator]

Not necessarily...

CODE1

class C
{
   public:
      int X;
};
void F(C &c)
{
   ++c.X;
}

CODE2

class C
{
   public:
      int X;
      void F()
      {
         ++X;
      }
};

"Code2" encapsulates the functionallity of "F" within "C". But there is absolutely no abstraction.

There can be abstraction at different levels. In the above, you say that there is absolutely no abstraction - which is disagreeable to some extent. To me, the first one looks like an incomplete abstraction and the second one a complete one i.e. if the first example is in relation to a language of implementation where you do have full-featured OO support for example, in C++. But if you are dealing with a language of implementation where you do not have OO supporting features, then first one is the closest you can get to achieving abstraction, for example in C, where you do not have the notion of member functions forming part of the abstracted interface.

I feel comfortable with the distinction between abstraction and encapsulation that:

- abstraction is anything that's got to do with the user of the type, interface, functionality, whatever. It has nothing to do with how that type/interface/functionality/whatever is going to be implemented. You just ignore those details when doing abstraction. That's why I like the definition that Andrew Koenig uses for abstraction being 'Selective Ignorance'. We choose to ignore the details although they are important but not when doing abstraction. Those are the next step.

- encapsulation is the way to keep the details of those types, interfaces, functionality and other implementation details away from the user (user meaning user code here). This helps in flexibility/maintainability of design. In a way we can say, it has nothing to do with the usage of the abstraction or the user code itself but it ensures that the usage/user code doesn't try to make itself depend on the details that are prone to changes as the design evolves.

So, abstraction is at the level of functional use and encapsulation helps hide the details of how that 'use' is implemented.

Hence, I find myself in agreement with what Graham said and what laserlight said as well - encapsulation being complementary to abstraction. encapsulation helps abstraction - in fact it makes an abstraction beneficial and protects it in many ways. It is the hiding of the implementation detail that makes the abstraction successful in the way it has got to be.

The second class example, is a complete abstraction but is not very useful because it exposes the way the class is implemented - doesn't expose completely but does partially and that is bad. It keeps the data members exposed that can harm the system design and cause great coupling of the implementation detail (of which data members are also a part of) and the user code. Hence, that abstraction is not a complete success unless one encapsulates the detail (that in this particular example can be achieve by private keyword - hiding the data members). The details can change someday and break the rest of the code or atleast cause a huge ripple effect that is rarely desirable. Of course, it is not necessary to make the design a 'robust' one.

So, even if the above code (snippet 2) may be a 'complete' abstraction in itself - it may be a failure in ways if encapsulation doesn't 'protect' against that.

CODE3

typedef void (*pfnFunc)(int &x);

void F(int &x) { ++x;}

pfnFunc  pF = F;

pfnFunc is an an abstraction of any function which takes a integer by reference. There is absolutely no ecapsulation.

Actually, I see both here! There is abstraction. How? The example abstracts the idea of a type that represents a function that takes so and so parameters and returns so and so results. That is what the user is to rely on. But there is encapsulation as well! How? The typedef! It hides away how the pfnFunc might be actually implemented behind the scenes. Well, note that the user can always see how the pfnFunc is implemented (as a typedef to a function pointer) but encapsulation doesn't protect against that. For example, even if a user can 'see' the private members in a class - and there can be ways to use those private details (reliable or unreliable - irrelevant) but that is not at all beneficial! As James Kanze says: "My recommendation in such cases would be to change the programmer, not the code" (source: C++ FAQ Lite).

How is that an encapsulation and how does it help? That is an encapsulation as it hides the details of how pfnFunc might be implemented. It helps in the way that tomorrow - one might opt to use a class to represent that function pointer and that shouldn't need the user code to change itself to adapt to that implementation details. Like this:

Today:

typedef void (*pfnFunc)(int &x);
void F(int &x) { ++x;}
pfnFunc  pF = &F;

Tomorrow:

//can contain some state tomorrow
//can have enhanced log/call trace
//if not convinced just assume there can be a valid reason to provide a different implementation
struct pfnFunc_detail{
private:
    typedef void (*pfnFunc_ptr)(int &x);
    pfnFunc_ptr fptr;
public:
    pfnFunc_detail(pfnFunc_ptr fptr_) : fptr(fptr_){}
    void operator()(int& x) { fptr(x);}
};

typedef pfnFunc_detail pfnFunc; 
void F(int &x) { ++x;}

int main()
{
    pfnFunc  pF = &F;
}

Here, pfnFunc_detail now can be a class underneath or just a typedef to a function pointer or that type. Another better example can be: a typedef to a StringCollection that might be a std::vector<std::string> today and std::vector<std::string, some_custom_allocator> someday or even std:eque<std::string> some other day. The user code is prevented as long as it follows the guidelines to usage of the StringVector (provided there is one, of course). That is how, I do suggest keeping a typedef for std::vector<bool>, in order to prevent user code from getting affected by much in case std::vector<bool> is changed tomorrow to mean something else (well, it means something else even today and hence the problem to which typedef is one of the solutions). The user code wouldn't need to adapt by much if I changed the typedef to say: std:eque<bool>. That's just one example where typedef helps encapsulate the detail of how my BoolVector is implemented. That is also one of the ways to achieve encapsulation in C as I stated in my earlier post.

This is why my previous post said that MAY occur in tandem, but are not required to be related.

They may occur in tandem. They are not required to be related. But in reality, encapsulation does complement abstraction and without it the abstraction can easily be a failure or not be achieved in the best possible way.

In the end, I do feel, everyone can have his own definition that they are comfortable with as long as the end product is the same and as long as there are sufficient reasoning behind those definitions. I do agree that I sometimes do use encapsulation to mean "abstraction + needed encapsulation". But some standardization or some guidelines certainly do help.