Developers work with complex systems. Each of those systems is complex on its own, and the interactions between them can become complex as well.
One way to deal with the complexity is to abstract those systems. We don’t need to know the implementation details to be able to work with them.
By using abstractions, we reduce complexity and reduce the possibility of mistakes.
Out of sight, out of mind!
Good abstractions are simple, descriptive, and easy to use, and do what you expect them to do.
Bad abstractions do too little or too much, are hard to work with, or leaky.
The hard part is to get the abstraction right. If it does not abstract enough, it is not useful. If it abstracts too much, it probably does too much.
Abstractions are not limited to computer science, and come in different
shapes and forms:
- Interfaces, methods, classes, services..
- Buttons, knobs..
Example 1: You are working on ProductService and need to load products from the database. Then, you use abstraction IProductRepository.Get(productId) to get the product, while hiding the actual implementation details of it.
What you care only about is getting the product.
What you don’t care about is SQL queries, tables, connection strings, etc.
Example 2: Sending data over the internet. We simply invoke a method on HttpClient. Do you know the 7 layers of TCP/IP protocol? I don’t. They are abstracted away.
Example 3: Driving a car. Press the gas pedal, the car goes faster. The pedal is the abstraction. The motor and its inner workings are abstracted away, and we don’t waste a second thinking about it. Otherwise, there would be much less drivers on the road.