In interviews I have been asked to explain the difference between abstraction and encapsulation.  My answer has been along the lines of

* **Abstraction** allows us to represent complex real world in simplest manner. It is the process of identifying the relevant qualities and behaviors an object should possess; in other words, to represent the necessary feature without representing the background details.

* **Encapsulation** is a process of hiding all the internal details of an object from the outside real world. The word &quot;encapsulation&quot;, is like &quot;enclosing&quot; into a &quot;capsule&quot;. It restricts clients from seeing its internal view where the behavior of the abstraction is implemented.

I think with above answer the interviewer was convinced, but then I was asked, if the purpose of both is hiding, then why there is a need to use encapsulation.  At that time I didn&#39;t have a good answer for this.

What should I have added to make my answer more complete?

What&#39;s the difference between abstraction and encapsulation?

I understand it is a very basic concept in the oops. But still I cannot get my head around. I understood why member variables are private, so class user cannot abuse it by setting up invalid values.

But how can this apply to the methods ? 


Why &quot;private&quot; methods in the object oriented?

From http://www.cplusplus.com/reference/utility/pair/, we know that `std::pair` has two member variables, `first` and `second`.

Why did the STL designers decide to expose two member variables, `first` and `second`, instead of offering a `getFirst()` and a `getSecond()`?

Why does std::pair expose member variables?

What is the difference between `public`, `private`, and `protected` inheritance in C++?

All of the questions I&#39;ve found on SO deal with specific cases.

What is the difference between public, private, and protected inheritance in C++?

I am trying to understand the difference between `__getattr__` and `__getattribute__`, however, I am failing at it.

The [answer][1] to the Stack Overflow question *[Difference between `__getattr__` vs `__getattribute__`][2]* says:

&gt; `__getattribute__` is invoked before looking at the actual attributes on
&gt; the object, and so can be tricky to
&gt; implement correctly. You can end up in
&gt; infinite recursions very easily.

I have absolutely no idea what that means.

Then it goes on to say:
&gt; You almost certainly want `__getattr__`.

Why? 

I read that if `__getattribute__` fails, `__getattr__` is called. So why are there two different methods doing the same thing? If my code implements the new style classes, what should I use? 

I am looking for some code examples to clear this question. I have Googled to best of my ability, but the answers that I found don&#39;t discuss the problem thoroughly.

If there is any documentation, I am ready to read that.


  [1]: https://stackoverflow.com/a/3278104/3798217
  [2]: https://stackoverflow.com/q/3278077/3798217

Understanding the difference between __getattr__ and __getattribute__

Suppose I have a method that returns a read-only view into a member list:

```java
class Team {
    private List&lt;Player&gt; players = new ArrayList&lt;&gt;();

    // ...

    public List&lt;Player&gt; getPlayers() {
        return Collections.unmodifiableList(players);
    }
}
```

Further suppose that all the client does is iterate over the list once, immediately. Maybe to put the players into a JList or something. The client does *not* store a reference to the list for later inspection!

Given this common scenario, should I return a stream instead?

```java
public Stream&lt;Player&gt; getPlayers() {
    return players.stream();
}
```

Or is returning a stream non-idiomatic in Java? Were streams designed to always be &quot;terminated&quot; inside the same expression they were created in?

Should I return a Collection or a Stream?

Can you tell me what is the difference between **abstraction** and **information hiding** in software development?

I am confused. Abstraction hides detail implementation and
information hiding abstracts whole details of something.

**Update:** I found a good answer for these three concepts. [See the separate answer below](https://stackoverflow.com/a/8694874/240733) for several citations taken from [there](http://web.archive.org/web/20080906224409/http://www.itmweb.com/essay550.htm).

Abstraction VS Information Hiding VS Encapsulation

Python gives us the ability to create &#39;private&#39; methods and variables within a class by prepending double underscores to the name, like this: `__myPrivateMethod()`. How, then, can one explain this

```lang-none
&gt;&gt;&gt;&gt; class MyClass:
...     def myPublicMethod(self):
...             print &#39;public method&#39;
...     def __myPrivateMethod(self):
...             print &#39;this is private!!&#39;
...
&gt;&gt;&gt; obj = MyClass()

&gt;&gt;&gt; obj.myPublicMethod()
public method

&gt;&gt;&gt; obj.__myPrivateMethod()
Traceback (most recent call last):
  File &quot;&lt;stdin&gt;&quot;, line 1, in &lt;module&gt;
AttributeError: MyClass instance has no attribute &#39;__myPrivateMethod&#39;

&gt;&gt;&gt; dir(obj)
[&#39;_MyClass__myPrivateMethod&#39;, &#39;__doc__&#39;, &#39;__module__&#39;, &#39;myPublicMethod&#39;]

&gt;&gt;&gt; obj._MyClass__myPrivateMethod()
this is private!!
```

What&#39;s the deal?!

I&#39;ll explain this a little for those who didn&#39;t quite get that.

```lang-none
&gt;&gt;&gt; class MyClass:
...     def myPublicMethod(self):
...             print &#39;public method&#39;
...     def __myPrivateMethod(self):
...             print &#39;this is private!!&#39;
...
&gt;&gt;&gt; obj = MyClass()
```

I create a class with a public method and a private method and instantiate it.

Next, I call its public method.

```lang-none
&gt;&gt;&gt; obj.myPublicMethod()
public method
```

Next, I try and call its private method.

```lang-none
&gt;&gt;&gt; obj.__myPrivateMethod()
Traceback (most recent call last):
  File &quot;&lt;stdin&gt;&quot;, line 1, in &lt;module&gt;
AttributeError: MyClass instance has no attribute &#39;__myPrivateMethod&#39;
```

Everything looks good here; we&#39;re unable to call it. It is, in fact, &#39;private&#39;. Well, actually it isn&#39;t. Running _dir()_ on the object reveals a new magical method that Python creates magically for all of your &#39;private&#39; methods.

```lang-none
&gt;&gt;&gt; dir(obj)
[&#39;_MyClass__myPrivateMethod&#39;, &#39;__doc__&#39;, &#39;__module__&#39;, &#39;myPublicMethod&#39;]
```

This new method&#39;s name is always an underscore, followed by the class name, followed by the method name.

```lang-none
&gt;&gt;&gt; obj._MyClass__myPrivateMethod()
this is private!!
```

So much for encapsulation, eh?

In any case, I&#39;d always heard Python doesn&#39;t support encapsulation, so why even try? What gives?





Why are Python&#39;s &#39;private&#39; methods not actually private?

If I understand correctly, the typical mechanism for Dependency Injection is to inject either through a class&#39; constructor or through a public property (member) of the class. 

This exposes the dependency being injected and violates the OOP principle of encapsulation.

Am I correct in identifying this tradeoff? How do you deal with this issue? 


*Please also see my answer to my own question below.*

Must Dependency Injection come at the expense of Encapsulation?

I had an interview today. I had a question from **OOP**, about the difference between **Encapsulation** &amp; **Abstraction**?
 
I replied her to my knowledge that **Encapsulation** is basically to bind data members &amp; member functions into a single unit called **Class**. Whereas **Abstraction** is basically to hide complexity of implementation &amp; provide ease of access to the users. I thought she would be fine with my answer. But she queried, if the purpose of both are to hide information then what is the actual difference between these two? I could not give any answer to her.

Before asking this question, I read other threads on StackOverFlow about the difference between these two **OOP**s concepts. But I am not finding my self in a position to convince the interviewer.

Can anyone please justify it with a simplest example? 

Difference between Encapsulation and Abstraction

Both design patterns encapsulate an algorithm and decouple implementation details from their calling classes. The only difference I can discern is that the Strategy pattern takes in parameters for execution, while the Command pattern doesn&#39;t.

It seems to me that the command pattern requires all information for execution to be available when it is created, and it is able to delay its calling (perhaps as part of a script). 

What determinations guide whether to use one pattern or the other? 

Using a strategy pattern and a command pattern

I have a project in which we often use `Integer.parseInt()` to convert a String to an int. When something goes wrong (for example, the `String` is not a number but the letter `a`, or whatever) this method will throw an exception. However, if I have to handle exceptions in my code everywhere, this starts to look very ugly very quickly. I would like to put this in a method, however, I have no clue how to return a clean value in order to show that the conversion went wrong. 

In C++ I could have created a method that accepted a pointer to an int and let the method itself return true or false. However, as far as I know, this is not possible in Java. I could also create an object that contains a true/false variable and the converted value, but this does not seem ideal either. The same thing goes for a global value, and this might give me some trouble with multithreading. 

So is there a clean way to do this? 

Good way to encapsulate Integer.parseInt()

Tried to run Run Code Analysis on a project here, and got a number of warnings that said something like this:

&gt;CA1002 : Microsoft.Design : Change &#39;List&lt;*SomeType*&gt;&#39; in &#39;*SomeClass.SomeProtectedOrPublicProperty*&#39; to use Collection&lt;T&gt;, ReadOnlyCollection&lt;T&gt; or KeyedCollection&lt;K,V&gt;

Why should I use `Collection&lt;T&gt;` instead of `List&lt;T&gt;`? When I look at the msdn documentation, they seem almost equal. After reading the error help for the warning, I found that 

&gt;System.Collections.Generic.List(T)_is a generic collection designed for performance not inheritance and, therefore, does not contain any virtual members.

But what does this really mean? And what should I be doing instead?

Should I keep using `List&lt;T&gt;` internally, and then in the properties return a `new Collection&lt;T&gt;(someList)` instead? Or should I just start using `Collection&lt;T&gt;` instead of `List&lt;T&gt;`?

C#: Difference between List&lt;T&gt; and Collection&lt;T&gt; (CA1002, Do not expose generic lists)

I have spent quite a few hours pondering the subject of exposing list members. In a similar question to mine, Jon Skeet gave an excellent answer. Please feel free to have a look.

https://stackoverflow.com/questions/491375/readonlycollection-or-ienumerable-for-exposing-member-collections

I am usually quite paranoid to exposing lists, especially if you are developing an API. 

I have always used IEnumerable for exposing lists, as it is quite safe, and it gives that much flexibility. Let me use an example here:

    public class Activity
    {
        private readonly IList&lt;WorkItem&gt; workItems = new List&lt;WorkItem&gt;();

        public string Name { get; set; }

        public IEnumerable&lt;WorkItem&gt; WorkItems
        {
            get
            {
                return this.workItems;
            }
        }

        public void AddWorkItem(WorkItem workItem)
        {
            this.workItems.Add(workItem);
        }
    }


Anyone who codes against an IEnumerable is quite safe here. If I later decide to use an ordered list or something, none of their code breaks and it is still nice. The downside of this is IEnumerable can be cast back to a list outside of this class.

For this reason, a lot of developers use ReadOnlyCollection for exposing a member. This is quite safe since it can never be cast back to a list. For me I prefer IEnumerable since it provides more flexibility, should I ever want to implement something different than a list.

I have come up with a new idea I like better. Using IReadOnlyCollection:

    public class Activity
    {
        private readonly IList&lt;WorkItem&gt; workItems = new List&lt;WorkItem&gt;();

        public string Name { get; set; }

        public IReadOnlyCollection&lt;WorkItem&gt; WorkItems
        {
            get
            {
                return new ReadOnlyCollection&lt;WorkItem&gt;(this.workItems);
            }
        }

        public void AddWorkItem(WorkItem workItem)
        {
            this.workItems.Add(workItem);
        }
    }


I feel this retains some of the flexibility of IEnumerable and is encapsulated quite nicely.

I posted this question to get some input on my idea. Do you prefer this solution to IEnumerable? Do you think it is better to use a concrete return value of ReadOnlyCollection? This is quite a debate and I want to try and see what are the advantages/disadvantages that we all can come up with.

Thanks in advance for your input.

***EDIT***

First of all thank you all for contributing so much to the discussion here. I have certainly learned a ton from each and every one and would like to thank you sincerely.

I am adding some extra scenarios and info.

There are some common pitfalls with IReadOnlyCollection and IEnumerable.

Consider the example below:

    public IReadOnlyCollection&lt;WorkItem&gt; WorkItems
    {
        get
        {
            return this.workItems;
        }
    }


The above example can be casted back to a list and mutated, even though the interface is readonly. The interface, despite it&#39;s namesake does not guarantee immutability. It is up to you to provide an immutable solution, therefore you should return a new ReadOnlyCollection. By creating a new list (a copy essentially), the state of your object is safe and sound.

Richiban says it best in his comment: a interface only guarantees what something can do, not what it cannot do.

See below for an example:

    public IEnumerable&lt;WorkItem&gt; WorkItems
    {
        get
        {
            return new List&lt;WorkItem&gt;(this.workItems);
        }
    }

The above can be casted and mutated, but your object is still immutable.

Another outside the box statement would be collection classes. Consider the following:

    public class Bar : IEnumerable&lt;string&gt;
    {
        private List&lt;string&gt; foo;

        public Bar()
        {
            this.foo = new List&lt;string&gt; { &quot;123&quot;, &quot;456&quot; };
        }

        public IEnumerator&lt;string&gt; GetEnumerator()
        {
            return this.foo.GetEnumerator();
        }

        IEnumerator IEnumerable.GetEnumerator()
        {
            return this.GetEnumerator();
        }
    }

The class above can have methods for mutating foo the way you want it to be, but your object can never be casted to a list of any sort and mutated. 

Carsten F&#252;hrmann makes a fantastic point about yield return statements in IEnumerables.

Thank you all once again.

IEnumerable vs IReadonlyCollection vs ReadonlyCollection for exposing a list member

Learning OOP concepts especially interested to understand Abstraction and Encapsulation in depth.

Checked out the below already

https://stackoverflow.com/questions/24626/abstraction-vs-information-hiding-vs-encapsulation

https://stackoverflow.com/questions/742341/difference-between-abstraction-and-encapsulation

I found very hard to understand those concepts with out a real and simple example class/code snippet.

&gt; One of my colleagues said abstraction is nothing but creating abstract
&gt; class and normal class that protects its member variable with scope is
&gt; called Encapsulation.

Is there a simple way I can understand and help others to understand what exactly they are, rather than repeating the below?

&gt; Abstraction and encapsulation are complementary concepts: abstraction
&gt; focuses on the observable behavior of an object... encapsulation
&gt; focuses upon the implementation that gives rise to this behavior...
&gt; encapsulation is most often achieved through information hiding, which
&gt; is the process of hiding all of the secrets of object that do not
&gt; contribute to its essential characteristics.

Simple way to understand Encapsulation and Abstraction

I am preparing for an interview and decided to brush up my OOP concepts.
There are hundreds of articles available, but it seems each describes them differently.
[Some][1] says

&gt; Abstraction is &quot;the process of identifying common patterns that have
&gt; systematic variations; an abstraction represents the common pattern
&gt; and provides a means for specifying which variation to use&quot; (Richard
&gt; Gabriel).

and is achieved through abstract classes.

Some [other][2] says

&gt; Abstraction means to show only the necessary details to the client of
&gt; the object

and

&gt; Let’s say you have a method &quot;CalculateSalary&quot; in your Employee class,
&gt; which takes EmployeeId as parameter and returns the salary of the
&gt; employee for the current month as an integer value. Now if someone
&gt; wants to use that method. He does not need to care about how Employee
&gt; object calculates the salary? An only thing he needs to be concern is
&gt; name of the method, its input parameters and format of resulting
&gt; member,

I googled again and again and none of the results seem to give me a proper answer. 
**Now, where does encapsulation fit in all these?**
I searched and found a [stack overflow question][3]. Even the answers to that questions were confusing
[Here][4], it says

&gt; Encapsulation is a strategy used as part of abstraction. Encapsulation
&gt; refers to the state of objects - objects encapsulate their state and
&gt; hide it from the outside; outside users of the class interact with it
&gt; through its methods, but cannot access the classes state directly. So
&gt; the class abstracts away the implementation details related to its
&gt; state.

And [here][5] another reputed member says,

&gt; They are different concepts.
&gt; 
&gt; Abstraction is the process of refining away all the
&gt; unneeded/unimportant attributes of an object and keep only the
&gt; characteristics best suitable for your domain.


Now I m messed up with the whole concept. I know about abstract class, inheritance, access specifiers and all. I just want to know **how should I answer when I am asked about abstraction and/or encapsulation in an interview.**

*Please don&#39;t mark it as a duplicate*. I know there are several similar questions. But I want to avoid the confusion among the conflicting explanations. Can anyone suggest a credible link? A link to stackoverflow question is also welcome unless it creates confusion again. :)

**EDIT: I need answers, a bit c# oriented**

  [1]: http://www.c-sharpcorner.com/UploadFile/eecabral/OOPSand.NET211102005075520AM/OOPSand.NET2.aspx
  [2]: http://forums.asp.net/t/1258933.aspx/1
  [3]: https://stackoverflow.com/questions/8960918/how-encapsulation-is-different-from-abstraction-as-a-object-oriented-concept-in
  [4]: https://stackoverflow.com/a/8960961/2401223
  [5]: https://stackoverflow.com/a/8961003/2401223

How abstraction and encapsulation differ?

### Disclaimer
Yes, I am fully aware that what I am asking about is totally stupid and that anyone who would wish to try such a thing in production code should be fired and/or shot.  I&#39;m mainly looking to see if *can* be done.

Now that that&#39;s out of the way, is there any way to access private class members in C++ from outside the class?  For example, is there any way to do this with pointer offsets?

(Naive and otherwise non-production-ready techniques welcome)

### Update
As noted in the comments, I asked this question because I wanted to write a blog post on over-encapsulation (and how it affects TDD).  I wanted to see if there was a way to say &quot;using private variables isn&#39;t a 100% reliable way to enforce encapsulation, even in C++.&quot;  At the end, I decided to focus more on how to solve the problem rather than why it&#39;s a problem, so I didn&#39;t feature some of the stuff brought up here as prominently as I had planned, but I still left a link.

At any rate, if anyone&#39;s interested in how it came out, here it is:  [Enemies of Test Driven Development part I: encapsulation][1] (I suggest reading it before you decide that I&#39;m crazy).


  [1]: http://jasonmbaker.wordpress.com/2009/01/08/enemies-of-test-driven-development-part-i-encapsulation/

Can I access private members from outside the class without using friends?

What is the precise difference between encapsulation and abstraction?

Difference between abstraction and encapsulation?

In Python, I have the following example class :

    class Foo:
        self._attr = 0

        @property
        def attr(self):
            return self._attr

        @attr.setter
        def attr(self, value):
            self._attr = value

        @attr.deleter
        def attr(self):
            del self._attr

As you can see, I have a simple &quot;private&quot; attribute &quot;_attr&quot; and a property to access it. There is a lot of codes to declare a simple private attribute and I think that it&#39;s not respecting the &quot;KISS&quot; philosophy to declare all attributes like that.

So, why not declare all my attributes as public attributes if I don&#39;t need a particular getter/setter/deleter ?

My answer will be :
Because the principle of encapsulation (OOP) says otherwise!

What is the best way ?



&quot;public&quot; or &quot;private&quot; attribute in Python ? What is the best way?

I have a class that benefits from the use of constants in its internal implementation, but I would like to limit visibility of these constants. Why doesn&#39;t PHP permit private constants?  Is there another way to achieve this or is PHP trying to discourage some type of design misstep I am ignorant of?

Why doesn&#39;t PHP permit private const?

I have been reading through the [C++ FAQ][1] and was curious about the [`friend`][2] declaration. I personally have never used it, however I am interested in exploring the language. 

What is a good example of using `friend`?

&lt;hr&gt;

Reading the FAQ a bit longer I like the idea of the `&lt;&lt;` `&gt;&gt;` operator overloading and adding as a friend of those classes. However I am not sure how this doesn&#39;t break encapsulation. When can these exceptions stay within the strictness that is OOP?

[1]: http://yosefk.com/c++fqa/
[2]: http://yosefk.com/c++fqa/friend.html


When should you use &#39;friend&#39; in C++?

In C++, I have often made a unit test class a friend of the class I am testing. I do this because I sometimes feel the need to write a unit test for a private method, or maybe I want access to some private member so I can more easily setup the state of the object so I can test it. To me this helps preserve encapsulation and abstraction because I am not modifying the public or protected interface of the class.

If I buy a third party library, I wouldn&#39;t want its public interface to be polluted with a bunch of public methods I don&#39;t need to know about simply because the vendor wanted to unit test!

Nor do I want have to worry about a bunch of protected members that I don&#39;t need to know about if I am inheriting from a class. 

That is why I say it preserves abstraction and encapsulation.

At my new job they frown against using friend classes even for unit tests. They say because the class should not &quot;know&quot; anything about the tests and that you do not want tight coupling of the class and its test. 

Can someone please explain these reasons to me more so that I may understand better? I just do not see why using a friend for unit tests is bad.

What is wrong with making a unit test a friend of the class it is testing?

I want to hide public methods from the IntelliSense member list.  I have created an attribute that, when applied to a method, will cause the method to be called when its object is constructed.  I&#39;ve done this to better support partial classes.  The problem is that in some environments (such as Silverlight), reflection cannot access private members, even those of child classes.  This is a problem since all of the work is done in a base class. I have to make these methods public, but I want them to be hidden from IntelliSense, similar to how the `Obsolete` attribute works.  Frankly, because I am anal about object encapsulation. I&#39;ve tried different things, but nothing has actually worked.  The method still shows up in the member drop-down.

**How do I keep public methods from showing up in IntelliSense when I don&#39;t want them to be called by clients?** How&#39;s that for a _real_ question, Philistines! This can also apply to MEF properties that have to be public though sometimes you want to hide them from clients.

**Update:**
I have matured as a developer since I posted this question. Why I cared so much about hiding interface is beyond me.

How to hide public methods from IntelliSense

Let&#39;s say I have a need for a simple private helper method, and intuitively in the code it would make sense as an extension method. Is there any way to encapsulate that helper to the only class that actually needs to use it?

For example, I try this:

    class Program
    {
        static void Main(string[] args)
        {
            var value = 0;
            value = value.GetNext(); // Compiler error
        }

        static int GetNext(this int i)
        {
            return i + 1;
        }
    }

The compiler doesn&#39;t &quot;see&quot; the `GetNext()` extension method.  The error is:

 &gt; Extension method must be defined in a non-generic static class

Fair enough, so I wrap it in its own class, but still encapsulated within the object where it belongs:

    class Program
    {
        static void Main(string[] args)
        {
            var value = 0;
            value = value.GetNext(); // Compiler error
        }

        static class Extensions
        {
            static int GetNext(this int i)
            {
                return i + 1;
            }
        }
    }

Still no dice.  Now the error states:

 &gt; Extension method must be defined in a top-level static class; Extensions is a nested class.

Is there a compelling reason for this requirement?  There are cases where a helper method really should be privately encapsulated, and there are cases where the code is a lot cleaner and more readable/supportable if a helper method is an extension method.  For cases where these two intersect, can both be satisfied or do we have to choose one over the other?

Can There Be Private Extension Methods?

In TypeScript 3.8+, what are the differences between using the `private` keyword to mark a member private:

```ts
class PrivateKeywordClass {
    private value = 1;
}
```

And using the `#` private fields [proposed for JavaScript](https://github.com/tc39/proposal-class-fields#private-fields):

```ts
class PrivateFieldClass {
    #value = 1;
}
```

Should I prefer one over the other?


What are the differences between the private keyword and private fields in TypeScript?

&gt; **Interviewer:** What is encapsulation and how do you achieve it in Java?
&gt; 
&gt; **Me:**  Encapsulation is a mechanism to hide information from the client. The information may be data or implementation or algorithm. We
&gt; achieve this using access modifiers. 
&gt; 
&gt; 
&gt; **Interviewer:** This is data hiding. How do we achieve encapsulation in Java?
&gt; 
&gt; **Me**: uummmm



**Concrete Question:** Other than &#39;Access Modifiers&#39;, what is the way to implement Encapsulation in Java?

All Encapsulation Solutions on Gang of Coders

Total of 26 Encapsulation Solutions

What's the difference between abstraction and encapsulation?

Why "private" methods in the object oriented?