SOLID principles in Angular

okay so hello everyone um my name is milan and uh i'm a part of interventra for a couple of years already um i work as a as a front-end engineer in addition team i also saw there are some of people from addition drawings so that's a good thing i would say and uh yeah been working with angular for some time already since angular 2. um and yeah i think i know something about it but i guess each year i found out that i don't know that good because every every year or every month you learn something new with angular you never know how the things work actually um and uh let me just um tell you how this presentation should look like so firstly i have like couple of slides which are not that important um they're mostly the basic definitions from wikipedia copy pasted um and i will focus more on the actual principles and this will be a live coding session which means that we will go through the code all the time and hopefully the the examples will be good enough uh to explain the principles itself so uh there will be easy ones uh standard ones and i think that's i guess the most important thing if you want to understand the principles correctly um so let me just show you the the project itself um because uh you will be looking at this screen probably 90 of the time so this is just a regular angular cli generated project um i have done already some changes uh because of the our presentation so as you can see in here i just modified the schematics of angular so whenever i create a component or a service um we will create it in a let's say minimized way so that we create only a single file with the inline style and inline templates so without any tests so that you can guide so you can actually see the files on the left so that it's not much of a confusion what we are doing and also i turned off tslint so that you don't see this uh red flags around us there on the screen because i don't think it's that important for this talk anyway so uh what else yes i have actually for each principle i defined a a branch which is actually showing the principle itself some of the principles are across the different branches but that's not important in the end these will be shared on my github account and in the end if you want to have the to have the look at the end code let's say uh just let me know at the end of the of the presentation so okay so let's let's start um solid in angular so let's i i need to go through a bit of these boring standard definitions because i need to introduce what we are talking about actually i guess some of you probably most of you already heard about it and no principles they used it and so on but for those who are not introduced to these ones i would like to just say a couple of sentences so uh the design principles we are talking about are just one set of principles um and there are a lot of them outside these ones i would say solid ones are the probably the most uh famous ones and probably they're used quite frequently so design principles are just recommendations how to design code in order to keep it maintainable flexible understandable and what is the most important thing that those are abstract so uh you probably heard about design patterns and same patterns are actually just an implementation of these mentioned above of these principles and then can be combined one or multiple or because there are a lot of principles out there you probably heard about dry or kiss like don't repeat yourself keep it simple stupid those are the ones which are not part of solid principles but they're also quite famous and yeah other other famous developers talked about it wrote some books about it and so on so let's just continue what is actually solid uh so it is an acronym it's a shortcut for five design principles and uh it is uh written by robert c martin or uncle bob you probably heard about him um he wrote the book design principles design patterns like 20 years ago and i would say that solid principles are quite uh used since then and i also need to say that these are recommendations so these are not rules these are not um the things you need to use these are these rules are not carved in stone but they're quite recommended to use and if you use them you probably know why so let's just this is the last slide and then we go to the codes so the solid principles uh maybe you heard for tho for those who didn't we have five of them so for each letter is solid so single responsibility open closed risk of substitution interface segregation and dependency inversion principles they are really sound complex but uh when you see the examples of them they're not that complex i would say and uh let's just jump to the first of them and let's just jump to the code so that i don't want to bother you anymore with this slides so as in solid or single responsibility principle um this is a wikipedia definition of course there is a different different for each of us i guess it's a different uh meaning for this principle but usually it means that there should never be more than one reason for a class to change in other words every class should have only one responsibility we are talking about classes of course um in angular specific uh it's this typescript so we have classes but we have different entities in there so we have uh as you already know services components directives and so on and so forth and of course regular classes which we use for our models and let's just go after this to the code and see the example of it a second i guess i need to go outside of this because for some reason it won't change my screen never mind anyway it is not that important uh the code is so let's dig into the code so i am on the synchro visibility principle branch and this is how the app component looks like it's actually pretty simple uh it's just a regular app and in here we are just having a single uh chunk of code which is presenting uh just a regular i would say social network widget in this case facebook and on the click itself we are just having some i would save ceo code because i didn't want to bother with implementations uh in in this presentation because we will have a lot more time for that we would need a lot more time for that so and this is how it looks like actually in the in the browser so this is just a regular header generated by angular cli and we have our widget in here this is all of course marked so this is hard coded it's hard coded and since we are talking about single responsibility principle which is saying that a class should have only one responsibility and only one reason to be changed let's talk about it a bit about our component root component or app component so let's usually when i when i think about this principle because it is a bit tricky and later on we will see why but um in this really uh simple example uh let's just think about what this component is actually doing so let's let's see firstly it is showing the toolbar secondly it is showing the content um and it's handling on click but also and it's having its own implementation logic of on click handler as you already heard we have already too many ends in our thinking i would say because this up this component is doing already a lot of things so it has more than one responsibility so let's just try to change it so that we are actually fulfilling the single responsibility responsibility principle so firstly what i can see in here that this part can be extracted to a a specific component because it's not a part of the app component for sure it's a widget right so let's just uh try to extract it i will just create a single component this is the schematics that we're talking about so i would just say something like facebook or yeah facebook um widget and facebook is created um it has everything in line so it's easier for you guys to see it so let's just copy the template inside of this let's go to the component itself move the click we don't need on anything here it is by default and what is left is yeah let's just copy the the css because so it looks decent at least because now it's this is not a part of the app but of the of this component and of course i will just minimize this so that you don't bother with that and yeah let's now just replace this with this component let's save it let's see our presentation and yeah as you can see it is yeah everything is the same so the application is working but somehow we managed to move part of the recipient to two different components so in my eyes this this component is now only showing the toolbar and the content and that's pretty much it so i think i'm pretty satisfied with this one but let's move to another one so this is the facebook widget in here and facebook widget is doing what so it is actually showing the content it's scanning the click which is totally fine it needs to kind of be clicked but it contains the constant implementation for the click this thing cannot shouldn't i mean it doesn't need to be a click it can be some complex implementation and i would say that this part of the code can be extracted to something different so let's in that case just create a service in angular and just call it uh something like i don't know facebook opener and just move this part of logic into our facebook opener service it will be called click won't return anything and this is pretty much it and then you go back to the component let's just inject the service and on click we'll call the service let's save it and then you go back to our application yeah so when we click on this it is from the service and it is working so this example is actually really really simple as you can see but the reason i didn't go for the for the more complex ones because this rule is a tricky one since in the more complex examples you actually are not 100 sure when the there is possibility of the first component stops and there's possibility of the second component starts it's a bit tricky thing uh what i what i usually do is just um talk with my team members or uh people who i'm working with and you we just need to provide some kind of uh limit to this uh actual uh principle because if you use this thing all across your app that the thing is already doing only one thing and so on firstly it's not really correct since it's probably doing more than one thing and after that you will have a lot of files a lot of code so you will have a lot of redundancy a lot of other platforms a lot of files after some time you will probably uh you could have problems with that so i would i always use this principle but i always use it to some extent so just talk with people you're working with and what makes the most sense for you how to separate this possibility you do it that way okay so this is this was synthesis possibility principle after uh when we finish all five you will see the example of uh the whole module in angular following all of these principles and you can actually also see the single responsibility in action so let's go back to our presentation and let's move to the next one and it is called uh oh and solid right open close principle uh this one is i would say the ones which is frequently used all across and i think it's pretty important since it directly influences the maintainability of your code so the definition from wikipedia is software entities classes modules functions etc should be open for extension but close for modification what does that means actually okay so let's see it in the code i will just just shortly commit this because this will be the end of the first principle and you can later on check it on my github just fastly push it and i will just rip just go back to actually move to the open close principle okay so let's dig into this example what mean what does it mean when when the when when uh the definition says something like yeah your class should be open for uh extension but clause for modification uh let's see this example in here so right now we are having um i have created a social network widget in here which is actually just a parent uh component of in this case facebook content and twitter content those are just two social network uh widgets and i'm showing it in the in the app so let's just see how it looks like a second yeah it looks like this doesn't matter but we now have this two social networks shown in here but what if we want to add uh one more it can be google plus or it can be an instagram it doesn't matter but we want to actually add additional functionality to our component and i just provided a regular solution standard solution for this case i just have two ngfs in here i'm just saying okay if you provide me facebook as a type i'm shopping facebook if i provide twitter as a type i'm showing twitter and yeah this will work right because it works so both of the those are shown and in the app itself we are just saying which type it is but imagine now what if i want to add a different one in here third one and i say this will be instagram right then i go into my code of my parent component and then i know then i need to add additional code in here which means i'm violating the rule of the open closed principle which means that i am actually modifying the parent component in addition of a new feature which is wrong and this means that this not is this thing is not fulfilling the principle right i would need to do something like this and ask if this is instagram and then add additional stuff in here right and i changed its source code in here so let's just provide the solution in which we will fulfill the open close principle at least with angular mechanisms so what i can see in here firstly i don't need type anymore uh i will just delete this thing or maybe i will need it later on let's just uh yeah i don't know it doesn't matter so as you can see in here we just remove this and this is the actual html of my widget this thing should be dynamic so let's say that this should be a title for our uh social network widget let's say a title in here we will write it as an input but what about the content itself in here right so what we should do with that let's just remove it let me just just a second i want to have this copy pasted just a second because i don't want to copy paste it again [Music] so there is a thing in angular called energy content you're probably if you use angular you probably use it if you're not yeah this is the the introduction to it engine content is actually dynamic rendering of the content and with some angular magic it fulfills the content with the content you provide as a child of your html html component to the template so for me this thing looks good enough for now right and let's try to use it first we don't have type right we have a title let's just put something like this and in here i will just put this content in here because i need it then i will delete it so i need the quantity of the facebook let's delete this and i have a content of a twitter and as you can see application is still working i just changed the approach in here i'm providing the content in here dynamically and we can go one step ahead and just extract these these two different components let's just do that fast so first will be something like facebook content and second will be twitter let's just copy these parts of the code which is the content of our first social entry widget go to the facebook content and put it in here and for the twitter we do the same and yeah we what we need is we just actually need to copy the the styling so the styling looks the same plus a second so that it's not broken just minimize it and for also for the twitter content because we moved the html right and after all of this when i s then i actually tried to use them facebook content that's it twitter content that's it let's go to the to the browser itself let's refresh it and if you take a look in here this is actually the same thing we just created so with the facebook content with the content but what is now the different with this approach i could add a different one here i could actually add like 10 of them right but whatever i specify in here is dynamic i can add a different component i can even i can even add just a regular paragraph something like new widget is coming and something like i don't know test this is d in here sorry and it is there so the thing is it's not seeing because it's css of course let's do something like h1 maybe it will sing the thing is that yeah but the thing is that whatever you provide as a content uh it is rendered right and with this approach we can add what how i mean how the endless number of new stuff in here of the new types of contents and we wouldn't change our network widget in here right because this component is now opened to uh extension but but close to modification we didn't change any of its codes we are just extending it and using it using it in here in various places we can use it in different modules and that we can provide whatever we want in here and it will just work as the first solution we provided but this one is just following the onpreclaws principle this is open cross principle applied to actual uh component level later on i'm going to show you actually how to do it with services abstractions and so on so let's just go back and to the slides and just go to the next one because i think i already spent a lot of time talking um yeah allen solid or lisco substitution principle functions that use pointers or references to base classes might be able to use objects of their classes without knowing it this looks like when you take a look at this default definition a bit complex but actually what it is about you can imagine that you have a one base class and you have maybe a couple of derivative class from that base class and this rule says that if if you replace the base class with any iteration of its children classes your application won't break so it is totally replaceable the parent class is replaceable with any instances of their children classes this principle you can actually implement on whatever thing you want i will just shortly show you uh in a just a basic example in typescript how this looks like but um stay tuned for that so please just call something like uh i don't know abstraction dot ps and let's just create a regular example so uh you already know about the streaming platforms right uh is it a netflix or i don't know amazon prime or whatever uh you have users in there right you have subscribers so you have a standard subscriber you also have a premium subscriber so let's just create those just for case so we have a premium subscriber and we also have standard one and when we take a look on this like logically these two subscribers actually have something in common right and that's why we're gonna create a base subscriber let's say that it has something like name it doesn't matter and let's add some kind of behavior for premium and standard subscribers something like watch premium content right and something like i don't know watch premium and we can also create uh something like watch standard content so think about this i started the presumption that this subscriber will be enough for both premium and standard subscribers but let's let's let's go uh more more through so premium subscriber will extend base subscriber and as it is it will have watch standard content and we also have watch premium content because it's a premium subscriber but what about standard one standard subscriber actually cannot watch premium content right because of that i will do something like this cannot or something like uh unsupported right or how is it spelled i don't know supported so now when you take a look at this code this code is actually violating the list constitution principle because this subscriber can be replaced with premium subscriber but when basis cover is replaced with standard subscriber error can be thrown and our application is off so uh the solution for it will be obviously if you don't throw the error in here you can do something else but the idea is that this model is not good enough so what is the actual solution to this one in my eyes is that if you want to provide this list position principle you need to be careful of what you put in your base class so for the first type of solution will be that you move the implementation or behavior to actual subclasses in here and with this approach you don't have anything in business scriber but with this approach we are actually fulfilling this constitutional principle because whenever you replace the subscriber with those two the application is working right so you don't have anything which will break it or another solution would be that you actually extract these things to interfaces which will be our next topic but you can insert these two interfaces and then implement interfaces something like this so i can do something like extract interface uh standard if let's say let's just prefix with i i don't want to just uh [Music] extract export sorry and something like e standard it will have just something like this and we will have a premium and this one will be handling premium content so with this approach now we can actually say that premium is implementing both of these and the standard one is implementing only the standard and this one of course need to implement all of this but this is one of the of the of the i would say uh decent approaches in this particular example so i think the idea is that uh whenever you think about your your models uh if you want to fulfill police constitution principle you need to think if your derivative classes actually can replace your best class without breaking it which brings us to our next principle which is interface segregation principle this one is pretty uh i would say spread around since it is used quite frequently at least in my environment um that the many client specific interfaces are better than one general purpose interface or if you wanted to to actually have a different definition is that consumers of your interface shouldn't be able to have behaviors which they don't need in this case in here i can i could create something like and then have a single interface for for both of these oh sorry so the thing is that uh thing is that i don't need what chromium content so i don't need this i don't want to implement interface which is having this type of method because i don't need it in the senate subscriber at all so the idea is to have small lean interfaces and that your uh consumers of interfaces are not having methods or behaviors which they don't want to use so i don't need this in here or i i will throw an error like something i it's not supported so if we use this then we are actually violating the interface segregation principle but if we use as we did it before in here when introducing actually two interfaces so that anyone can actually take the behavior which it's needed for it for them so for premium it's indeed both of them and for standard it's not only standard and that's i would say it's the idea about this principle okay let's go to the next one which will be the last one but i would say the most interesting one so next one is the in solid or dependency inversion principle which means depend upon abstractions and not concretions yeah this one is pretty i would say why because this one sentence doesn't tell you a lot right and uh let's let's uh let's see it in the code because that's the best way to uh to actually show it okay i will just act like like like last time i will just uh commit this stuff i did on the open close principle because it contains all of them second and let's just go to the dependency in version one or actually let's let's because we have time let's just go back to this previous one and uh just write it through because we have time to do it uh i wanted to actually show you um how it is done but i would rather now actually since i have time uh let me just see how much time we have yes so i will i will be fast tamara uh don't worry take your time okay so let's go to our facebook sorry social network widget let's close it you already saw how it looks like sorry for this because i'm new to max so this is a bit small for me changing the stuff [Music] let's see what is wrong probably because changing the uh let's just run it once more yeah these things happen with live code always so sorry for that but now we are fine okay so we are back let's go to our app component let's remove this one we don't need it and let's let's actually try to uh explain the dependency inversion principle which is i would say maybe the most important thing when it comes to creating angular modules so first of all our social networking here right so what if we want uh something like for each child entry content um component we would need to trigger on init some kind of action like uh click on it right we can do that so let's see how we can do that firstly we will implement in the in our children components something like we go to abstraction i want to ex to create an interface for clicking something like clickable and this will be having only one single method which is click and it's tight void and both of our content components gonna implement those so it is clickable click which means it needs to implement the member let's we don't need this and something like yeah let's let me remove this and let's just log something like uh facebook click so that we know when they click that it's a facebook component right and let's go to the uh twitter component and do the same you don't need this but we need click and it's actually twitter let's go back to those digit components so what we want to do we want to to actually on in it to this component we want that each of our content components trigger a click because we need it it doesn't mean to be a click it can be any other event or action but in this case i think it's good because it's simple enough to show the example so let's let's uh see how we can do it firstly in angular in order to actually uh find its proper child you can use content child because in this case use energy content if you use something else you can use some other decorators in this case it's content child and in our case it will be like facebook content component right with facebook content and for twitter it will be twitter and then on init we are saying something like if facebook content because it has publicly available method and same thing we go with twitter we just need to put something in here because we're using it on init and content is actually ready after uh after content init lifecycle method so we need to put a static true in here in order in order to have these content available off on init let's check our ad component we have facebook we've had twitter and let's see if everything is going well yeah so when this is initialized we're having two clicks on facebook and on twitter so we automatically trigger this but actually even though this is working um we are depending on co-creations in here and we are violating the dependency version principle which says that your classes in this place are components need to depend on the abstractions but not on concretions and how we do that first of all uh i'm not you're familiar with but in angular there is no possibility to actually inject abstractions there is a mechanism so you can provide uh actual uh token in which that token is later on replaced with your implementation and that's actually quite strong and quite powerful mechanism which i will show you right now so uh in because what i can see in here that both facebook content and twitter content they're both clickable right since they're implemented interface so let's try to uh create some more abstractions in here so we don't just need this interface and let's do something like this so i want to create my clickable content which is an abstraction [Music] and this will be an injection token and this is just a description we can see something like clickable content and in here we will say that this type of injection token is actually we need it for clickable by using this now we can actually provide an abstraction and later on inject the concrete or provide a concrete implementation for this how this works so what we can do now is in social network widget is that instead of this because we had two right now we don't have to we have only one because both of them are actually clickable and in here since we cannot use abstraction in here we can use a token so we can say that this is clickable content and let's just replace this with this content content dot click and what we need to do now is to provide a provider for this abstraction and what are the providers for these abstractions they're actually clickable components so let's do that go to twitter content after this i can say providers i can say provide clickable content and use sorry we need an object in here and we need something like use existing because this is the component which is already injected and um we will say something like twitter content component and the same thing we will do for facebook and that's it so let's see if it works from the first try oh it works so we automatically clicked on both of them but when you look at the social networking here do you see any concretion in here because we followed our fifth principle dependency inversion and we are depending only and uh only on abstractions how this works actually is that this injection token is a mechanism of angular which will be in a way to actually provide the runtime representation for abstractions which you cannot directly inject in this case we're just saying okay this is a placeholder this is our abstraction and this component is actually inject this component when it's needed and that's pretty much it so this is the dependency version principle in a nutshell for the components but let's do it uh let's do it one step ahead because i think i already spent a lot of time but i think i i i have enough so let's just uh do something even more interesting okay so let's for example uh move all of this to uh module so i will create something like a social network module okay i don't need this and this social network module oh actually it is i created the component second yeah so let's just delete it we need to just remove it from our application module and this will be okay so let's generate it once more so like module and just let's call it social network and here it is this is the module so let's move our abstraction and our social network widget because these are our abstractions and these are actually the main point to our logic and we need now to remove the social network widgets from our ad component and we need to introduce it in here so it's a social network widget component and of course we need to export it in order to use it outside of this module and when you then when you go to a component if we say okay i don't i don't have it right so we need to import it into the module itself and now in theory take a look on this it works so we just move everything to our social network module and this is good thing about angular if you actually create a module with your code inside of it you can always and always just import it into your own other module and just use it so i guess this is a good thing because let's do the last step but i think that uh i will just go to the next uh i will just commit it and go to the next branch because i think i'm run out of time so let's just i will show you what i what i did next um let's just commit it a second and let's just open the dependency version we have the same logic we had in there but we had one more thing we added and then i will show you what we added let's just collapse this okay so what i wanted to do is to use an actual service to do the reload on the oninit for all of my child or children components right and in order to do so i firstly introduce the reload service which is just saying reloading and that's it but later on i needed to actually uh to fulfill the the rule of the dependency inversion and i need to depend on abstractions so what i did is that i created uh also the reloadable provider which is another token i created the abstract reloading here and i use that provider in my social network component and down in it i just click reload and what is most important thing is that this is used all inside of the social network module so in social network mode we have an abstraction of the service and we have the concretion and this said that in this particular module we use a specific class for that but why would we want to do that right the idea is that whoever consumes this module which is in here can use its own class so look how this powerful is actually this is maybe the most powerful thing about angular is that if you create and you depend on the abstractions in your modules you are free to import that everywhere in other modules but also extend and or change its behavior so let's just show that in the app itself we don't need this so we just imported the module and you see that it's saying reloading reloading which means that for both of our content components [Music] just a second social network widget so for both of our content components we are actually clicking reload and if you if you see this is the abstract reload right and when you take a look on the real service this is the default implementation so if i import that module inside of my module in here i will have the default implementation and this is reloading but if i want to actually change it or enhance it i can just do this and provide my own service and this is the actually the best thing about these abstractions and injection tokens and by using this in my custom service i can use something like yeah i can do something like um a second what they're doing here i can actually provide my my uh custom implementation and also use the old one so if i say something like this my custom reload my custom reload is there but what is most important we didn't change anything in our social network module we just used our own class in our app module and just provided it for the specific token and abstraction so in this module just to finish this quite quickly your module of social network is based all on abstractions there is no single classic here but also it is open to extension and closer modification so in this case we also followed rule open closed we followed rule dependency inversion we use interfaces properly we use single responsibility because our module here is only responsible for the social network widget and nothing else so that's why i said this first solid principle is a bit tricky and this is i would say the the power of angular and this these rules are the rules which angular uses quite frequently and i'll let's just go on a couple of examples on angular code so there is this you probably use it already it's called app initializer and this is the thing we did actually it's the same thing so app initializer is just a token and if you want to add an additional logic or actually extend it without modifying it you can use this and provide your own factory and block in this case custom stuff but you can do whatever you want before the app is loaded so what we see in here is that angular followed both open closed and and dependency immersion principle in its own source code and then i can go back to this here and you can see that custom stuff is loaded so we can either keep the same behavior as the default one we can enhance it and on the default behavior add additional one or we can totally replace it at least in our case of social network what else i just wanted to show you is that this is the same principle as for the http interceptors if you go there you will see that this is the same injection token as we used again so this is an abstraction angular depends on abstractions and you can provide your own interceptor which will either keep the old logic and add additional work or totally replace it and what else i want to show you regarding angular is that in the apps with components itself you have this lifecycle methods which are used everywhere i would say but if you take a look on its implementation you will see that each of these interfaces are following interface segregation principle because they are simple they don't have single method and whoever wants to actually add a behavior to it it can use it imagine if you have like a a single interface with with six or seven like cycle methods you will have a lot of unused methods in your in your components and this is just a showcase that even though these are recommendations only angular really heavily depends on them and angular in the source code uses all of these principles and i think [Music] i am run out of time and i think that actually will be everything i wanted to talk to you guys today um thank you for listening and uh hopefully i was clear clear enough and yes sorry if if i missed something out but i think this will be everything and uh yeah tamara don't worry milan don't worry about the time you can finish uh you can finish if you if you need something else to to wrap it up also we have a few questions uh do you want me to read it or you do want uh do you want to read it yourself uh which one is this one i'm looking at it uh yes we have one from uh in a q a uh option with the single responsibility question let's say if we have a shopping cart they need to get shopping cart with a specific user how to make a decision is it the responsibility of the user service or a shopping cart service i would say that if you want to to to be more lean i would say uh you need to uh the logic itself for getting the data about the concrete user i would put that inside of a service because if you want to change something in there you will need to change just a service and your component is using it so you wouldn't change anything in the component right so i would put it in the service okay thank you and uh there is one more question from goran in chat box regarding lisk of sub principle uh i will read it for other people who are not maybe seeing it this is more on the side of single responsibility lsp's lsp is more about not breaking even in in what is this name environment this constitutional principle yeah can you discuss about return values and arguments with regards to risk of sub principle uh yeah i know what what he asks actually um yeah well to be honest i didn't dig that deep into the spiritual principle because so far my models were just good enough to be used uh with the with the basic exam examples uh returning values and arguments um not sure what what you actually mean with that can you can you can you explain to me uh because i'm quite interested what you meant by return values and arguments with regards to this consistent principle gordon if you would like i can yes of course yeah there you go just a second can you hear me yes we can hear you okay thank you very much first of all thank you thank you for the presentation and this is very uh new to me uh to to hear about the solid principles from the angular perspective because uh uh i didn't know anything about angular and my question about lsp uh is uh uh maybe you remember that uh example of uh rectangle and square and if you have a square class and rectangle class uh which one should inherit uh the other one so uh this is the the classic school example for a list of substitution principle and i think it's not about methods that are not implemented uh because okay that is is a problem by uh by its own uh you can even have all the all the methods in derived class implemented but yet again uh and if you watch uh separately these classes they are quite okay uh but uh if you watch the relationship between these uh two classes derived in the base class then the invariants are broke i know what you mean the thing is that i see this principle as to be honest i didn't at all think about that uh uh that that that uh let's say approach you're you're talking about because i was always thinking about the relationship between my base classes and my derivative classes and that i need to think about them if i want to follow these principles i need to think about the model itself if i don't want to actually break my app right but uh what you're actually talking about to be honest it's totally different perspective of what i actually use this procedure for maybe uh i don't know if yeah i i don't want to uh to postpone the these uh with with my question i have just pasted a link for anyone who is interested so i mean we can uh discuss later on if someone else have another question uh there is an interesting uh uh article uh about this example that i mentioned and the broken invariants that can happen very often and it's uh not so uh uh it's not so obvious so to say so not implemented methods are pretty much obvious things uh but broken invariants uh in inheritance relationships uh are uh obvious so they it requires much uh uh deeper analysis i mean okay yeah yeah keep just if if you if you have some uh article you can you yeah thank you very much again for uh for the presentation yeah you're welcome thank you gordon for your question uh there's quite a discussion in a chat box here uh darko was asking why did you use a content project okay well i use content projector because this is the way you can put everything inside of your wrapper i know that in some cases this is you can repeat stuff right but this was just a use case it was just a social network what if they're they're not social networks what if you need to provide the content which is totally different from each other they're not shared anymore any model at all what i will need to provide a different input if i can just put whatever i want in there and this was purely for solid principles uh yeah don't repeat yourself is quite nice one but i would rather go in four solid ones than for dry that's my personal preference thanks do we have any more questions okay nicolas is adding something thank you and the thing is just one more thing uh the thing is that uh you said that you want to put a rapper widget around but the thing is if you do that then this whole thing is not extendable anymore you are forced to use the proper input in there then so then the my solid principle or actually my open cross principle is broken dry is another hand probably followed but my open open principle open close principle is broken so that's why actually and i focused on these particular principles to be fulfilled this is just a basic example in the end you can enhance it even more to not be repeatable but yeah i guess it it is always uh a way to make the code better especially if you are having more time to do it okay uh if we don't have any more questions maybe we should wrap it up thank you thank you everyone for coming participating in this angular tech talk villain thank you for your presentation i mean people are really really um [Music] interesting to hear more about it and they're just posting a great thank you notes in chat box you can follow our linkedin page and social media for news and open positions and future events and as i said the recording of this tech talk will be available on youtube channel tomorrow i hope you enjoyed it and uh have a nice evening see you bye bye thanks for listening and see ya bye

Channel: InterVenture

Views: 452

Keywords:

Id: GN73J6cNrFc

Length: 66min 32sec (3992 seconds)

Published: Fri Oct 29 2021