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?
Thask you you for your kind words Atabay! Appreciate you taking the time to let me know. I don't have content anywhere else yet. But this year, I do plan to do something about that.
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.
You may want to look at my video on the "Factory Method Pattern". (different from Factory Pattern). You're probably using the Factory Method pattern unknowingly!
Thank you Ross! It sounds like a mundane rule but I'm reality it has saved me and my teams many times from being locked in to a refactor/abstraction that would not have served us in the long run.
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.
I complete agree with this, to use nature in understanding this: Imagine you are some sort of God, you need to create plants, trees. you could create particular plants and trees (Concretions) another thing that you can do (and in fact nature works this way) is to make a function that feeds itself of the output of that function (A Fractal, the abstraction) so now with different types of functions (Concretions that have a can/do contract with the IFractal abstraction) you can create whatever plant/tree you want and if all functions looks the same but have different coefficient, constants, etc, then an abstract class may help as you have implementation details. That is how plants and tree grow, they follow a fractal pattern, same our bodies, etc.
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 ?
Thank you for you kind words Johnny! Much appreciated. Encapsulation's basically meant data hiding. But for me it has mean hide implementation details. So yes, if something (properties/methods) need not be public then hide them. So one (Encapsulation) hides implementation, while the other hides complexity but surfaces a simplified interface.
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
Hi Halil. Here's what I think.... Whenever I'm working with third party libraries I generally have an abstraction. These libraries generally have: 1. Way more functionality than I need 2. Their "language" is not the language of the business. So my abstraction will provide my system with just those methods I need and in the language I need them in. The implementation will also account for special things the library may need that I don't care to allow to leak into my system. I'm not trying to build a reusable abstraction. I'm simply trying to abstract. I do this almost always. So the motivation for this is simply needing something that talks in my language and in my terms (my data types, etc.). When I use the Microsoft SDK for CosmosDb, Blob Storage or ServiceBus, I do this all the time because not only is their feature set too vast, there are many ways to achieve the same thing and the abstraction implements using the best of the possible options. I only write code for what I *know I need now/today*. I don't ever bother about accommodating what may happen in the future. This keeps things very simple and simple things are easy to change. I think we're on the same page, mostly :)
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?
Thank you Daniel! Personally, I don't consider testability to be litmus test for anything other than testability :). That's just me. Because I don't care to test components/classes. I test the entire system to ensure, what I'm delivering meets the requirements and acceptance criteria. As regards abstraction, I believe classes need to be black boxes. As a result, I'm don't care to know what their dependencies and so if classes expose their dependencies I believe that's a leaky abstraction. So for the code examples I give in this video, if the CosmosDbGateway were to expose its dependencies that it would no longer be a clean abstraction :). I know, this probably goes against everything to know/believe :). My experiences, however, have taught me (correctly or incorrectly) that DI is a bad idea. So I've been a convert ever since.
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.
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.
I like that! AHA. You have an Aha moment :). I think if you do this long enough we'll all have similar awakenings as long as we're "Open for extension AND Open for modification"!!
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 :)
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 !
A gateway is used when you want to talk to a service. An adapter is generally used for other things that are not related to talking to a service. It like the keys to your home are called keys. Your login credentials to your computer are called credentials. But they are both "keys" are they not? They both allow you access to something. Bit would it make sense to you if I asked you to use your key to access your computer? Of course these days we do have access keys for computers😏. But I hope you understand my point. The terms we use help up immediately distinguish one from the other. If while talking to you I asked you to use a gate for some service you'll realize the when it comes to implementation. The gateway has very specific roles and responsibilities pertaining to accessing a service. Watch the video again if you're not sure what I mean. While the adapter is a general concept and essentially is an example of a good abstraction. So a gateway then a specialization of the adapter because it is used for a specific purpose and has rule specific to that purpose as well.
@@Matlus Abstract systems are non-physical entities or conceptual that may be formulas, representation or model of a real system. What are the problem we face when developing such systems pls?
@@martonbalassa8128 me too! Bit I quickly learnt that I was getting trigger happy. YAGNI,is the mantra to follow as I mentioned in the Video. Or rule of thirds is perfect because generally get a deeper insight the more you know about what you're doing and where the system is headed.
![Cody Johnson - I'm Gonna Love You (with Carrie Underwood) [Official Music Video]](http://i.ytimg.com/vi/yy9PuYMU29g/mqdefault.jpg)
![Yailin La Mas Viral, @kreizyk.official - Dale 2 (Remix) [Video Oficial]](http://i.ytimg.com/vi/JaYHBzgqz94/mqdefault.jpg)
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?
Thask you you for your kind words Atabay! Appreciate you taking the time to let me know.
I don't have content anywhere else yet. But this year, I do plan to do something about that.
Looking forward to it ☺️
@@Matlus good news!
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.
You may want to look at my video on the "Factory Method Pattern". (different from Factory Pattern). You're probably using the Factory Method pattern unknowingly!
Rule of thirds sounds great. Uncle bob also warns against booleans as arguments
Thank you Ross! It sounds like a mundane rule but I'm reality it has saved me and my teams many times from being locked in to a refactor/abstraction that would not have served us in the long run.
Absolute gold
Thank you Roos. I'm glad you think so, which means my attempt at trying to explain abstraction wasn't too shabby!
This is very insightfull. Thanks sir!
Glad you enjoyed it!
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.
I complete agree with this, to use nature in understanding this:
Imagine you are some sort of God, you need to create plants, trees. you could create particular plants and trees (Concretions) another thing that you can do (and in fact nature works this way) is to make a function that feeds itself of the output of that function (A Fractal, the abstraction) so now with different types of functions (Concretions that have a can/do contract with the IFractal abstraction) you can create whatever plant/tree you want and if all functions looks the same but have different coefficient, constants, etc, then an abstract class may help as you have implementation details.
That is how plants and tree grow, they follow a fractal pattern, same our bodies, etc.
@@AnotherFancyUser yes that sounds right.. there is definitely hints of this fractal structure all over the place..
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 ?
Thank you for you kind words Johnny! Much appreciated.
Encapsulation's basically meant data hiding. But for me it has mean hide implementation details. So yes, if something (properties/methods) need not be public then hide them.
So one (Encapsulation) hides implementation, while the other hides complexity but surfaces a simplified interface.
Great content Shiv.
Thank you Zamansmail! Glad you think so.
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
Hi Halil. Here's what I think....
Whenever I'm working with third party libraries I generally have an abstraction. These libraries generally have:
1. Way more functionality than I need
2. Their "language" is not the language of the business.
So my abstraction will provide my system with just those methods I need and in the language I need them in. The implementation will also account for special things the library may need that I don't care to allow to leak into my system.
I'm not trying to build a reusable abstraction. I'm simply trying to abstract. I do this almost always. So the motivation for this is simply needing something that talks in my language and in my terms (my data types, etc.).
When I use the Microsoft SDK for CosmosDb, Blob Storage or ServiceBus, I do this all the time because not only is their feature set too vast, there are many ways to achieve the same thing and the abstraction implements using the best of the possible options.
I only write code for what I *know I need now/today*. I don't ever bother about accommodating what may happen in the future. This keeps things very simple and simple things are easy to change.
I think we're on the same page, mostly :)
@@Matlus "I'm not trying to build a reusable abstraction. I'm simply trying to abstract." good approach I'll keep in mind.
Awesome!! video as always Shiv. Please let us know what theme is that you using in vs?
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?
Thank you Daniel!
Personally, I don't consider testability to be litmus test for anything other than testability :). That's just me. Because I don't care to test components/classes. I test the entire system to ensure, what I'm delivering meets the requirements and acceptance criteria.
As regards abstraction, I believe classes need to be black boxes. As a result, I'm don't care to know what their dependencies and so if classes expose their dependencies I believe that's a leaky abstraction.
So for the code examples I give in this video, if the CosmosDbGateway were to expose its dependencies that it would no longer be a clean abstraction :).
I know, this probably goes against everything to know/believe :). My experiences, however, have taught me (correctly or incorrectly) that DI is a bad idea. So I've been a convert ever since.
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.
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.
I like that! AHA. You have an Aha moment :).
I think if you do this long enough we'll all have similar awakenings as long as we're "Open for extension AND Open for modification"!!
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 :)
I'd love to see you do a reflection of the book a philosophy of software design.
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 !
A gateway is used when you want to talk to a service. An adapter is generally used for other things that are not related to talking to a service.
It like the keys to your home are called keys. Your login credentials to your computer are called credentials. But they are both "keys" are they not? They both allow you access to something. Bit would it make sense to you if I asked you to use your key to access your computer?
Of course these days we do have access keys for computers😏. But I hope you understand my point. The terms we use help up immediately distinguish one from the other. If while talking to you I asked you to use a gate for some service you'll realize the when it comes to implementation. The gateway has very specific roles and responsibilities pertaining to accessing a service. Watch the video again if you're not sure what I mean. While the adapter is a general concept and essentially is an example of a good abstraction.
So a gateway then a specialization of the adapter because it is used for a specific purpose and has rule specific to that purpose as well.
@@Matlus Thank you for explaining.
@@saurabhchauhan232 You're welcome Saurabh.
hello! please can i know the problems we face when developing an abstract system?
Sorry, I don't understand your question. What do you mean by abstract system? I'll need a lot more information to being to help, I'm afraid.
@@Matlus Abstract systems are non-physical entities or conceptual that may be formulas, representation or model of a real system. What are the problem we face when developing such systems pls?
@@adaobiokoye3593 Sorry, I haven't got a clue about what you're talking about. This video is about abstraction in software specifically.
Great video
Glad you enjoyed it
Guiding principles by level of coding experience
Beginner - DRY
Advanced - SOLID
Senior - YAGNI
:D
Beginner: YAGNI
Advanced: YAGNI
Senior: YAGNI
Throw away SOLID and DRY :)
@@Matlus it's easy to see that in retrospect, but when I was a beginner, extracting a method was an epic win.
@@martonbalassa8128 me too! Bit I quickly learnt that I was getting trigger happy. YAGNI,is the mantra to follow as I mentioned in the Video. Or rule of thirds is perfect because generally get a deeper insight the more you know about what you're doing and where the system is headed.
Brilliant! As always! I'm extremely happy that you decided to dedicate a couple more lessons to the topic of abstractions.
Thank you! I still feel something is missing. But I'll wait till a encounter an example at work to make another video on the subject