{"id":1661,"date":"2021-03-06T11:57:43","date_gmt":"2021-03-06T10:57:43","guid":{"rendered":"http:\/\/mateuszglowinski.pl\/?p=1661"},"modified":"2021-03-06T15:17:46","modified_gmt":"2021-03-06T14:17:46","slug":"interface-segregation-principle","status":"publish","type":"post","link":"https:\/\/mateuszglowinski.pl\/index.php\/2021\/03\/06\/interface-segregation-principle\/","title":{"rendered":"Interface Segregation Principle"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

What is „Interface Segregation Principle” (ISP) ?<\/h4>

It is the fourth<\/span><\/span> rule of the SOLID design rules (it stands for I in SOLID acronym).<\/span><\/span><\/p>

Definition<\/h4>

Clients should not be forced to depend upon interfaces that they do no use.<\/p>

\u00a0<\/div>
Robert C. Martin (Uncle Bob)<\/div><\/div><\/blockquote>

In simpler words<\/span><\/span>, we should avoid situation where class inheriting from interface do not use some parts of the interface. <\/span><\/span>Interfaces should be specific and as small as possible.<\/span><\/span> <\/span><\/span><\/p>

Real-life example<\/h4>

Let’s say we want to implement classes for car, airplane and multifunctional car (like in Taxi movie).<\/p>

public interface Vehicle {\n    void drive();\n\n    void fly();\n}\n<\/pre>
public class Car implements Vehicle {\n    public void drive() {\n        System.out.println(\"Driving a car\");\n    }\n\n    public void fly() {\n    }\n}\n<\/pre>
public class Airplane implements Vehicle {\n    public void drive() {\n    }\n\n    public void fly() {\n        System.out.println(\"Flying a plane\");\n    }\n}\n<\/pre>
public class MultiFunctionalCar implements Vehicle {\n    public void drive() {\n        System.out.println(\"Drive a multifunctional car\");\n    }\n\n    public void fly() {\n        System.out.println(\"Fly a multifunctional car\");\n    }\n}\n<\/pre>
UML diagram of our application:<\/p>
\"\"<\/p>
Fly<\/em> method in Car<\/em> class is empty, the same about drive<\/em> method in Airplane<\/em> class. It means that Vehicle<\/em> interface contains too many parts for our needs and due to that our program does not meet ISP<\/em> rule.<\/p>
To fix it, we need to split Vehicle<\/em> interface into smalled interfaces e.g. ICar and IAirplance.<\/p>
public interface ICar {\n    void drive();\n}\n<\/pre>
public interface IAirplane {\n    void fly();\n}\n<\/pre>
public class Car implements ICar {\n    public void drive() {\n        System.out.println(\"Driving a car\");\n    }\n}\n<\/pre>
public class Airplane implements IAirplane {\n    public void fly() {\n        System.out.println(\"Flying a plane\");\n    }\n}\n<\/pre>
public class MultiFunctionalCar implements ICar, IAirplane {\n    public void drive() {\n        System.out.println(\"Drive a multifunctional car\");\n    }\n\n    public void fly() {\n        System.out.println(\"Fly a multifunctional car\");\n    }\n}\n<\/pre>
Now classes implement only necessary methods, it means that interfaces are consistent with the ISP<\/em> rule.<\/span><\/span><\/p>
UML diagram of our application after refactoring:<\/p>
\"\"<\/p>
Why should I follow „Interface Segregation Principle” ?<\/h4>
Thanks to this rule, the code is easier to extend and maintain. Less tricky interfaces also mean more clear code.<\/p>
What to look for?<\/h4>
ISP<\/em> is not the same as LSP<\/em>. Focus in ISP<\/em> is not about making classes replaceable, but rather on rethinking initial design and picking up proper abstractions when designing a system.<\/p><\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t","protected":false},"excerpt":{"rendered":"
What is „Interface Segregation Principle” (ISP) ? It is the fourth rule of the SOLID design rules (it stands for I in SOLID acronym). Definition…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[34],"tags":[35],"_links":{"self":[{"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/posts\/1661"}],"collection":[{"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/comments?post=1661"}],"version-history":[{"count":46,"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/posts\/1661\/revisions"}],"predecessor-version":[{"id":1752,"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/posts\/1661\/revisions\/1752"}],"wp:attachment":[{"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/media?parent=1661"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/categories?post=1661"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/tags?post=1661"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}