Abstraction Abstraction is one of the four fundamentals of Object-oriented Programming

Abstraction is the concept which enables you to model an otherwise complex real life entity in a simpler way that our limited brains can understand. Abstraction is core to modeling sofware systems. It means to concentrate on the necessary things and highlight the ones which are crucial to solving the problem at hand, without worrying about the details which are not relevant to the problem hand.[1] Abstraction is about hiding unwanted details while giving out most essential details, while Encapsulation means hiding the code and data into a single unit e.g. class or method to protect inner working of an object from outside world. In other words, Abstraction means extracting common details or generalizing things.[2]

Abstraction lets you focus on what the object does instead of how it does, while Encapsulation means hiding the internal details of how an object works. When you keep internal working details private, you can change it later with a better method.[2]

Abstraction focus on outer lookout e.g. moving of vehicle while Encapsulation focuses on internal working or inner lookout e.g. how exactly the vehicle moves.[2]

What does that mean?[1]#

Assume you have to model Prakash, Sendhil and Manu for a payroll processing system. Prakash, Sendhil and Manu can be modeled as objects. These can be classified under the Employee class. This Employee class is an abstraction representing the real world entities Prakash, Manu and Sendhil in the context of a Payroll processing system. Their basic pay, joining date, bonus pay, incentive, hours worked or each of the months will be attributes of the Employee class. But what about the other details about Prakash, Sendhil and Manu like what languages they know, what frameworks they have worked on, what is their experience level in each of these skills etc. These completely irrelevent with respect to the Payroll system. But these might be completely relevant in a Skill management system. Abstraction also in modeling context could mean leaving out / hiding the implementation details in the early stages of the model lifecycle or in the high level architecture of the system so that one can get the big picture. But we are just hiding these implementation details, these have to be there in some other view of the model. This is especially crucial if dont want to throw the model away after understanding the system. This makes sense if you want to do model driven development. As a non software example, consider the braking system of your car. As a driver of the car you just need to know that pressing the brake pedal, applies the brake and stops your vehicle. That’s the details you should know about the brake to use it. On the other hand a mechanic needs to work with the braking system at a different level of abstraction. He needs to know how it works. Is it a disk brake, or is it a drum brake. How do the hydraulics work etc. In other words he works at a different level of Abstraction.

More Information#

There might be more information for this subject on one of the following:

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-6) was last changed on 18-Apr-2017 12:07 by jim