Abstraction against encapsulation in Java

Question

Possible duplicate:
Abstraction VS Hiding information VS Encapsulation

I know that this question may have been asked thousands of times on this forum, even the network also has a lot of definitions about these concepts, but they all sound the same and use the same technical words. For example, the following definitions

Encapsulation is the process of linking or packing data and codes that work with data into a single object. This ensures data security from the external interface and misuse. One way to think about encapsulation is with a protective shell that prevents arbitrary access to code and data from other code defined outside the shell.

What I understood from the above definition is that we create variables, mark them private and generate getter-setter for these variables and use the object to access these getter and setter. Thus, the data is hidden inside the object and is accessible only through the object. I hope I'm right .

---

Abstraction is a process in Java that is used to hide certain details and show only the basic properties of an object. In other words, this refers to the appearance of the object (interface).

This is the part that always confuses me. Whenever I think of abstraction, the Abstract class comes to my mind (maybe because both have the keyword Abstract). The above definition says that abstraction means hiding data and only showing the necessary details, but this is what we already do in encapsulation, right? then what's the difference. Also, I did not understand what the appearance of the object is, it refers to the appearance of the object .

Can someone please shed more light on this real-life example or, if possible, using some programming examples.

Answer 1

OO Abstraction arises during the development of a class level in order to hide the complexity of the implementation as far as the functions offered by the API / design / system are understandable, in a way simplifying the "interface" for accessing the basic implementation.

This process can be repeated with more and more "higher" levels (levels) of abstraction, which allows you to build large systems without increasing the complexity of the code and understanding at higher levels.

For example, a Java developer can use the high-level functions of FileInputStream without worrying about how it works (for example, files, file system security checks, memory allocation, and buffering will be managed internally and hidden from consumers). This allows you to change the implementation of FileInputStream , and as long as the API (interface) to FileInputStream remains unchanged, code built against previous versions will still work.

Similarly, when designing your classes, you will want to hide the internal implementation from others as much as possible.

In the definition of Booch ¹ , OO Encapsulation is achieved by hiding information , and especially around hiding internal data (fields / members representing state) belonging to an instance of the class, by forcing access to internal data in a controlled manner and preventing direct external change of these fields, as well as hiding any internal methods for implementing the class (for example, making them private).

For example, by default, class fields can be made private , and only if external access to them is required, will get() and / or set() (or Property ) from the class be displayed. (In modern OO languages, fields can be marked as readonly / final / immutable , which further limits the change even inside the class).

An example where NO information hiding was applied (Bad Practice):

 class Foo { // BAD - NOT Encapsulated - code external to the class can change this field directly // Class Foo has no control over the range of values which could be set. public int notEncapsulated; } 

An example of using field encapsulation:

 class Bar { // Improvement - access restricted only to this class private int encapsulated; // The state of Bar (and its fields) can now be changed in a controlled manner public void setEncapsulatedField(int newValue) { if (newValue < 100) { encapsulated = newValue; } // else throw ... out of range } } 

An example of initializing an immutable / constructor field:

 class Baz { private final int onlyValue; public void Baz(int immutableValue) { // ... can check that immutableValue is valid onlyValue = immutableValue; } // Further change of `onlyValue` outside of the constructor is NOT permitted // even within the same class } 

Re: Abstraction against an abstract class

Abstract classes are classes that facilitate the reuse of commonality between classes, but which themselves cannot be directly created using new() - abstract classes must be subclasses, and only concrete (non-abstract) subclasses can be created. Probably one of the sources of confusion between Abstraction and the abstract class was that in the early days of OO, inheritance was more actively used for code reuse (for example, with associated abstract base classes). Currently, encapsulation composition is usually used in a more general sense when determining which methods, fields, properties, events, and other bundle in a class.

Quote from Wikipedia:

In a more specific setting of an object-oriented programming language, the concept is used as meaning either a mechanism for hiding information, a linking mechanism, or a combination of the two.

For example, in the statement “I encapsulated the data access code in my own class,” the interpretation of encapsulation is roughly equivalent to the Separation of Concern (S in SOLID) and, perhaps, can be used as a synonym for refactoring.

---

^{[1] _{Once you see Booch's cat image encapsulation , you can never forget encapsulation - p46 object-oriented analysis and design with applications, 2nd Ed}}

Answer 2

In simple words: you make an abstraction when deciding what to implement. You do encapsulation by hiding something that you implemented.

Answer 3

Abstraction is the definition of common features and the reduction of opportunities that you have to work at different levels of your code.

eg. I can have a Vehicle class. A Car will be derived from a Vehicle , as will a Motorbike . I can ask each Vehicle number of wheels, passengers, etc., and this information has been abstracted and identified as normal from Cars and Motorbikes .

In my code, I can often deal with Vehicles using the common methods go() , stop() , etc. When I add a new type of vehicle later (for example, Scooter ), most of my code will remain ignored by this fact, and only the Scooter implementation is concerned about the features of Scooter .