Abstraction in Software Design

what's up youtube abstractions are one of the most fundamental elements and the most important tenet of software design yet most of us don't know what they are most of us can't explain to anyone what abstractions really are and most of us can't discern good from bad apps actions so here we are in a field where as i said abstractions are a key tenet of software design yet we can't teach it some people have tried i've certainly tried myself as well most people can't explain it i've tried myself well and you'll see my effort in this video so i'm hoping to do a good job of trying to explain to you abstractions so i'm going to start with what they are i'm not going to go through major definitions but just to understand at a high level what an app session really is or intended to be and then through the course of this video i'm going to show you different examples code examples and give my explanation of the reasoning for why something is a good or bad abstraction or why a certain abstraction is the way it is in terms of the code that you see with the hope that this exercise or this video is going to help you discern good from bad abstractions or leaky abstractions or good abstractions and or too much or too little abstraction these are all the flaws or problems i see with people creating or defining their own abstractions as important as abstractions are and as helpful or useful as a good abstraction is what's better than a bad abstraction what's better than a bad abstraction is no abstraction in other words what i'm saying is if you're not sure about your abstraction or the level of abstraction or whether it's a good or bad abstraction over this leaky abstraction just don't try it maybe this is not the time to do the abstraction and which is actually been most often the case i find people are rushing to make an abstraction yet they don't really have a good grasp of what is it that they are trying to do and what that abstraction needs to look like it's too early in the design phase or too early in the implementation phase where you're attempting an abstraction and you're going to miss the mark you're going to make a bad abstraction and that is going to be worse than not having one in the first place i'll try and explain that to you during the course of videos to how or when you should be going down the path of creating an abstraction but i'm also going to be giving you a basis or a foundational understanding i hope of looking at how or when or why you should be creating an attraction in the first place and then kind of going down a certain path and missing all the bad if you will you know because you have certain ideas in mind now i'm going to try them apart to you certain i won't call them guidelines or or rules or whatever but just just call them guiding principles of how to design an abstraction and therefore if you do that well enough you could still get a bad abstraction but i'm hoping that will help you there all right so let's get started with the uh definition simple simplified or simple definition of one abstraction i think it's good dijkstra i'm hoping i'm saying that correctly it's good dijkstra i think some the danish would say that i think he's dutch said the purpose of an abstraction is not to be vague and he must have said that because he's really experienced many people trying to make an abstraction that goes really big and i see the same thing till date that's the problem these vague attractions we'll talk about that so the purpose of an abstraction is not to be big but rather to provide a simplified meaning of something to be more precise that is saying a lot if you understand abstractions if you or you can discern good from bad abstractions or too much or too little absolutely what he's saying is get to the right level of attention not too much but also not too little and definitely not vague a vague abstraction is trying to be more generic and this is the biggest problem i see with abstractions people are trying to make this one wonderful abstraction that can do pretty much anything they want to do today in the future and for the whole you know software programming community don't bother please don't try that that is too big an abstraction it doesn't help all right it's okay for some libraries and we discuss some of that where for libraries you want to be less precise because the library is trying to give you more options but when you're building an application and you are designing your own abstraction you are not hopefully not trying to be vague you you're trying to be precise not too precise but the right amount of precise so let's try and understand the level of abstraction of what that means too much abstraction and too little abstraction right there are also other terms weak and weak and strong abstraction or good and bad abstractions they get unnecessarily confusing but i think too much too little might need an explanation so that as i move forward to this video i'm using them in the right manner so that you can understand what they mean all right so there's a spectrum of abstraction can you see man that's too little at least from my perspective yeah even from your perspective actually too little abstraction and too much abstraction so what's the right level of abstraction then in the middle no well let's first define what is too much or what is too little imagine you're doing something with some some class or some that's the file system if you create too much of an abstraction you're almost not even sure what it is you're doing exactly right it's becoming vague and big the the too much of an abstraction is becoming bigger and bigger if there's a term bigger it's it's becoming too obtuse it's becoming too generalized too generic too little abstraction is keeping you so close to the actual implementation of what's going on behind the scenes that you're not getting much of an abstraction right so that's too little too much is kind of the vague side as dijkstra said you know the the purpose of an abstraction is not to be vague to be more precise which also means not exposing or hiding enough of the complexities which is what the purpose of an application is is to hide the complexity of a certain thing or certain you know implementation while giving you an interface if you will a public surface that is more useful hiding the complexities and yet keeping the interface useful that usefulness is that is that usefulness at the right level of abstraction is it too little like then you're still exposed to some of the inners and the inner workings of what that complexity is and this is kind of a leaky abstraction or is too much meaning it's so vague you have no idea what it is you're doing for example you know if i'm trying to build an abstraction for a database i could use terms like database or datastore or storage you follow that the name is becoming more and more vague storage what could it be now you you may be your intention is to be big minister in the sense that in this particular application you're for some reason valid reason trying to hide the fact that the data comes from a database maybe it could come from an in-memory store or a cache or blob storage or something and so the reason for why you're being vague in the naming is because you're intending not because of a future possibility but you know now that's the problem with abstraction defined they become vague because people are imagining all kinds of future possibilities and that generalization the bigness becomes you pay a cost for that you pay a very heavy cost in the sense of people trying to complain and understand your system you was the person that designed the system might know and understand it but others are having a hard time getting to give to that big abstraction unless that's the requirement see so if everyone understands that yes we are working with the database but we also could be working with a memory cache we could also be working with azure blob storage or something it's a well-known and understood thing in the application on the team that we need that level abstraction where we are being vague about our storage we just call it storage we don't call it data store or database some abstraction if that's needed so at that point you're getting more of the strong side of abstraction but yet if it's useful it's useful if the application id requires it now i can see the need now i'm not imagining a future name right too little of an abstraction will not allow you to in this particular case allow you to be able to implement different implementations ones that go against the cache versus ones that go against the database versus ones that go against like azure blob storage to apply or do the same thing right so too little also have becomes sort of leaky and i'll explain what leaky abstractions are there's many ways to look at leaky i'm going to describe probably one aspect of a leaky abstraction because i think that's the one that is the most common one that people find i find when i look at people's abstractions they're not clean abstractions they have something is some issue with them so the a good abstraction at least in from an object-oriented design perspective a good abstraction is choosing the right level meaning too little to too much right level abstraction retaining the detail required from a domain point of view in other words you are building an abstraction for the purposes of your domain for whatever application you're building whether it's a game or a business system whatever that domain is is specific to the domain and of course in this specific particular case also specific to the application you're building and for the need of that abstraction with regard to your domain for example i'm and i'm going to show you an example of that here by in code i need to use a message broker message brokers allow you to publish to messages to certain topics exchanges allow you to subscribe to certain queues or subscriptions depending on what methodology you're using at high level to perform these two functions but within a system that is in this pub sub published subscribe architecture there are many applications within the many microservices if you want to call them that that only publish they don't subscribe there are others that only subscribe don't publish and there are some who publish and subscribe so for the one application that only needs to publish does it need an abstraction that talks about subscription and of course not and conversely if the for the other bunch of applications that need to only subscribe but not publish do they need to know about publish no so the right level of abstraction for the applications that are doing the publishing is the fact that they don't have to know about or get modeled with subscriptions and conversely on the other side those applications that do the publishing but also do the subscription shouldn't have to know about the subscription sorry to the subscription but don't know the publishing don't know about the publishing but just know about the subscription so it's picking the right level of abstraction not too much not too little it's certainly not in the middle right which might be an easy way to say it's always in the middle no it's not it's it depends where you're trying to get at so i'm saying in the case of the publisher only application you're going more towards the stronger abstraction this is the right level for the application that requires both publish and subscribe you're literally like in the middle somewhere because you're weakening the abstraction in the sense that your same is published and subscribed and if you look at each of those they may be at the same level i mean the publishing functionality might be the same level as the application that does only the publishing which again i'll show you in this code here i don't want to get you to model with to be just talking right so we've at a high level giving you kind of the description of what an abstraction is and i've tried to explain there are things like good and bad abstractions or too much or too little abstractions and also from the perspective of objective programming picking that right level abstraction exposing the right amount of detail and it's domain specific these are the key aspects moving forward i think keeping in mind that you are building this application for this specific domain for your specific needs don't try and generalize for the whole software community or your whole organization abstractions should be specific to the application don't start too early in this idea of building an abstraction people i find too quickly in transformation especially uh methods methods and abstractions too are they not you are saying here's a method give me some information i'll do all the stuff for you you don't need to know how to do it same idea you're providing a level of abstraction by way of your method signature hiding all the complexity of the implementations and thus methods are your first kind of abstraction that you'll be building in software right classes are the next level but if you remember my few of the talks api design principles method design principles they all talk about the same thing if you can design methods correctly you can design classes correctly for the same exact reason if you can decide the proper level of abstraction at the method level then your classes will be the right level too right from method standpoint i've seen people are rushing to make a generalized generic method like they make one and while they're making the one they're imagining other uses for that one and so they start to add additional parameters to make it parameterized the method to make it more generalized don't do that even if you copy paste that method two to three times it's fine i have a rule of thirds and something that goes to rule of fours which is if you copy paste it for the third time that's the time to sit back and think about okay now that i've used this copy basis method three times what should i do now to refactor it to make it more abstract right more generalized but it may not three may not be enough and if the way you implement the abstraction or generalization is by adding more arguments especially both bold method arguments are not allowed in my my systems this is it's indicative of this problem that you are trying to generalize a method and you're adding both arguments and sometimes more than one and this is all this conditional logic in this one method that's trying to be generalized this is faking the generalization if that makes sense to you you are implementing a method with lots of if else conditions to give the impression to the outside that your method is generalized i don't like those kinds of abstractions i like cleaner abstractions where the method signature is not changing because of the fact that you are having to do different implementations and as a result i certainly got bull and they could be maybe like an enum or something which is a little more useful but even that would be suspect polymorphism is sort of the best use case as i can find where the abstract method in the base class is the signature and all descendants have exactly the same signature but their implementations are different as a result of which you're getting different behaviors so you're effectively able to reuse that one method to affect different behavior and that sometimes becomes the solution for method abstractions right if you jump to make a method more generalized you're fixing your future possibility you've kind of killed your future possibility of moving anywhere else besides making a method and then keep adding on more and more capability to that method as you realize more and more use cases that need to be satisfied by your generalization make sense so rather than jump rush to generalize on method signatures and implement these general generic or generalized reusable methods i'm saying wait keep in mind that remember that you have the duplication the copy pasting with little tweaks remember that i'm not saying forget that but revisit it later after you've sometimes implemented this entire system and you have a much much better understanding of what it is you're doing what does what all these methods have to do what are the commonalities and what are the variances and apply a decision design decision after all that understanding your abstraction will be far cleaner far more useful because you have the full gamut of possibilities variances in the commonality and the variances so when you make a choice should i make it a method should i use polymorphism should i use delegates there are so many options why fix yourself early in the implementation phase without knowing the full depth and breadth of the all the requirements that that one method might have to have like the variances so i think with method design that's all i'm going to say because a lot of it will play out in class design as well so i'm just i want to just show you now class design so what is the basic i'm going to show you some examples though quite a few of them but i'm going to talk about some basic ideas first with regards to class design and abstractions with regards to classes there are at high level there are two purposes to abstractions when it comes to classes ideally they're doing the same thing which is they're trying to hide the complexity yet surface the right level of detail domain specific detail that applies to your domain your application your the domain of your application what are they hiding exactly what is this complexity could be many things sometimes the complexity is the fact that you might be coupled to something like a database or a you know a library that's giving you access to let's say azure you know cosmos db uh you know or database for ado.net versus oracle and others sometimes you were creating an abstraction to give yourselves the ability to use different implementations polymorphism and in fact the d in solid dependency inversion is a big example of this in fact just you know the i was planning to make a video on dependency inversion because i think that's one of the important aspects it's not applied again from the get go so just be aware that's kind of the point of this talk is don't rush into the abstraction mode right away but it's a good idea dependency inversion is a very clean and you know useful concept but the problem is it depends on abstraction so here i am talking to you about abstractions because i can't explain abstractions to you then you're certainly not going to understand dependency inversion but the idea is that you are building an abstraction such that you can have multiple implementations i'll show you examples of those without impacting without your application knowing that there are different abstractions of different implementations maybe just what polymorphism is okay so hiding some complexity decoupling yourself from some third-party library which is the other reason you might have an abstraction which i do quite a bit and for a good reason and i'll explain that those reasons and then polymorphism which is having a singular unified interface if you will the abstraction while having multiple implementations allowing your application to use one or the other implementation as long as your abstraction is a direct right level of abstraction for that application and is domain specific right okay so let's look at some examples this code you're seeing here is i'll put a link to it in the description below is part of my message broker series where i introduced the adapter pattern this code is the adapter pattern so if you've seen that grade if you haven't you might want to look at that video i'll put a link to it here that video goes more about discussing the the pattern itself while here i'm using the code to explain abstraction all right so here is a message broker publisher base this is the base class for all message broker publishers then on the right left-hand side here we have one implementation which is a message broker publisher for service bus right that's my naming convention i'll use the same prefix if you will the first part while the suffix would be base or the specific implementation in this case the is service bus right and that distance from the base class so this is the abstraction here the base class that's the abstraction now you i'm hoping and you're probably thinking about this like so because how do i get to this abstraction how do i know this is what i need the method signatures to be especially the public aspect the public surface right here's the thing you need to understand i have an abstraction it may not be so obvious in the message publisher side but the message subscriber side you're gonna it's gonna blow your mind and think holy crap i don't think i would have come up with that abstraction what i'm getting at is i didn't just come up with this abstraction the first time i started using messy brokers i've used in this case both raven mq and source for many many years for many many projects i'm very very familiar with both these messy brokers i am confident i can make a good app session today after having used those classes those um services and their libraries rapid mq has its own library and source bus has its own library we'll talk about that now but i'm familiar with the libraries i'm familiar with the message brokers there are the nuances across the two message brokers i'm in a good place to design an abstraction for an application that requires both of them in the same system with the possibility of moving to one or the other right so don't rush to make an abstraction because you will likely make a bad one okay and remember right at the beginning i said what's worse than not having an abstraction a bad app session it is a whole lot worse than no abstraction at all right a good app section is useful but a bad app session is very costly it's the team hates using it it causes a lot of pain a lot of trouble it's just not worth the time of trouble it's another thing i heard from sandy metz i think her name is and she's something like the best way forward with the bad app session is to go back meaning undo right i have the same mentality most of them some people who work with me will really know i say this i don't want the problem i'm not trying to solve it i don't want the problem which basically i'm saying backtrack go back to lead didn't have to go down this path in the first place like find out go back till you come to the point where you realize you made the wrong turn and then again go back on the right track right so instead of trying to solve the problem here because you've already gone our way off course you're trying to solve the problem here i'm saying no backup because you may not even need to go down this route man maybe this is the the better way to do it and so i see i think she's saying the same thing she said the best way forward is to go backwards or something laughing effect and that's pretty important as well the the saying okay so let's look at now the the subscriber version of the base class and you'll see that implementation i'm going to go deeper into the libraries that i have in mq libraries versus the first libraries but also the reasoning for that abstraction so here is the subscriber base class now you can see that the subscribe method damn we're only interested in the public method really so and this is an abstract based class descending from what this is the base class sorry it has the signature of type action that takes a message received event hours and received callback and already there is a bit of a disconnect here because you think could you have possibly arrived at that i mean that doesn't make sense right and it doesn't that's what i'm trying to get to you cannot just design a good abstraction out of thin air you have to have had the right amount of experiences with you know the two or three variances to understand how best to give an abstraction or create a design abstraction for that purpose for that application specifically okay so however you dice it you will see that in the implementation for go back now to the search bus implementation of the subscriber right you can see i'm using the subscription client this is the part of the library from this from the azure service bus library sdk as i call it this abstraction and the base class that is this abstraction is hiding this notion normal knowledge implementation of the class as in the subscription client in this case of the search bus versus whatever rapid mq has a connection factory and connection and so on those classes the library classes have a lot of methods i don't want to get muddled i don't want everyone in the system or everything in the system getting muddled with using that subscription client the sdk directly in azure the azure service plus sdk directly and having to figure out what method to use and it's just too confusing so one of the purposes of an abstraction is to hide that complexity of the library itself but by hiding the complexity of the library you're also decoupling yourself from the library meaning you're not tightly coupled to sales bus you're not tightly coupled to raven mq right my abstractions would be the same where in a system some people ask me this so shift this abstraction is because you need to use rabbit and q and service bus in the same application so you have this attraction the base classes for the publisher and the subscriber would it be different if you needed to use very new you would only ever use search bar so you would only ever use rabbitmq not really this abstraction would be the same because for me i'm still focused on what is this thing doing for me in my system this the publisher and the subscribers they're doing a certain kind of work for me that has not changed the only thing you're saying is that i have no need to use david mq let's say so do you have a base class and an abstraction yes may not have a base class i certainly have the abstraction though meaning it's all implemented in this descendant and that's all i would have the base class only comes into play if i intend to use polymorphism you know in that in that class meaning i might have to swap between tab and mq and service bus maybe at runtime or deployment time we decide this customer uses supposed to use raven mq that customer wants to use the service bus or whatever the cases if i don't have a need to use a base class in a system i wouldn't use it meaning if i if you tell me shift be the only messenger vocal we will ever use in this in our application this an organization is azure search bus i would use the decision class minus the base class meaning of course it will be combined one class but there will be no notion of a base class and then a descendant it will just be the search first class right so i said here the client the subscription client here there's a lot of nuances to the client that is being hidden by the implementation which is the whole point lots of methods you have to understand whereas the public side is just saying subscribe and it just says subscribe don't have to worry about all the details that subscribe means all this stuff will happen for service bus but there i have an mq side that subscribe means all this right and you can also notice here that this message received event hours this is our type this is the type of the domain as if you want to say that it's a class it's our class it's not service buses class it's not ravencues class and this is a very key aspect about abstractions and you've probably heard me say this many many times when i talk about the design pattern like the gateway design pattern the gateway works for you it does not work for the service what i mean by that is the inputs and outputs of the abstraction of the gateway design work for you they are your classes they're not classes related to that service so the same thing applies here in this message broker thing probably more and more uh prominent or obvious in the publisher here so when i'm publishing a message i'm publishing a message whose message is this this is our message the domain's message it has nothing to do with it mq or service bus the implementations would have to map between our message and however search bus needs this message and however raman mq needs this message our implementation would have to do the mapping and i'll show you that but we are our abstraction is not talking the language of rapid mqa servers and that's the key aspect of abstractions your abstractions have to talk in your language and that is the right level abstraction and certainly is also going towards not making a leaky abstraction meaning if the service bus things start to leak out into your application meaning by way of a method argument or a return type if this message word this service bus message it becomes a leaky abstraction because you're letting the search business service business of the implementation leak out of your application and your application is now being caught up in the service bus things or the rapidmq things it's just a leaky abstraction in that sense you're letting me in on how what is required to implement now you're not doing a clean abstraction because you're forcing me to talk to sales bus even in my application before i can talk to your abstraction in this case this abstraction so if you look at the the publisher for service bus you can see that it takes the our message and effectively mapping it to this case a service bus message right i just a-listed to sb message and effectively is using this message classes properties to map it to the search bus property and then is calling the topic line which is the sdk client from azure pro service bus to send a message using the service bus message so this method is effectively just mapping our message to the salespers message the rabbit mq version of the implementation is doing the same thing is taking our message right the type and it's mapping it to in this case what they call ibasic properties which is this type here let me you see that type i have basic properties that's rapid and q thing nothing to do with us as well at all but it's confined or encapsulated within this class the whole rabbit mq nature of this class is confined within this class where this class is using these two mq specific things well the service bus thing is using this uh so specific thing right the same idea persists on the publishers sorry subscriber side it's a little more complicated just because the fact that that method signature had to be designed in a way that becomes works for both search bus and lab and mq but the idea is when we receive a message in this case it uses a callback we have to map that message to our message received event our thing okay so here's the callback it receives this as the message and basically mapping that sb message and a bunch of the information that we need into our message received event hours and then that is being sent out here in the callback so this callback receives one of those but this is the same or common for both the raven mq versus the source password in this case in the rabbit mq so rabbitmq implementation that's the callback we receive the in this case what they call a model and ea basically and that maps to a message which maps to a method received and we call that back here implementations are very different as i said a a good abstraction like this would not be possible because you've used sales bus one so you use dividend key once you bit or you've been introduced to them very recently good abstractions come from understanding very clearly the variances and the commonality between the one or more things you're trying to blend into one abstraction right if you're not trying to blend like if you only want to use service bus and that's all you have but you want to build an app station like i do anyways you know with hiding the sdk if you will from my business application the domain of my application then that abstraction is specific to what you're trying to do from the application and i'll explain that by way of a cosmos db abstraction that i use in my applications so you can understand what i'm saying with regards to cosmos db or that level of abstraction or kind of abstraction right so here is a class that is got has got some of these public methods just look at some of the public methods here and look at the signatures meaning inputs and outputs and that will give you a sense by just looking at this method and the the names and the data types inputs and outputs as to what this is doing it looks kind of like a database abstraction does it not create a record get me this data get me that data update this data and what i'm going to say now is some people may not understand it but so i'm going to say it anyways you understand what i'm what the purpose of an abstraction is yes i told you this is working with cosmos db but is it apparent in the signature in the public surface of the class that this is cosmos db take a look again now you don't know if it's cosmos db or audio.net or is it you know in the memory store or you're storing stuff to a file system you don't know and that's the point of an abstraction your abstraction is designed for your domain it has nothing to do with the implementation if you can keep your kind of your mind in the right place when you're building an app session you're building an app session for you you get caught up and i'm building a cosmos db app session i'm building a app station for my database i'm building an app station for an mq or a messy broker right that is not it your abstraction is being built for your application that abstraction works for you it does not work for the the other thing if i'm using a charting application starting library and i've used some of those in the past these charting libraries are incredible are they not i mean this like they make it so simple for you to create graphs and charts 3ds and which proper shading is just fantastic but they're extremely complex you know whenever i've used these charting third-party libraries i essentially build an app session i said in from my application i want to create a bar chart and i have this information and i want the thing to use this information to go create a bar chart of a specific type what are the options are and then i wanted to create a pie chart like this and i want to create a line graph like that so in my application i've got a bar chart line graph pie chart other charts i built an abstraction meaning a public service or an interface that works for me for the domain the domain doesn't have to use the full capability of that library it just needs a very small subset that abstraction gives me a simple way for my business application of the domain application to deal with my graphs and charts without getting all muddled and caught up in all of the possible possible nuances that library has to offer as a result also gives me the opportunity to implement that class in a completely different way using a completely different third party library having different graphs appear yet my abstraction if it was a clean abstraction would still hold because my requirement of that abstraction has not changed all i've done is i've used a different third party library maybe it's better maybe it's you know shinier whatever what i'm getting at is a cleaner abstraction will last longer if you will right a cleaner abstraction will last longer not because it's too much of an abstraction or too little abstraction it is the right level of abstraction that app session was built for this domain to make use of a charting library from the perspective of the domain of your application not from the perspective of the charting library but if your requirements have not changed there's no need for that abstraction to change which means you can implement it using various different libraries if you've abstracted correctly right but nonetheless even if you don't intend to change the library the fact is you've given users of your your your abstraction a simple way to get bar charts and pie charts and all the different charts you want done and you're in some ways enforcing a certain shading or color theme or whatever that maybe you know you would do with abstraction so that not every time you call a charting feature you have to remember to do all those things correctly right so in this case this the signature of this class the public surface or the interface would look like any other database related thing you have no notion that it's a cosmos db thing and that is how you need to design your app sessions yes i'm working with cosmos db but look at the implementation here you can see there's lots of cosmos db things in here throughout privacy only it's the whole thing it's just completely kind of cluttered with cosmos db stuff this cosmodb client also another thing to point out here is show you some of the methods here create database okay that creates fine get container very specific to cosmos to get database but then they've got other things like get database stream async and so on or if you look at um well these are specific containers there even containers for example might have certain methods that may not make sense to you like get item query iterator what the heck is that right so the reason for this abstraction is you know what we have a need in our application to do these features of this functionality with cosmos tv let's design the abstraction for that i don't necessarily need to know or care to know more importantly that is cosmos db and who is going to understand these methods like get item query iterator like get item link variable i mean this is just too much nuance too much detail about cosmos db yes somebody needs to know that somebody who's building that interface the implementation of this class needs to know that sure but nothing in your application needs to know that which is why you're building an abstraction you're keeping a distance you're decoupling yourself from the nuances of that library is it not that's the main driver for an app session and of course that gives you the benefit of saying well i can have any implementation if your application is at the right level like i'm proposing that this abstraction is it doesn't matter i could have this in this case of course the implementation is using [Music] cosmos db right it may not make sense to you but this is a cosmos dp way of doing stuff if i were to let's say retrieve get tag videos for example there's a lot of gobbledygook seemingly coverly cook from a normal programming point of view what the heck is going on here but for those who know cosmos db that would make sense however this method signature i could implement using adrian.net if the data were in adr.net i could implement this method signature then given a signature like this i could implement a method where the implementation was in memory or based on a file system or based on a database or based on blob story whatever the the case may be it doesn't really matter the abstraction the method signature the interface or the public surface of that class has is not leaking anything it's at that right level from the business point of view from the domain perspective it is at the right level abstraction i am trying to save data to some place here's my data please save it i want you to get so and so data given an id or a tag or a you know series of tags how you store that data is it in one table two tables 25 table i don't know i don't want to know how cosmos db stores databases house you have to store data and sql server completely different but this abstraction is decoupling you from those implementations as well what is your data model like what is your database don't know don't care it's an abstraction from in this case a data storage point of view what i'm saying from the business side this abstraction is working for me i am saying i want you to say my domain model not what you have a table i don't care what that table is or how many tables they are or if it's split up into 15 tables or it's in a cosmos db kind of container i don't care that video and the tag video these are my classes domain classes this video type here and the tag video these are my domain classes these are not dependent on the database or the data model i don't care whether i'm using sql server or cosmos db my domain model is not going to change because my business is not changing so the api the abstraction is based on what i need from the business's point of view this class works for me it talks in my language my language meaning my types right the video tag video and the video types how if this data is saved like this in the sql server database this way or they're saved and split across multiple tables i don't know and i don't care is that data saved like this in cosmos db or is it got its own style i don't care i don't know what i don't want to know that's the point of an abstraction a good abstraction will give you that sense of saying i don't need to know i don't even want to know and it's not leaking it's not forcing me to learn about cosmos db or 80. ef whatever you might be using it's not a clean abstraction if it does that so it becomes a leaky application or it's too much of an app station becomes too vague and you're trying to be generic oh my gosh i'm just going to store a thing it's not a video just give me a thing and i'll store it right and i've seen aps systems like that crud operations oh we've made this beautiful system it's got all these crud operations you know and then you sometimes you send sql statements as part of your arguments which means you are leaking the abstraction two weeks ago and one is you are of course making very clear that the caller has to know sql which means now there you're forcing them to understand your language right in the databases language but you're also leaking this data model out to your system right now they how can they write a query they want to sit and do an update if they don't understand your data model so you're leaking all of that out it's not just sql it's like so much is being given up if you will from an abstraction point of view there are many services i've encountered sometimes third party services sometimes within organizations the company that i'm working with where their abstractions of their services right are pathetic i mean they're forcing you to understand their data model or because let's say they got five tables they got five end points and saying well you can do what you want yes but crowd operations are not helping me one bit crud operations don't help you as an api your api is helpful if it's providing some business value so for example if you're interesting just if i want to effect a certain change in my data it's not a matter of just adding or updating one recorder maybe do this one thing from a business point of view i have to modify three tables right so give me crowd operations for three tables is not the way you expose an api you need to give me one method that says and ask for the specific information that only i can give you and you do all the stuff that needs to be done if you have to modify three tables of 25 tables that should be done by your system your api should not ask you to ask the user to modify three or 25 tables that's not what an api so as i said a good method design implies implies good class design implies good system design focus on method design meaning signatures of the methods and class design you will automatically design better apis so the same theory the same ideas levels of abstraction decomposition it all applies to everything else okay so i think the i'm hoping this class the or the universe the cosmos db gateway class if you look at the methods you know i'm hoping that that the public methods that helps you understand that this could be anything it's not specific to a gateway or cosmos db this could be anything which is why sometimes i feel people get confused right i said but sure but then what's the difference between a gateway in a facade yes because all classes are trying to do the same thing they're trying to give you a clean level of abstraction like an abstraction is opaque opaque means you can't see light can't go through it it's like a black box it's the point of an abstraction you don't want to know so classes are trying to be opaque which is why if you hear my dependency injection kind of thing is this a black ball i don't want to know it's dependency that's the whole point of the class itself a class has to be a black box you just if it's a clean abstraction it'll be a black box i can't see through it it does some really useful work for me i don't know how it does it and i don't care to know how it does it so that abstraction is the point of every class so then you're saying well then what's the difference in the gateway and i don't know the facade pattern well there are similarities they're both trying to do the same thing they're both trying to give you this good abstraction they're trying to be opaque their intents are slightly different the motivations come from slightly different different angles and they are placed in the system at different places the facade is like the front of your application or is the beginning of something while a gateway is at the time of reaching out to our service so depending on what it's doing in your system it's a gateway of course there are some nuances some specializations if you will if you look at my videos on the gateway and the facade they have very different implementation guidelines but on the surface that class is a class it's giving you is useful because this abstractions are clean and it's useful because you don't you're not required to know the inner details or implementation details of that class so that's the basic idea of applications all right i think this brings me to the end of this video i hope i've done a good job of trying to explain abstractions there are many forms of abstraction but i was focused mainly on method and class abstractions i hope i've done a good job if i have please give me a thumbs up and i will see you next time

Channel: Shiv Kumar

Views: 2,817

Keywords: Abstraction, Software abstraction, Software abstraction deisng, Weak Abstraction, Strong abstraction, Correct Abstraction, Levels of Abstraction, Good Abstraction, Bad Abstraction, Software Design, Edsger W. Dijkstra, Sandy Metz, C3, .NET, .NET Core, Good Software Design, Design

Id: hOrpppzEX14

Length: 48min 0sec (2880 seconds)

Published: Sat Feb 13 2021