Consider a real-world analogy. All you need to start the motor bike is to put the key on, push the start button, and use the accelerator. While riding, you may need to use the brake as well.
You are not really concerned about how the engine, accelerator and brake are working during the ride. All that is abstract to you, and you are not concerned with it unless you are mechanic. Take another example - printing a document from your computer.
You are not really bothered about how the computer stores the document in 0s and 1s, nor about hoe it is transferred to the printer. Whenever we build applications, we do so in layers. Here is the layered architecture of a simple web application:. An advantage of doing so is that the Web layer does not need to know anything about the Data layer.
It is abstracted away from the Data layer. All that it needs to be concerned with, is that it can delegate requests to the Business layer, and the business layer would take care of rest of the flow.
Layering in an application is, in a way, abstracting away complexity. I could have implemented some class representing the carriers, use them in some of my country label class using composition, and I would have never created bloated abstract class painful to scale.
Thankfully you can learn from my mistakes! I took some time to define abstraction at the beginning of this article partly because I heard some weird definitions. For some, an abstraction allows you to replace part of your implementation with something else, thanks to an interface construct or an abstract classes.
From the Oxford dictionary :. In computing, it means calling something using one or multiple middle man. Parser is an interface construct, so the method Exporter::export call parse on an interface construct. At runtime, YamlParser will be used, but indirectly. Is this interface an abstraction? Well, it hides the implementation details of the concrete class YamlParser , so it looks like it is! Yet, each class implementing Parser must implement every single of its method, which is basically the totality of the behavior of the class YamlParser.
There is a relationship between the interface construct and the class which implements it. You would need to push one to open or close the valves, another one to move the drum, another one to pour the washing liquid on your clothes.
Can we still call that a simplification? Not really. What about generalization? Well, it will be difficult as well, since everything needs to be implemented in every case. At the end, this interface construct is more about indirection than abstraction. Indirection can bring flexibility: we can always swap the YamlParser used in the Exporter by something else, like JsonParser. However, it brings complexity as well, as I pointed out in another article. Levels of indirection can be difficult to comprehend at once when you need to do some change in your codebase.
Our brain is not good to reason on many layers of indirection. The world is a very complex place. We abstract away many things, all the time: what we see and feel is abstracted by our senses and our brain. However, abstractions can fool us, believing that we know things, based on our experience, even if the details of these experiences are washed away for our own good.
My experience showed me that a deep knowledge about the different layers of abstraction in computing is the best tool you can have to develop robust solutions and answer the most complex problems. Today, I would like to go with you on a deep dive in the world of abstractions. We will: Define what an abstraction is, illustrated with examples. Cover what are the different sorts of abstraction you can find in software development.
Analyzing the obvious benefits of using abstractions, but as well their drawbacks. Understand the difference between abstraction and indirection, two concepts tightly linked, but still different. Well, well, well. We have now gathered the three main properties of an abstraction: The concept of hiding , or removing. The concept of generalization. The concept of idea versus reality.
These three concepts will come back very often in this article. Wonderful Washing Machines The concept of abstraction is not only for software engineering. Now, look intensely to your washing machine. I know you always wanted to. What do you see? The reality is what happens inside the washing machine itself. We come back to the three properties of an abstraction, as we defined it above: Hiding useless information.
Generalizing a concept. Dealing with an idea representing the reality. Maps have some general conventions, some ways to represent the same things. The topography will be lines with numbers, to represent the elevation, for example.
A map is an abstract idea of a portion of land. A pure representation, which can differ from map to map. Related to maps, there is this famous quote by Alfred Korzybski : The map is not the territory It means that abstractions are not the objects they abstract.
Your Application is an Abstraction of an Abstraction of an Abstraction Abstraction can be layered, that is, you can abstract an abstraction.
We could come up with this list of abstraction layers : User interface. High-level language PHP, for example. Low-level language C. Machine language. Circuit elements logic gates. Solid-state physics. Quantum mechanics. Everything else is nicely abstracted.
Types of Abstractions in Software Engineering Now that we defined what an abstraction is and what are its main three properties, let see what are the abstractions available to us in our programming languages. A complete mess nobody grasps most of the time. Data and control flow. Exotic naming conventions and whether we should use space instead of tabs. The good answer is 2. Data is the information stored somehow on a computer.
Behaviors process the data and possibly transform it, overtime. Another modern prime example of abstraction is illustrated in the application programming interface API , which is so prevalent in cross-platform systems. The API is a key way to provide that abstraction information so that outside third parties don't need to know as much about an inherent codebase.
The API, then, functions as the key vehicle of abstraction by building in those object-oriented principles that show the "outside program" what the "inside program" is doing.
In closing, abstraction is simply the process of making codebase information more versatile by simplifying how it's represented in external systems. That, however, has led to massive tech advances preceding other kinds of core change like the move toward virtualization of networks. By: Brad Rudisail Contributor. By: Kaushik Pal Contributor.
By: Leah Zitter Contributor. Dictionary Dictionary Term of the Day. Decentralized Finance. The student uses SAT scores to determine a good match. The student has abstracted complexity when it comes to choosing a college. There are actually many factors in choosing a college, but the student has chosen to focus on SAT scores. I want to launch a missile, loaded with 10, liters of peanut butter, at my friend because it would be funny. There are hundreds of important variables associated with launching, flying, and hitting a target in this example.
Please think for a moment how we could construct an abstraction. We could create a giant red button with the words "launch peanut butter missile at friend" which would launch the missile.
0コメント