{"id":247,"date":"2022-12-03T21:09:33","date_gmt":"2022-12-03T21:09:33","guid":{"rendered":"https:\/\/codingwithleo.xyz\/?p=247"},"modified":"2023-03-15T20:46:53","modified_gmt":"2023-03-15T20:46:53","slug":"solid-the-interface-segregation-principle","status":"publish","type":"post","link":"https:\/\/codingwithleo.xyz\/index.php\/2022\/12\/03\/solid-the-interface-segregation-principle\/","title":{"rendered":"SOL[I]D – The interface segregation principle"},"content":{"rendered":"\n

We can use the previous classes design to exemplify The Interface Segregation Principle as well. To demonstrate the importance of this principle, consider the scheme below.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

In the diagram, we can see 3 classes (Fiat, Chevrolet and Hyundai) that implement the “Car” interface. We can see the correspondent code below:<\/p>\n\n\n\n

class Car\n{\npublic:\n\n\tvirtual void accelerate() = 0;\n\tvirtual void brake() = 0;\n\tvirtual void putGas() = 0;\n\tvirtual ~Car();\n}\n\nclass Fiat : public Car\n{\npublic:\n\n\tvirtual void accelerate() override \n\t{ \/* Increment the velocity *\/ }\n\tvirtual void brake() override \n\t{ \/* Reduce the velocity *\/ }\n\tvirtual void putGas() override \n\t{ \/* Insert some fuel in the tank *\/ }\n}\n\nclass Chevrolet : public Car\n{\npublic:\n\n\tvirtual void accelerate() override \n\t{ \/* Increment the velocity *\/ }\n\tvirtual void brake() override \n\t{ \/* Reduce the velocity *\/ }\n\tvirtual void putGas() override \n\t{ \/* Insert some fuel in the tank *\/ }\n}\n\nclass Hyundai : public Car\n{\npublic:\n\n\tvirtual void accelerate() override \n\t{ \/* Increment the velocity *\/ }\n\tvirtual void brake() override \n\t{ \/* Reduce the velocity *\/ }\n\tvirtual void putGas() override \n\t{ \/* Insert some fuel in the tank *\/ }\n}<\/code><\/pre>\n\n\n\n
All cars must implement the 3 functions of the interface, these are: accelerate()<\/code>, brake()<\/code> and putGas()<\/code>. These functions do the exact thing that their name suggests, so it will be weird if we decided to implement a new car brand that doesn’t uses gas as its com fuel.<\/p>\n\n\n\n
For example, all Tesla-branded cars will use only energy as their fuel. Imagine that this system we are managing\/programming exists for some years and we are responsible just to make some maintenance in the code. Well, it’s will be a hard problem, because there’s no way to implement it in a good manner without refactoring some parts of the code.<\/p>\n\n\n\n
Look at the suggestion below:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Here we are creating a new class called “Tesla” and implementing the same interface on it. The problem is we’ll need to create a method called plugToEnergy()<\/code> in Car interface because Teslas won’t use the putGas()<\/code> method at all.<\/p>\n\n\n\n
The second problem is that we’ll be forced to implement inside all the other car brands the plugToEnergy()<\/code> method even though we don’t use it because the other cars aren’t electric. In the same way, the method putGas()<\/code> needs to be implemented inside Tesla, otherwise, it will break our compilation. Here’s the code for this situation:<\/p>\n\n\n\n
class Car\n{\npublic:\n\n\tvoid accelerate() = 0;\n\tvoid brake() = 0;\n\tvoid putGas() = 0;\n\tvoid plugToEnergy() = 0;\n\tvitual ~Car();\n}\n\nclass Tesla : public Car\n{\npublic:\n\n\tvirtual void accelerate() override \n\t{ \/* Increment the velocity *\/ }\n\tvirtual void brake() override \n\t{ \/* Reduce the velocity *\/ }\n\tvirtual void putGas() override\n\t{ \/* Does nothing because there's no fuel tank *\/ }\n\tvirtual void plugToEnergy() override\n\t{ \/* Charge the car *\/ }\n}\n\nclass Fiat : public Car\n{\n\tpublic:\n\n\tvirtual void accelerate() override\n\t{ \/* Increment the velocity *\/ }\n\tvirtual void brake() override\n\t{ \/* Reduce the velocity *\/ }\n\tvirtual void putGas() override\n\t{ \/* Insert some fuel in the tank *\/ }\n\tvirtual void plugToEnergy() override\n\t{ \/* Does nothing because it's not a electric car *\/ }\n}\n\nclass Chevrolet : public Car\n{\n\tpublic:\n\n\tvirtual void accelerate() override\n\t{ \/* Increment the velocity *\/ }\n\tvirtual void brake() override\n\t{ \/* Reduce the velocity *\/ }\n\tvirtual void putGas() override\n\t{ \/* Insert some fuel in the tank *\/ }\n\tvirtual void plugToEnergy() override\n\t{ \/* Does nothing because it's not a electric car *\/ }\n}\n\nclass Hyundai : public Car\n{\n\tpublic:\n\n\tvirtual void accelerate() override\n\t{ \/* Increment the velocity *\/ }\n\tvirtual void brake() override\n\t{ \/* Reduce the velocity *\/ }\n\tvirtual void putGas() override\n\t{ \/* Insert some fuel in the tank *\/ }\n\tvirtual void plugToEnergy() override\n\t{ \/* Does nothing because it's not a electric car *\/ }\n}<\/code><\/pre>\n\n\n\n
The Interface Segregation Principle says that the situation above isn’t good because it will break our production and limit our program’s extensibility. The correct way to handle it is to segregate<\/strong><\/em> the car functionality from the engine fuel functionality. So, we’ll have a car interface for the methods accelerate()<\/code> and brake()<\/code> because all cars do that. The other interfaces called Combustion Engine and Electric Engine will be responsible to charge the car or put some gas on it depending on the engine. Take a look at the diagram and code below:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
class Car\n{\npublic:\n\n\tvirtual void accelerate() = 0;\n\tvirtual void brake() = 0;\n\tvirtual ~Car();\n}\nclass CombustionEngine\n{\npublic:\n\n\tvirtual void putGas() = 0;\n\tvirtual ~CombustionEngine();\n}\n\nclass ElectricEngine\n{\npublic:\n\n\tvirtual void plugToEnergy() = 0;\n\tvirtual ~ElectricEngine();\n}\n\nclass Fiat : public Car, public CombustionEngine\n{\npublic:\n\n\tvirtual void accelerate() override\n\t{ \/* Increment the velocity *\/ }\n\tvirtual void brake() override \n\t{ \/* Reduce the velocity *\/ }\n\tvirtual void putGas() override\n\t{ \/* Insert some fuel in the tank *\/ }\n}\n\nclass Chevrolet : public Car, public CombustionEngine\n{\npublic:\n\n\tvirtual void accelerate() override\n\t{ \/* Increment the velocity *\/ }\n\tvirtual void brake() override\n\t{ \/* Reduce the velocity *\/ }\n\tvirtual void putGas() override\n\t{ \/* Insert some fuel in the tank *\/ }\n}\n\nclass Hyundai : public Car, public CombustionEngine\n{\npublic:\n\n\tvirtual void accelerate() override\n\t{ \/* Increment the velocity *\/ }\n\tvirtual void brake() override\n\t{ \/* Reduce the velocity *\/ }\n\tvirtual void putGas() override\n\t{ \/* Insert some fuel in the tank *\/ }\n}\n\nclass Tesla : public Car, public ElectricEngine\n{\npublic:\n\t\n\tvirtual void accelerate() override\n\t{ \/* Increment the velocity *\/ }\n\tvirtual void brake() override\n\t{ \/* Reduce the velocity *\/ }\n\tvirtual void plugToEnergy() override\n\t{ \/* Charge the car *\/ }\n}<\/code><\/pre>\n\n\n\n
Now, there are useless functions neither in combustion cars nor in electric cars. As I said before, the good solution above will need some code refactoring of the original problem, but it will be a good thing for your project because this way you are safe for expanding your system without making too big changes. Using the interface segregation will guarantee that on future changes you will need to compile and deploy just the part of the software that was really changed instead to recompile and deploy the classes\/methods that already working well in the program.<\/p>\n","protected":false},"excerpt":{"rendered":"
We can use the previous classes design to exemplify The Interface Segregation Principle as well. To demonstrate the importance of this principle, consider the scheme below. In the diagram, we can see 3 classes (Fiat, Chevrolet and Hyundai) that implement the “Car” interface. We can see the correspondent code below: All cars must implement the […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[3,6,7],"tags":[],"_links":{"self":[{"href":"https:\/\/codingwithleo.xyz\/index.php\/wp-json\/wp\/v2\/posts\/247"}],"collection":[{"href":"https:\/\/codingwithleo.xyz\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/codingwithleo.xyz\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/codingwithleo.xyz\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/codingwithleo.xyz\/index.php\/wp-json\/wp\/v2\/comments?post=247"}],"version-history":[{"count":15,"href":"https:\/\/codingwithleo.xyz\/index.php\/wp-json\/wp\/v2\/posts\/247\/revisions"}],"predecessor-version":[{"id":310,"href":"https:\/\/codingwithleo.xyz\/index.php\/wp-json\/wp\/v2\/posts\/247\/revisions\/310"}],"wp:attachment":[{"href":"https:\/\/codingwithleo.xyz\/index.php\/wp-json\/wp\/v2\/media?parent=247"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/codingwithleo.xyz\/index.php\/wp-json\/wp\/v2\/categories?post=247"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/codingwithleo.xyz\/index.php\/wp-json\/wp\/v2\/tags?post=247"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}