‫Hello, my friends.
‫As a programmer, you may encounter the word solid, and many people ask it for you to make your code
‫solid according to solid principles.
‫So what are these principles?
‫These principles establish practices that lend to developing software with considerations for maintaining
‫and extending as the project grows.
‫Adopting these practices can also contribute to avoiding code, smells, fracturing code and agile or
‫adept at software development.
‫How this happens and what is solid with the abbreviation s o.
‫L i.
‫D s stands for Single Responsibility o for Open Closed Principle l for list codes, substitution II
‫for interface segregation and D for dependency inversion.
‫Don't worry, we are going to get all of these principles and take an example on every.
‫Want to understand it.
‫Singular responsibility, principal.
‫A class should have only and one and only one reason to change.
‫Meaning that a class should have only one job.
‫Consider this application.
‫We have many classes and for an example we took the retrofit instance, the Java from this.
‫So in the previous videos we have developed like these classes, this class called retrofit instance
‫and its basic function is to do the work of getting the service or making an instance of retrofit.
‫So this class has only one job to do that is creating the retrofit instance.
‫So any change of any change occurs like changing the base.
‫You are al if if there is moving from this base, you are.
‫And we have said before that we have two parts of base.
‫You are at two parts of the you are al the base.
‫You are out of the API.
‫And the second one, which is the end point, which is valuable.
‫So considering the base you are Al, which is the fixed, we have put it into a private static string
‫called base.
‫You are Al.
‫So if there is any change in this code or this, you are Al.
‫If the the movie db dot org or the website have changed the slash three, two, slash four, we came
‫to retrofit instance and we changed this slash three, two, slash four.
‫So we make the changes here.
‫So we know that in the retrofit instance class, which is responsible for connectivity with the base,
‫you are using their hit instance.
‫So any change occurs in base.
‫You are l we came to retrofit instance here and we change it other other functions like like if there
‫is any change in the variable, we don't need to get the latest movies.
‫We need to get the most rated movies.
‫So we came to the other class that is responsible for making the variable connection and specifying
‫despite the latest movies, we specified the higher rated movies.
‫So every class should make only and only one job to do.
‫The second principle is called up and closed.
‫Principle objects or entities should be open for extension, but closed for modification.
‫This means that a class should be extendable without modifying the class itself.
‫Let's imagine that we have that.
‫We are developing a check out functionality for a store that offers discount to senior clients and pregnant
‫clients.
‫At first, our basic code will be the following.
‫This is that check out.
‫And here we are, checking if the client type is senior.
‫Then make a discount at 25%.
‫Else if.
‫If the client type is pregnant.
‫So may also discount 50%.
‫Okay.
‫So this is the code.
‫This is the check out class.
‫But open closed principle objects or entities should be open for extension, but closed for modification.
‫So we if the if there is a new developing things like or any changes or modify modification to this
‫program later on, if we are going to add new client type and we make discounts like for 10% we need
‫to go to here and put.
‫If client type equal AMI for example, then if there is a discount for 10% and this is a breaking the
‫open closed principle.
‫This is because even though the class is open for extension as we may have as many client types as we
‫like, it is not closed for modification.
‫So let's say that we want to add veteran type of client.
‫To do this, we should simply add another else if to our code.
‫So our may or veteran we need to add LCF code and this is breaking the open closed principle.
‫We should not put that code.
‫Come here and make it changing on that code.
‫Else if, else if and else if.
‫And so on.
‫Every time we need to make that change.
‫What is the solution to adhere to the principle?
‫We may split every type of client into a class and handle the check out calculation by abstraction that
‫if factoring of the code should be the following, so we create it.
‫Check out class.
‫It's alone.
‫We create a new class that extends from the check out and calculate.
‫At that total, we check.
‫We make a new class for the pregnant.
‫We make a new class for that veteran and so on.
‫And even if there is a new and new classes or new clients, so we should make this this connection between
‫and this extending and we may separate that code by using that abstraction.
‫So this is part of their regular client.
‫We are don't we don't have any discount for the veteran client.
‫We have 10% that pregnant 15 and the senior client 25.
‫So this is that obstruction of the code.
‫The third principle is called this cove substitution.
‫Every subclass or derived class should be substitutable for their base or parent class.
‫Both bark method calls will print.
‫This is a bark sound and the both mouse method calls will print this as meow sound.
‫If we consider that code below here there is a class animal, there is a bark and there is a meow method.
‫Class dog extends the animal.
‫It inherits the bark and inherits demure.
‫And the class cap extends from the animal.
‫It has the bark method and the meow method, but cats only meow not barking.
‫And the inverse is true for the dog.
‫So when we create two objects for dog and cat from animal, both will inherit the bark and both will
‫inherit the Miao method.
‫Okay, so we should not allow the dog to call the method meow.
‫And we should not call and allow the cat to bark.
‫Now, if we were to substitute the parent class with corresponding children, we would have the problem.
‫And this is the violation of the School of Substitution Principle.
‫What is the solution?
‫This is because dogs cannot meow and cats cannot bark.
‫Or, in other words, they cannot perform all the actions their parent can.
‫Also on the children class, some methods are turning on different types compared to what their parents
‫returns.
‫The code of this violation would be the following.
‫So.
‫Here any change to any corresponding.
‫We need to make the constant dog for new dog constant cat equal new cat.
‫And here we allow that dog to bark and cat to bark.
‫This will throw an exception or an error.
‫Also here, the dog to meow.
‫This will make an exception.
‫Okay.
‫How we have fixed this violation, we will create a more genetic method for the animal sound instead
‫of specific method for each animal sound.
‫And also, we will make sure that every method returns the same time that a fracturing of the code will
‫be the following.
‫We create a general class animal we make and extending and we make.
‫And in extending.
‫But here we don't have a bark.
‫And the Miao method we have make sound method.
‫This will inherit that dog will inherit the make sound and it will return this woof woof.
‫And the cat will made the sound and inherits this method and will return meow, meow.
‫So this is that the changing of the code according to its children.
‫And here is the same.
‫So that the parent should not make any sound.
‫It only specify the method makes sound and allows and make it obligatory for that children to make the
‫sound according to their time.
‫So if we create dog and cat from the new animal, we can now make a call.
‫The method make sound and make sound and there is no error because the dog will bark and the cat will
‫meow.
‫This by calling this refractory.
‫So this is the let's go substitution.
‫Interface segregation principle.
‫A client should never be forced to implement an interface that it does not use, or clients should not
‫be forced to depend on method they don't use.
‫Now, any shape you create must implement the volume method, but you should.
‫And you know that squares are flat shapes and that they don't have any volume.
‫So this interface would force the square class to implement a method that it has no use.
‫Okay, so this interface called Shape Interface two functions, the area and the volume, but the square
‫in duty, it does not have any volume.
‫So it will implement the volume method and it will not use it.
‫And this is a break and infringement of the interface segregation principle.
‫We should not implement any interface or that we are not going to use or we should not implement any
‫method that we are doing.
‫We are not going to use this would violate the interface segregation principle.
‫What is that solution?
‫Instead, you should create another interface called the three dimensional shape interface that has
‫the volume contract and the three dimensional shapes can implement this interface.
‫This is the shape interface, having an area and it is common between the square and the cube and.
‫And here we have the three dimensional shape, three dimensional interface or three dimensional shape
‫interface.
‫And it has that volume and which glass should only implement it.
‫It only the class cube will implement this three dimensional shape interface.
‫So you see guys that the common thing which is the area have been implemented for both the square and
‫the cube and the three dimensional shape interface is implemented only by the cube.
‫The fifth M principle is called dependency inversion.
‫Principle entities must depend.
‫On abstraction, not on concretion.
‫It states that the high level module must not depend on the low level modules, but they should depend
‫on abstraction.
‫How we do that.
‫This is a public class car.
‫It creates or three three objects, the engine in transmission, the and the wheels.
‫W If we create a constructor here, if we need to create a new car object, we need to create a.
‫Engine.
‫Our transmission and a wheel or wheels objects.
‫So an engine here is created inside the constructor by making new engine, the new transmission and
‫w new wheels.
‫And we have passed the parameters.
‫Okay, so consider the parameters for engine transmission and we as are strings.
‫Just for demonstration, this will depend or makes the car depend on three objects that we are creating
‫now so we don't ride like these.
‫If you are a professional coder because we are painting and creating this object upon creation of the
‫car and this will not be good and healthy for making like unit testing, like creating and making abstractions
‫and so on.
‫And this is what we are going to concentrate on in the next sections.
‫And this principle, well, it will be a very big, very big section and that we will discuss that dependency
‫injection and we will learn how to separate the codes and how to make our code clean, testable and
‫maintainable.
‫So these are the solid principles we have learned the first four very well because we have made a lot
‫of practices about them and especially in the MVP architecture.
‫Now let's move to learn about the dependency injection or dependency inversion principle and the dependency
‫injection sections.
‫Thank you, guys.
‫Let's move and start building our dependency injection apps and learn these very advanced.