Abstraction in Software Design

Abstractions are the most fundamental elements and the most important tenet of Software Design.
Yet, most of us can't explain it, or can't recognize good from bad abstractions. In this video I attempt to explain how to design abstractions as well as how to recognize weak and strong abstractions and when to even attempt to abstract.

Adapter Design Pattern (Code referenced in this video)

00:00 Intro
01:24 Don't Rush to Abstract
03:06 What is an Abstraction?
03:38 Too Much or Too Little Abstraction
04:45 Strong and Weak Abstractions
06:14 Purpose and Correct Level of an Abstraction
08:38 Too Little or Leaky Abstraction
09:15 The Right Level of Abstraction
09:51 An Example - Message Broker
12:31 Methods are Abstractions
13:23 Don't Rush to Abstract - Rule of Thirds
14:10 Don't use Bool arguments
15:50 Wait before you Lock Yourself into a Solution
17:06 Abstraction in Class Design
19:35 Code Example - Message Broker Abstraction
32:04 How to arrive at a Good Abstraction
33:03 Code Example - CosmosDb Abstraction
34:32 Graphs and Charts Abstraction
35:59 Clean Abstraction last longer
37:29 Code Example - CosmosDb Abstraction Continued
41:11 Abstractions work for you and not what they're hiding
42:22 Example of a Bad Abstraction
45:46 Too much Abstraction
45:57 Conclusion

[thisgavemegoosebumps]

Brilliant! As always! I'm extremely happy that you decided to dedicate a couple more lessons to the topic of abstractions.

[atabayilker]

One of the most underrated coding channels on youtube. I love your content and your way of teaching. Do you have any classes on Udemy or similar platforms or did you ever consider doing something like that?

[haaniniyaz]

I'd love to see you do a reflection of the book a philosophy of software design.

[CodyEngelCodes]

I like Sandi Metz’s acronym “AHA” which is avoid hasty abstractions. It’s perfectly fine to duplicate code if you can’t see the right abstraction. The wrong abstraction is incredibly costly. I think that single thing changed the way I write software.

[sohamjoshi]

Most of the abstraction being talked about here is in the context of creating decoupled interaction through detail hiding. However Abstraction is a much deeper concept.. eg: in an ecommerce website a person in the real world is represented as a Customer. Even the Customer is an abstraction of a real person in CONTEXT of ecommerce, however its not related at all to decoupling.

The act of abstraction is a tool to reduce entropy of a system (which is same as creating information gain in the domain/context being modeled which Eric Evans, the founder of DDD calls knowledge crunching).

Stephen wolfram's book A new kind of science illustrates beautifully the fact that most complexity in nature arises from simple rules. As software developers when we design abstractions and get components to interact, we are just writing the rules with which the objects will interact at runtime. Abstractions are a beautiful tool to write these rules which basically reduces entropy in the context of future changes to the software, all of a sudden it becomes very easy to change the system when the right abstractions are in place.

[ghevisartor]

15:51 This happened to me in one of my first project, where i needed difference types of products in the same list. I made three difference MakeProduct() methods, one for each type, and return them as the base class. In the UI i just needed the base class properties and then when one of the products was clicked, a (Blazor) component with the child type would appear with its specific details plus repeating the base class ones.
The first temptation was to make a big switch on just one method. But this happened because i suspect i have a poor grasp of what goes into the component and what in the viewmodel. Also because viewmodel can be reused elsewhere. Anyway im going off topic. Great video! Very helpfull.

[sunkarasureshkumar]

Awesome!! video as always Shiv. Please let us know what theme is that you using in vs?

[brainoverflow]

About your charting library example. Let's say you have created an abstraction for a specific type of chart and later you realized you need a bit customization for a different use case. You have two options either to create a completely different method or add a "boolean" parameter to your method. Second option at the end might lead you to an abstraction interface that is more complicated than the actual library. But the first option might lead you to too little abstraction because you will almost create a separate method for each different functionality in that specific library. Sometimes I feel like it's best not to create an abstraction around those utility libraries until I decide that there will be multiple implementations of the similar library in my system. Or at least I should understand what are the exact use cases that might appear in my system. Which might be more understandable as the project reaches the version 1.0 but can never know what will come. Abstraction looks simple but is not an easy one for sure :D

[rossthemusicandguitarteacher]

Rule of thirds sounds great. Uncle bob also warns against booleans as arguments

[saurabhchauhan]

I would pay a ticket to attend/listen this 😀.
Thank you for explaining such a topic, was get confused with abstraction but this video and Eval of abstraction really helped me. This is another nugget from your channel.

Apart from this at last in video you have asked gateway vs facade, that something I asked gateway vs adapter, I felt both trying to get in hand to hand but different intention, so with again CosmosDB why gateway and not adapter. I have watched both videos multiple times though this is something confused ne because gateway and adapter help you to talk in domain/application language. Please correct me if I am wrong.

Thank you !

[danielvillalba]

Again this is a great and quite hard to wrap around topic explained in a really easy to understand and follow manner, thanks for that Shiv.

Another guideline I like to follow to identify the right level of abstraction is how easy a specific component is testable, would it be fair to say that it is a good guideline perhaps?

[MrJonnis]

Hi Shiv,

Thank you for yet another great, down to the reality video.

How would you differentiate "Abstraction" to "Encapsulation" ?
If Abstraction tries to hide the complexity, in the Domain context,
is Encapsulation just the "how" to implement the Abstraction by hiding the internals (private methods and private properties) ?
In other words, you make use of Encapsulation in order to implement your Abstraction ?

[AnotherFancyUser]

This happens to me (where you start saying that we want to do very generic stuff). I don't know why I'm fascinated by it, to create interfaces, generic interface, generic classes that can do stuff, etc, like a mini framework. It is true, it obscures the understanding. If you are coding an application that is not going to change that much then you don't need all those fancy interfaces of type T where T : etc etc, or use reflection and use convention over configuration to create strategies... (without if statements) it is too much.

[johanlarsson]

And then you just have something that is using the Contract/interface IDisposable in the program. So the program that instantiates this would have a "MessageBus" of type IDisposable, and that would then simply use Subscribe, Acknowledge, Dispose methods since all, irrelevant of implementation, the contract says all types of subclasses have those.

Dependency inversion :)

[adaobiokoye]

hello! please can i know the problems we face when developing an abstract system?

[martonbalassa]

Guiding principles by level of coding experience
Beginner - DRY
Advanced - SOLID
Senior - YAGNI
:D