JAVA & Objektorientiertes Programmieren
Eine Einführung in das objektorientierte Programmieren mit JAVA Diese Kartei baut auf dem Stoff des Moduls OOP an der HSLU geleitet von Roland Gisler auf.
Eine Einführung in das objektorientierte Programmieren mit JAVA Diese Kartei baut auf dem Stoff des Moduls OOP an der HSLU geleitet von Roland Gisler auf.
Kartei Details
| Karten | 500 |
|---|---|
| Lernende | 19 |
| Sprache | Deutsch |
| Kategorie | Informatik |
| Stufe | Universität |
| Erstellt / Aktualisiert | 04.12.2016 / 16.08.2024 |
| Weblink |
https://card2brain.ch/box/java_objektorientiertes_programmieren
|
| Einbinden |
<iframe src="https://card2brain.ch/box/java_objektorientiertes_programmieren/embed" width="780" height="150" scrolling="no" frameborder="0"></iframe>
|
Ist eine Klasse vollständig abstrakt muss man ein Interface daraus machen!
In der Regel sollten alle Methoden einer abstrakten Klasse abstrakt sein
In der Regel sollte eine als abstrakt definierte Klasse auch mindestens eine abstrakte Methode enthalten
Will man "nur" die Instanziierung von Objekten verhindern, sollte man eine abstrakte Klasse mit jeweils nach Wunsch abstrakten und nicht abstrakten Methoden definieren
Will man "nur" die Instanziierung von Objekten verhindern, könnte man z.B. die Klasse finalisieren und einen privaten Konstruktor implementiere. Dies anstatt einer abstrakten Klasse!
Sind Interfaces abstrakt?
Ja sie sind vollständig abstrakt und es ist nicht möglich, davon Objekte zu instanziieren
Weshalb ist es nicht möglich Objekte von Interfaces zu instanziieren?
- Interfaces enthalten ausschliesslich Methodenköpfe
- Interfaces enthalten kein Attribute
- Interfaces enthalten keine Implementation
Wofür sind Interfaces geeignet?
Interfaces beschreiben ausschliesslich das "öffentliche" Verhalten von Klassen, was man gerne auch mit einer "Rolle" vergleicht.
- Keine Aussagen oder Annahmen über Implementation!
- Interfaces sind somit ein Mittel, das WAS (Methodenköpfe) zu definieren
Definieren Interfaces einen validen Typ?
Ja
Interfaces enthalten immer einen Konstruktor
Interfaces enthalten keinen Konstruktor
Da alle Methoden eines Interfaces implizit public und abstract sind, muss man public und abstract nicht schreiben (z.B. nur "void switchOn()" )
Wie sieht das Interface mit folgenden vier Methoden aus?
- void switchOn()
- void switchOff()
- boolean isSwitchedOn()
- boolean isSwitchedOff()
siehe Bild
Wie implementiert man ein Interface in einer Klasse?
siehe Bild
Die Implementation eines Interface zwingt die Klassen zur Implementation aller darin enthaltenen Methoden
Oft werden Interfaces verwendet, um teile zu separiere, die nur lose gekoppelt sein sollen, ohne weitere Gemeinsamkeit
Welche Elemente können im Javadoc dokumentiert werden?
Ist es sinnvoll alles im Javadoc zu dokumentieren?
Nein, man sollte bedürfnisorientiert dokumentieren -> vorallem für den Nutzer
Bei welchen Java-Elementen ist es absolute Pflicht sie zu dokumentieren?
Interfaces und deren Methoden
- Interfaces beschreiben den "Vertrag" und stellen, da sie mehrfach Implementiert werden können, Multiplikatoren dar!
Öffentliche Klassen und Methoden (die von Dritten verwendet werden können) sind in der Regel auch zu dokumentieren
In den meisten Objektorientierten Sprachen verwendet man Klassen, um in diesen Daten und Funktionen zusammengefasst abzubilden
Klassen (bzw. Module) interagieren dann gemeinsam miteinander und untereinander durch?
- gegenseitiges Ausstauschen von Daten
- über den gegenseitigen Aufruf von Methoden
Was wäre der Nachteil, wenn jede Klasse auf die Daten und Methoden jeder anderen Klasse Zugriff hätte? Was kann man dagegen machen?
Man hätte eine extrem starke gegenseitige Vernetzung und Abhängigkeit (starke Kopplung).
Eine lose Kopplung ist erwünscht, da es eine bessere Wiederverwendung einzelner Klassen und den leichteren Austausch von einzelnen Klassen zur Folge hat!
Lösung: Zugriffsmodifizierer!
Was bedeutet Datenkapselung?
Attribute werden nicht nur einfach gemeinsam in einer Klasse zusammengefasst (Kohäsion), sondern durch explizite Zugriffsmodifizierer feingranular und differenziert gekapselt.
Was sind Zugriffsmodifizierer?
Legen fest, ob ein Element überhaupt, und wenn ja, für welche anderen Klassen sichtbar (und somit referenzier- oder aufrufbar) ist.
Bei welchen Java-Elementen können Zugriffsmodifizierer verwendet werden?
Was bedeutet es, wenn ein Java-Element public ist?
Sichtbar in der Klasse selbst und auch in allen anderen Klassen, egal in welchem Package (maximale Sichtbarkeit, vollständig öffentlich)
Darstellung in UML: +
public wird of bei Attributen eingesetzt
Was bedeutet es, wenn ein Java-Element private ist?
Ausschliesslich sichtbar in der Klasse selbst, nirgends sonst! (Maximale Kapselung, vollständig privat)
Kann somit ohne Einfluss auf Dritte jederzeit verändert werden
Darstellung in UML: -
Was bedeutet es, wenn ein Java-Element keinen expliziten Zugriffsmodifizierer hat?
Dann ist es sichtbar in der Klasse selbst, und für jede Klasse des selben Packages zu dem diese Klasse gehört: package - Zugriff (default)
Kein Schlüsselwort!
Darstellung in UML: ~
Was bedeutet es, wenn ein Java-Element protected ist?
Sichtbarkeit wie "package", zusätzlich aber auch in allen davon spezialisierten Klassen (egal in welchem Package)
Einsatz selten, und eher bei Methoden
Darstellung in UML: #
Studiere diese Matrix der Zugriffsmodifizierer
Kennst du nun alle Zugriffsmodifizierer?
Definiere die Sichtbarkeit der Java-Elemente so verschlossen wie möglich, und so offen wie nötig, aber auf jeden Fall immer bewusst
Datenkapselung kann auch bedeuten, ganz bewusst eine Methode wegzulassen, oder Zugriff differenzierter zu steuern, z.B. um Schreibzugriffe komplett zu verhindern
Das folgende Beispiel einer Klasse verfügt weder über Datenkapselung noch Information Hiding. Wie könnte man dies besser implementieren?
(Das Attribut celsius kann von beliebigen anderen Klassen beliebig gelesen und geschrieben werden)
(Somit ist weder Kontrolle des Wertes, noch jemals z.B. eine Änderung des möglich, ohne umfangreiches Refactoring aller Klassen die Temperatur verwenden)
Das Attribut ist privat und somit geschützt.
Es existieren Setter- und Getter-Methoden, die eine Kontrolle des Zugriffes auf das Attribut erlauben
Lese- und Schreibzugriff sind bzw. sind getrennt kontrollierbar
Die Schnittstellen lassen aber den Schluss zu, dass die Temperatur tatsächlich auch intern als float und inder Einheit Celcius gespeicher wird
Hier wird fundamentales Datenkapseln angewandt.
Könnte man die Klasse noch besser schützen?
Die Schnittstellen sind zwar unverändert, tatsächlich wird die Temperatur jetzt aber in Kelvin gespeichert!
In diesem einfachen Beispiel eher sinnlos, könnte man aber durchaus den internen Datentyp z.B. auf double verändern.
Spätestens wenn man z.B. noch get- und setFahrenheit() ergänzen würde, ist die interne Repräsentation völlig "versteckt"!
Bei den Parametern und Rückgabewerten der Methoden achtet man darauf, das diese möglich viele Information über die interne Repräsentation (oder gar direkte Referenzen) preis geben
Die Zugriffsmodifizierer private, "package", protected und public werden für den Zugriffsschutz auf Attribute, Methoden und Klassen verwendet
Gutes Information Hiding erlaubt eine möglichst 1.)_________ zwischen den Klassen, gleichzeitig kann man die Implementation in einem gewissen Spielraum 2.)__________ verändern und anpassen
Was ist die stärkste Form von Kopplung in der Objektorientierung?
Vererbung
