!!! Overview
[{$pagename}] the quality of dealing with ideas rather than specific events.


[{$pagename}] in its main sense is a conceptual process where general rules and concepts are derived from the usage and [classification] of specific [examples], literal ("real" or "concrete") signifiers, first principles, or other methods.

[{$pagename}] is the process of removing physical, spatial, or temporal details or [attributes] in the study of [objects] or systems in order to more closely attend to other [Item of Interest] ([IOI])

[{$pagename}] maybe performed for [Applications] or any process.

[{$pagename}] and [Refinement] are complementary concepts.

!! [Software development]
[{$pagename}] is one of the four fundamentals of [Object-oriented Programming]


[{$pagename}] 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 software 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]
 
[{$pagename}] 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, [{$pagename}] means extracting common details or generalizing [things].[2]

[{$pagename}] 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] 

[{$pagename}] 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 [{$pagename}] 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.
 
[{$pagename}] 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 [{$pagename}].

!! [Monolithic Architecture], [Microservice], [Functions as a Service]
When [Mainframes] were the beginnings of computing. The perfect concept of a [Monolithic Architecture]. 

We [Abstracted|Abstraction] our [Personal Computers] to provide more flexibility.

We then [Abstracted|Abstraction] used the [Hardware Abstraction Layer] to [Abstract|Abstraction] our software from the hardware

We then [Abstracted|Abstraction] our [Operating System]using [Operating-system-level virtualization] ([Containerization]).

We then [Abstracted|Abstraction] our [Applications] through the use of [Application Programing Interfaces] ([APIs]).

We then [Abstracted|Abstraction] our [APIs] through the use of [Microservices]

We then (or now) [Abstracted|Abstraction] Microservices] to [Functions as a Service]


!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [Four Tenets of OOP|https://codingarchitect.wordpress.com/2006/09/27/four-tenets-of-oop/|target='_blank'] - based on information obtained 2017-04-18
* [#2] - [Head First Object-Oriented Analysis and Design|https://codingarchitect.wordpress.com/2006/09/27/four-tenets-of-oop/|target='_blank'] - based on information obtained 2017-04-18