Commit b03face9 authored by Jens Ehlers's avatar Jens Ehlers
Browse files

Class encapsulation

parent 637e5b00
Pipeline #4452 passed with stage
in 34 seconds
......@@ -143,4 +143,15 @@ public class SimpleRegressionModel {
<p>Die gezeigten Code-Beispiele zu JPMS finden sich im Verzeichnis <a href="/architecture/jpms" class="repo-link">/architecture/jpms</a> des Modul-Repository. Das folgende UML-Komponentendiagramm veranschaulicht die Abhängigkeiten der Module aus dem obigen Code-Beispiel. Es wird deutlich, wie das JPMS dazu beiträgt, Abhängigkeiten zwischen Komponenten explizit zu gestalten und ggf. einzuschränken.</p>
<img src="media/architecture_jpms.png" style="width:600px">
<label>UML-Komponentendiagramm zur Veranschaulichung des Java Platform Module System (JPMS)</label>
\ No newline at end of file
<label>UML-Komponentendiagramm zur Veranschaulichung des Java Platform Module System (JPMS)</label>
<h4>Kapselung auf Ebene von Klassen</h4>
<span>Bisher ist nur über Modularisierung und Kapselung auf Ebene von Komponenten gesprochen worden. Im Feinentwurf werden die Komponenten durch Klassen realisiert, die ebenfalls interne Daten- und Verhaltensstrukturen in Form von privaten Attributen und Methoden voreinander verstecken können. Dazu dienen in objektorientierten Sprachen insbesondere die Sicherbarkeitsmodifizierer <code>private</code> und <code>protected</code>. Wenn auf eine Klasse regelmäßig von außen zugegriffen wird, ist eine stabile Schnittstelle wichtig. Der Zugriff kann in diesem Fall sinnvoll über Getter- und Setter-Methoden gekapselt werden, um die zugrundeliegenden internen Strukturen verändern zu können, ohne den Zugriff von außen zu beeinflussen. Grundsätzlich stellt sich die Frage, vor welchen äußeren Zugriffen die internen Strukturen gekapselt werden sollen.</span>
<ul>
<li>Vor Zugriffen aus Methoden in anderen Klassen im selben Modul?</li>
<li>Oder vor Zugriffen aus anderen Modulen durch externe Anwender, die das eigene Modul als abhängige Bibliothek einsetzen?</li>
</ul>
<p>Im letzteren Fall kann der Aufwand, eine Veränderung der Schnittstelle durchzusetzen, sehr hoch sein, weil die externen Anwender etwaige Änderungen aus Trägheit ablehnen und ggf. als Anwender abspringen, oder weil sie aufgrund ihrer Vielzahl gar nicht vollständig bekannt sind, usw. Es werden aber auch viele Klassen entwickelt, die nur teamintern für eine kleine Anwendung oder ein kleines Modul genutzt und nicht nach außen über eine API weitergegeben werden. Wenn die Anzahl der Zugriffe auf die Strukturen einer Klasse übersichtlich ist und relativ einfach per Refactoring auch an den abhängigen Stellen geändert werden kann, ist zu überlegen, ob Getter und Setter tatsächlich erforderlich sind. Der strukturelle Aufbau der Klasse soll hier weiterhin einfach bleiben und nicht die Narben der Versionsgeschichte der Klasse abbilden. <i>Keep it simple!</i> Getter und Setter bleiben stets sinnvoll, wenn sie zusätzliche Funktionalitäten übernehmen und diese vom Aufrufer auch erwartet werden. Sichtbarkeit kann seit Java 9 aber z.T. sinnvoller auf Modulebene als auf Klassenebene eingeschränkt werden.</p>
<p>Das Projekt <a href="https://projectlombok.org/">Lombok</a> ermöglicht es in Java, Getter und Setter ohne weitere Funktionalität, die lediglich <i><a href="https://en.wikipedia.org/wiki/Boilerplate_code">Boilerplate-Code</a></i> darstellen, über die Verwendung von Annotationen wie <code>@Getter</code> und <code>@Setter</code> zur Kompilierungszeit zu generieren. In der verwendeten Entwicklungsumgebung muss ein entsprechendes Plugin (s. hier für <a href="https://projectlombok.org/setup/intellij">IntelliJ IDEA</a>) installiert werden, damit die Lombok-Annotationen auch während der Entwicklung aufgelöst werden können.</p>
\ No newline at end of file
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment