5 Objektorientiertes Design

Weitere Magazine

Empfehlungen

Info

62 3 <strong>Objektorientiertes</strong> <strong>Design</strong> Führen wir das Programm als Ant-Target REFERENCESEMANTICSEXAMPLE aus, so werden die ersten beiden Einträge "Test1" und "Test2" des Arrays geändert. Wir erhalten folgende Ausgabe: [Michael, changed this entry, !!!] Außerdem wird durch diese Ausgabe offensichtlich, dass die Neuzuweisung der Referenz innerhalb der Methode sich nicht in der main()-Methode auswirkt, Wertänderungen einzelner Elemente dagegen schon. Das gilt ebenso für Datenstrukturen aus dem Collections-Framework (vgl. Kapitel 5), etwa für Listen und Mengen. Dieser Sachverhalt sollte einem immer bewusst sein, da sich ansonsten leicht Fehler einschleichen, die schwierig zu finden sind. Call-by-Value bezieht sich in Java wirklich ausschließlich auf den Wert der Referenz bzw. des primitiven Typs. Auf weitere Auswirkungen der Referenzsemantik werde ich im Verlauf dieses Buchs, insbesondere in Abschnitt 3.4.1, detaillierter eingehen. Lebenszyklus von Objekten und Speicherfreigabe Der Lebenszyklus eines Objekts beginnt bei dessen Konstruktion. Ein Objekt ist an sein »Lebensende« gelangt, wenn keine Referenzvariable mehr auf dieses Objekt verweist. Folglich kann es von keiner Stelle im Programm mehr erreicht und angesprochen werden. Der genaue Zeitpunkt des »Ablebens« und der damit verbundenen Speicherfreigabe kann in der JVM nicht exakt bestimmt werden. Das liegt daran, dass die Aufräumarbeiten und die Speicherfreigabe durch einen speziellen Mechanismus zur Speicherbereinigung, die sogenannte Garbage Collection, erfolgen. Die konkreten Zeitpunkte der Ausführung sind nicht vorhersehbar, da diese von der gewählten Aufräumstrategie und des gerade belegten und noch freien Speichers abhängig sind. Details dazu beschreibt Abschnitt 8.7. Sichtbarkeiten Beim objektorientierten Programmieren unterscheidet man verschiedene Sichtbarkeiten, die festlegen, ob und wie andere Klassen auf Methoden und Attribute zugreifen dürfen. Java bietet folgende vier Sichtbarkeiten: ■ ■ ■ ■ public – von überall aus zugreifbar protected – Zugriff für abgeleitete Klassen und alle Klassen im selben Package Package-private oder default (kein Schlüsselwort 5 ) – nur Klassen im selben Package haben Zugriff darauf private – nur die Klasse selbst und alle ihre inneren Klassen haben Zugriff Kapselung Die Kapselung von Daten (Information Hiding) stellt einen Weg dar, die Attribute eines Objekts vor dem direkten Zugriff und der direkten Manipulation durch andere Objekte zu schützen. Dazu kann man die Sichtbarkeit der Attribute auf 5 Man kann diese Sichtbarkeit durch einen Kommentar der Form /*private*/ bzw. /*package*/ andeuten. Dies ist hilfreich, um versehentliche Sichtbarkeitserweiterungen zu verhindern. Man dokumentiert somit, dass bewusst diese Sichtbarkeit gewählt wurde.
3.1 OO-Grundlagen 63 protected, Package-private oder private einschränken. Das ist ebenfalls für Methoden möglich. Auf diese Weise erreicht man durch die Definition von Sichtbarkeitsregeln eine Strukturierung und Kapselung: Die Klasse kann durch die Zugriffsmethoden die Möglichkeiten zum Zugriff auf Attribute selbst steuern oder einschränken. Objektverhalten und Business-Methoden Das Verhalten der Instanzen einer Klasse ist durch die bereitgestellten Methoden definiert. Diese Methoden weisen unterschiedliche Abstraktionsgrade und verschiedene Sichtbarkeiten auf. Einige Arbeitsund Hilfsmethoden verwenden viele Implementierungsdetails und arbeiten direkt mit den Attributen der Klasse. Sie sollten bevorzugt private oder Package-private definiert werden. Meistens realisieren nur wenige der Methoden einer Klasse »High- Level-Operationen« mit einem hohen Abstraktionsgrad. Diese verhaltensdefinierenden Methoden bilden in der Regel die Schnittstelle der Klasse nach außen. 6 Derartige Methoden nennt man auch Business-Methoden. Sie verstecken die komplexen internen Vorgänge. Auf diese Weise erreicht man folgende Dinge: ■ ■ ■ Abstraktion und Datenkapselung – Implementierungsdetails werden versteckt. Klare Abhängigkeiten – Wenn Zugriffe durch andere Klassen nur über die Business-Methoden erfolgen, existieren wenige und klare Abhängigkeiten. Austauschbarkeit und Wiederverwendbarkeit – Werden die Business-Methoden durch ein Interface beschrieben, so kann ein Austausch der Realisierung ohne Rückwirkung auf Nutzer erfolgen. Tipp: Zusammensetzung und Aufrufhierarchien von Methoden Um den Sourcecode übersichtlich zu halten, sollten sich öffentliche Methoden aus Methodenaufrufen anderer Sichtbarkeiten zusammensetzen und wenig Implementierungsdetails zeigen. Zudem sollten Methoden niemals andere Methoden höherer Sichtbarkeit aufrufen; eine private Methode »darf« demnach keine öffentliche Methode aufrufen. Diese Strukturierung hilft vor allem, wenn man Datenänderungen verarbeiten und an andere Klassen kommunizieren muss. Ohne die Einhaltung dieses Hinweises kommt es schnell zu einem Chaos. Kohäsion Beim objektorientierten Programmieren verstehen wir unter Kohäsion, wie gut eine Methode tatsächlich genau eine Aufgabe erfüllt. Je höher die Kohäsion, desto besser realisiert eine Methode lediglich eine spezielle Funktionalität. Bei hoher Kohäsion ist eine gute Trennung von Zuständigkeiten erfolgt. Methoden mit hoher Kohäsion können normalerweise gut kombiniert werden, um neue Funktionalitäten zu realisieren. Dies hilft bei der Wiederverwendbarkeit. Je niedriger auf der anderen Seite die 6 Die Schnittstelle kann explizit über ein Interface beschrieben werden oder aber durch die Definition von Methoden mit der Sichtbarkeit public.
Seite 1 und 2: 57 3 Objektorientiertes Design Dies
Seite 3 und 4: 3.1 OO-Grundlagen 59 Typen Durch Kl
Seite 5: 3.1 OO-Grundlagen 61 Betrachten wir
Seite 9 und 10: 3.1 OO-Grundlagen 65 Kopplung Unter
Seite 11 und 12: 3.1 OO-Grundlagen 67 erreicht, d. h
Seite 13 und 14: 3.1 OO-Grundlagen 69 3.1.2 Beispiel
Seite 15 und 16: 3.1 OO-Grundlagen 71 if (graphicObj
Seite 17 und 18: 3.1 OO-Grundlagen 73 final Counter
Seite 19 und 20: 3.1 OO-Grundlagen 75 Erweiterbarkei
Seite 21 und 22: 3.1 OO-Grundlagen 77 1. diese Klass
Seite 23 und 24: 3.1 OO-Grundlagen 79 Vererbung und
Seite 25 und 26: 3.1 OO-Grundlagen 81 standsübergä
Seite 27 und 28: 3.1 OO-Grundlagen 83 Invarianten, V
Seite 29 und 30: 3.1 OO-Grundlagen 85 Diese Zwischen
Seite 31 und 32: 3.1 OO-Grundlagen 87 3. Es müssen
Seite 33 und 34: 3.2 Grundlegende OO-Techniken 89 Ö
Seite 35 und 36: 3.2 Grundlegende OO-Techniken 91 Be

5 Objektorientiertes Design

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?