C# difference between Abstraction and Encapsulation

Question

1.00/5 (2 votes)

See more:

I just spent a long while on Google trying to figure this out and want to make sure I have it right.

Encapsulation is hiding data that another programmer of different classes should not be able to directly access.

Abstraction is only making available the methods and features that are essential of a class. AKA I may have 30 methods that are necessary for making my class work, but only 5 of them should be accessed by anyone calling it, as they make all the necessary calls to the other functions.

So Encapsulation are the private variables and methods and Abstraction are the public ones. Is this correct?

I understand that Abstraction can be completed using Abstract, Interface and overloading as well. I just want to know if I'm right in the most basic sense.

Posted 21-Jan-15 7:51am

Safari137

Updated 21-Jan-15 8:32am

v2

Add a Solution

Comments

OriginalGriff 21-Jan-15 14:09pm

And?
Your question is? :laugh:

Safari137 21-Jan-15 14:33pm

touche` lol

Sergey Alexandrovich Kryukov 21-Jan-15 17:39pm

Nearly all questions on "differences" are invalid. This is the same as asking: "what is the difference between Christmas and Santa Claus"? Would you be able to answer? And this is the same thing.

Your main problem (or, rather, the problem of your teacher and study material you have, but yours too) is that you are learning by words instead by getting to essence of things.

Besides, there is a traditional "pedagogical" way of explaining OOP as something based on some base principles: encapsulation, inheritance, polymorphism and abstraction. People who really understand OOP often don't pay much attention for that, but simple analysis shows that such way of education is nearly pure lie (depending on how persistent and dogmatic such "pedagogic" shows). The reason for that is: even though all these words correspond to some real and very important notions, those notions cannot be considered as the set of basic fundamentals, because they are not independent, belong to different levels of abstraction (for example, "abstraction" is applied to absolutely everything in programming), some serve as prerequisites for others, and so on.

What to do? Don't trust such teaching. Try to get to the essence of things, by examining how it really works.

—SA

2 solutions

Solution 1

Ok, you were not quite efficient in googling :)
Encapsulation[^] is quite what you have drafted: hiding from the class "user" what's not his concern. If I implement a class that represents a polynom, don't let the user uf my class mess around with the array storing the coefficeints. And so on...
If you wnat to understand abstraction[^], you better also look at the other direction, specialization. Let's think about shapes. A shape is an abstract thing, but all shapes have area and perimeter. But at this point you can't say how to calculate these. Bur you have rectangles, triangles, curved ones, and general polygons. These are specialized descendants of the shape abstraction. At this point you can calculate are and perimeter of them. But you can go even further. A square is a specialized rectangle, and you can override the formulas defined in the rectangle class, with more specialized ones. Aswell there are specialized triangles and specialized curved shapes.

If you read the article I have linked you will see, that there are other kinds of abstraction in computer sciances. But the idea is the same: abstraction is the way of dealing with the compexity of a model related to the real-word objects, getting rid of uninteresting aspects, and concentrating on what's important. But keep in mind that modelling is not a one-time action: the abstract model of the same real-word object might differ from project to project.

Posted 21-Jan-15 8:24am

Zoltán Zörgő

Comments

Safari137 21-Jan-15 14:37pm

Correct me if I'm not understanding.

By creating an Abstract method for example, you create a basic outline of a method's design and functionality. By using a subclass you can overload that method to achieve the same result for a slightly different object than the parent class. And you are doing this as opposed to creating multiple functions with different names?

Zoltán Zörgő 21-Jan-15 15:00pm

More or less.
In the case of an abstarct method, you don't add any functionality. But it don't has to be abstract to override it. Let me turn back to my examples: Area method in case of Shape abstract class will be abstract, in case of Rectangle class it will return a*b, but in case of the more specialized Square it will return a^2. So you don't necessary achieve the same result, you serve the same purpose. This is overriding. But of course you can also extend the base class wth new functionalities, like adding Diagonal method to the rectangle.
On the other hand if you create multiple methods with the same name you create overloads on that method. You can add functionality (specialize the base class) also by overloading.

Sergey Alexandrovich Kryukov 21-Jan-15 17:45pm

Zoltán,

I understand that it's difficult to explain the very commonly used notions and don't want to blame you for lack of clarity I can see in this answer. I think the whole idea of answering such incorrect questions is wrong. Instead, it's good to look critically at how OOP is traditionally explained and not catch the hook. I really think that many authors of the texts on the subject (even those who actually use OOP) don't understand it and simply repeat the same words, like parrots. Please see my comment to the question.

—SA

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

BillWoodruff · Accepted Answer · 2015-01-22T01:40:00

I think you are struggling, as many newcomers to C# and OOP do, with trying map big-picture concepts/outcomes of implementing what you might call "general OOP philosophy" to actual C# code objects you program with.

In my experience students often start C# with a general sense that OOP is about modeling "objects" in "the real world;" and, yes, that is a major use of OOP technique, but, in programming in C# you are dealing with objects that are unique to code, as well. Your Program in WinForms is a (static) Class; your UserControl in WinForms can inherit from other user-interface widgets.

I'd like to suggest that you focus on studying, and creating, actual C# programs that implement and use Classes (abstract, virtual, and "regular"), Interfaces, Structs, Enums, and Delegates.

As you gain increasing mastery of using these tools/objects, then I suggest you step-back and articulate how, for you, they fit in to your understanding of OOP, in general. This suggestion is based on my experience with many students, most of whom do better learning OOP with a bottom-up, rather than top-down approach.

Abstraction is a principle, an outcome to be attained, of implementing relationships of objects in such a way that they can interact efficiently, and also do not generate unknown side-effects.

Inheritance is the key technique used to implement abstraction; C#'s inheritance facility allows for single-class inheritance, and multiple interface inheritance (other programming languages offer different paradigms). However, one can, in C#, in effect achieve multiple inheritance by compound, or serial, inheritance of the form:

C#

public Class1
{
    public void Method1(string sParam, int iParam) {}
}

public Class2 : Class1
{
    public void Method2(string sParam, int iParam) {}
}

public Class3 : Class2
{
    public void Method3(string sParam, int iParam) {}
}

In this (silly) example the point is that any instance of Class3 will have access to Method1 in Class1 and Method2 in Class2.

An actual Abstract Class in C# is not necessarily an "abstraction," although it's a tool one can use to implement "abstraction:" remember that the Abstract Class can contain actual Method implementations, as well as Virtual methods.

Encapsulation is a big-picture concept that says it is valuable, desirable, even necessary, to exert rigorous control over the possible interactions of objects by regulating what they expose to other objects, and regulate that exposure through formal means (Interfaces, for example). This big-picture concept is also expressed using terms like "modularity," "separation of concerns."

Around the term "OOP," there are a swarm of buzzwords that come and go, reflecting the times, the trends, the latest gurus.

Getting "down to earth" with what C# allows, and does not allow, is a good basis for, later, exploring such fascinating capabilities of the language as Extension Methods (you can even extend Interfaces !), Linq, Reflection and dynamic creating of new assemblies at run-time that contain code that can be executed, etc.