Hallo Spa\u00df-Coder.<\/p>\n
Wer von euch hat schon einmal ein Interface implementiert und findet anschlie\u00dfend ein oder mehrere leere Methoden oder Methoden mit throw new NotImplementedException()<\/em> in seiner neuen Klasse wieder? Warum? Weil einfach zu viele Methoden im Interface vorgesehen sind, die mit der eigentlichen Aufgabe gar nichts zu tun haben. Hier werden wir immer wieder dazu gezwungen, viele Methoden in der Implementierung anbieten zu m\u00fcssen, was auf der anderen Seite auch die Verwendung des Interfaces auf Grund dieser hohen Anzahl von Methoden nicht gerade einfach macht. Schauen wir uns daher das vierte Prinzip der SOLI<\/strong>D-Prinzipien an.<\/p>\n <\/p>\n \u201eClients sollten nicht dazu gezwungen werden, von Interfaces abzuh\u00e4ngen, die sie nicht verwenden.\u201c<\/p>\n \u2013 Robert C. Martin<\/span>: The Interface Segregation Principle (Quelle: Wikipedia<\/a>)<\/p><\/blockquote>\n <\/p>\n Im Wesentlichen geht es beim ISP mal wieder um eine gute Namensgebung und der Umsetzung von einer<\/strong> konkreten Anforderung. Ein schlecht gew\u00e4hlter Name eines Interfaces f\u00fchrt unweigerlich dazu, dass hier viele Methoden landen werden, die m\u00f6glicherweise wenig gemein haben.<\/p>\n Zu was f\u00fchrt denn ein umfangreiches Interface, welches Problem entsteht dabei? Bei einer Klasse streben wir lose Kopplung und eine hohe Koh\u00e4sion an. Lose Kopplung bedeutet hier, die Abh\u00e4ngigkeiten zwischen Klassen so gering wie m\u00f6glich zu halten, damit die Austauschbarkeit gegeben ist. Die Koh\u00e4sion gibt an, wie sehr eine Klasse tats\u00e4chlich zusammengeh\u00f6rig ist. Wenn nun alle Methoden der Klasse alle Klassenvariablen verwenden, so ist die Koh\u00e4sion hoch. Verwendet ein Teil der Methoden einen Teil der Klassenvariablen und alle anderen Methoden genau die anderen Klassenvariablen, so ist dies ein Indikator (Code-Smell) daf\u00fcr, dass die Klasse sich sinnvoll auf zwei Klassen aufteilen l\u00e4sst – die beiden Teile haben offensichtlich wenig miteinander zu tun.<\/p>\n Ein Code-Smell f\u00fcr zu gro\u00dfe Interfaces findet ihr auf der Seite des Clients, also bei der Verwendung des Interfaces. Werden regelm\u00e4\u00dfig nur wenige bestimmte Methoden eines Interfaces verwendet oder in bestimmten Situationen nur eine kleine Auswahl von Methoden ben\u00f6tigt, so zeigt dies an, dass das Interface m\u00f6glicherweise zu umfangreich gew\u00e4hlt ist. Habt ihr schon einmal durch die lange Liste von Methoden eines Interfaces gebl\u00e4ttert um die richtige Methoden zu finden, die gerade aufzurufen ist? L\u00e4stig.<\/p>\n Schauen wir uns ein kleines Beispiel aus der OSGI-Implementierung mit Felix an.<\/p>\n F\u00fcr das Interface BundleActivator<\/em> werden die beiden Methoden start(…)<\/em> und stop(…)<\/em> implementiert, f\u00fcr das Interface ServiceListener<\/em> die Methode serviceChanged(…)<\/em>. Nun h\u00e4tten beide Methoden auch in einem einzigen Interface bereitgestellt werden k\u00f6nnen, jedoch w\u00e4re ich dann gezwungen gewesen, alle drei Methoden in einer Klasse zu implementieren. So habe ich die Wahl, eine separate ServiceListener<\/em>-Implementierung bereitzustellen. Der BundleActivator<\/em> f\u00fcgt den ServiceListener<\/em> dem BundleContext<\/em> hinzu bzw. entfernt diesen, das hat nichts mit der Reaktion auf das serviceChanged<\/em>-Event zu tun.<\/p>\n <\/p>\n Ist es ein Problem, bei Bedarf zwei oder mehr Interfaces zu implementieren? Nat\u00fcrlich nicht. Dabei kann aber jeder Implementierer entscheiden, welche der Methoden ben\u00f6tigt und demnach welche Interfaces implementiert werden. Bei nur einem umfangreichen Interface besteht diese Wahlm\u00f6glichkeit erst gar nicht.<\/p>\n Hei\u00dft dies nun, dass in jedem Interface nur eine Methode enthalten sein sollte? Wer gerade seine Schwarz-Wei\u00df-Brille aufgesetzt hat, mag dies so sehen, jedoch ist das nicht die Intention des ISP. Stattdessen sollten alle Methoden in einem Interface zusammengefasst werden, die tats\u00e4chlich auch zusammen geh\u00f6ren und eine bestimmte Anforderung abbilden – so klein wie m\u00f6glich, so gro\u00df wie n\u00f6tig. Diese Idee kommt euch nat\u00fcrlich aus dem Single Responsibility Principle<\/a> bekannt vor, oder?<\/p>\n <\/p>\n Bei der Durchsicht unserer Codebasis sind mir tats\u00e4chlich sehr wenige Interfaces aufgefallen, die wir aufteilen sollten. Mit kleinen Interfaces zu arbeiten ist aus unserer Sicht deutlich einfacher und macht damit auch viel mehr Spa\u00df. Wie oben beschrieben wird die Definition der Interfaces durch einen aussagekr\u00e4ftigen Namen deutlich unterst\u00fctzt.<\/p>\n Aber wie gehe ich vor, wenn ich denn nun ein Interface aufteilen m\u00f6chte, ohne s\u00e4mtliche bereits vorhandenen Implementierer zu \u00e4ndern? Das Refaktorisierungs-Muster „Extract Interface“ kann auch in diesem Fall angewendet werden.<\/p>\n <\/p>\n Auch das I<\/strong>nterface S<\/strong>egregation P<\/strong>rinciple<\/em> sorgt f\u00fcr eine modularisierte Anwendung mit kleinen, \u00fcberschaubaren und wiederverwendbaren Einheiten. Eine gute Namensgebung sowie Paket- \/ Namensraum-Organisation sorgt daf\u00fcr, dass jeder Entwickler genau die Klassen und Interfaces findet, die er ben\u00f6tigt.<\/p>\n <\/p>\n Viel Spa\u00df beim Anwenden.<\/p>\n Eure Spa\u00df-Coder. Hallo Spa\u00df-Coder. Wer von euch hat schon einmal ein Interface implementiert und findet anschlie\u00dfend ein oder mehrere leere Methoden oder Methoden mit throw new NotImplementedException() in seiner neuen Klasse wieder? Warum? Weil einfach zu viele Methoden im Interface vorgesehen sind, die mit der eigentlichen Aufgabe gar nichts zu tun haben. Hier werden wir immer wieder […]<\/p>\n","protected":false},"author":2,"featured_media":344,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[90],"tags":[48,57,20,44],"_links":{"self":[{"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/posts\/334"}],"collection":[{"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/comments?post=334"}],"version-history":[{"count":7,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/posts\/334\/revisions"}],"predecessor-version":[{"id":347,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/posts\/334\/revisions\/347"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/media\/344"}],"wp:attachment":[{"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/media?parent=334"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/categories?post=334"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/tags?post=334"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Interface Segregation Principle (ISP)<\/h2>\n
Erl\u00e4uterung des Prinzips<\/h2>\n
package tutorial.example1;\r\n\r\nimport org.osgi.framework.BundleActivator;\r\nimport org.osgi.framework.BundleContext;\r\nimport org.osgi.framework.ServiceEvent;\r\nimport org.osgi.framework.ServiceListener;\r\n\r\npublic class Activator implements BundleActivator, ServiceListener {\r\n\r\n\t@Override\r\n\tpublic void serviceChanged(ServiceEvent event) {\r\n\t\t[...]\r\n\t}\r\n\r\n\t@Override\r\n\tpublic void start(BundleContext context) throws Exception {\r\n System.out.println(\"Starting to listen for service events.\");\r\n context.addServiceListener(this);\r\n\t}\r\n\r\n\t@Override\r\n\tpublic void stop(BundleContext context) throws Exception {\r\n\t\tcontext.removeServiceListener(this);\r\n System.out.println(\"Stopped listening for service events.\");\t\t\r\n\t}\r\n}\r\n<\/pre>\nUnsere Erfahrung mit dem ISP<\/h2>\n
\n
Zusammenfassung<\/h2>\n
\nDieser Artikel basiert neben unseren Erfahrungen auf verschiedenen Internetquellen.<\/p>\n","protected":false},"excerpt":{"rendered":"