Java Prinzipien objektorientierter Softwareentwicklung

[Slight]

Halloo,

Ich schreibe bald eine Klausur im Modul Softwaretechnik. Dabei werden die Prinzipien der objektorientierter Softwareentwicklung eine Rolle spielen, die man in Design Patterns wiederfinden soll. Ich wusste nicht in welches Forum ich es schreiben sollte, und weil das Thema zu Java gehört, habe ich mich für dieses entschieden, und hoffe, hier kennt sich einer damit aus und kann mir weiterhelfen.

Wir haben das Singleton, Factory, Builder und Observer Pattern besprochen und sollen dort die Prinzipien Abstraktion, Objektidentitäten, Berücksichtigung verschiedener Organsiationsprinzipien (Objekte lassen sich anhand verschiedener Hierarchieebenen anordnen), Vererbung, Kapselung, Geheimnisprinzip, Kommunikation unter Objekten und Polymorphismus ausfindig machen. Meine Frage ist eigentlich nur, ob ich das alles so richtig gemacht habe, und ob es vielleicht was zu ergänzen gibt. Falls ich etwas zu ungenau geschrieben habe, sagt mir bitte Bescheid.
Vielen Dank im Voraus!

Im Singleton findet man
- Objektidentitäten, Singleton soll ja gewährleisten, dass eine bestimmte Komponente nur einmal innerhalb eines Systems vorkommt, dafür sorgt die getInstance-Methode, da ich von dieser immer das selbe Objekt zurück bekomme. Das wäre in dem Fall Identität und nicht Gleichheit, habe ich das so richtig verstanden?
- Kapselung, wegen der privaten Methode Singleton() und dem privaten Attribut INSTANCE
- Geheimnisprinzip: Kapselung ist die Zugriffskontrolle für die Daten, die hier wie schon gesagt, zu finden ist. Es gibt keinen direkten Zugriff auf die INSTANCE-Variable, jedoch wird Zugriff über die getInstance-Methode gewährt.

Abstraktion, Berücksichtigung versch. Org., Vererbung, Kommunikation unter Objekten und Polymorphismus sind hier nicht zu finden.

Im Builder findet man:
- Abstraktion weil die zwei ConcreteBuilder1 und 2 Abstraktionen von dem Builder sind. Außerdem wird zur Erzeugung von Objekten eine Abstraktionsschicht implementiert, daran lässt sich Abstraktion auch zeigen.
- Objektidentitäten: Da das Builder der Erzeugung von Objekten unterschiedlichen Typs dient, müssen Objektidentitäten vorhanden sein. (Reicht das so, oder kann man das irgendwie eindeutiger formulieren?)
- Berücksichtigung verschiedener Organisationsprinzipien: Dieses Prinzip ist vorhanden, was man an der Relation zwischen den ConcreteBuildern und dem Product sieht.
- Vererbung: ConcreteBuilder erben vom Builder (die Methode buildPart() ). Erkennt man an dem Pfeil der von den ConcreteBuildern zum Builder geht.

Kapselung, Geheimnisprinzip, Kommunikation unter Objekten und Polymorphismus sind hier nicht zu finden. Was bedeutet die Aggregation vom Director zum Builder? Findet man dort irgendwelche Prinzipien?

Im Factory findet man:
- Abstraktion: ConcreteCreator ist Abstraktion vom Creator.
- Objektidentitäten: erzeugt viele Objekte vom selben Typ und mit gleichen Eigenschaften, dies wäre in dem Fall Identität, da sie vom selben Typ sind. Oder ist es Gleichheit, wegen den gleichen Eigenschaften?
- Berücksichtigung verschiedener Organisationsprinzipien: Dieses Prinzip ist vorhanden, was man an der Relation zwischen den ConcreteCreator und dem Product sieht.
- Vererbung: ConcreteCreator erben vom Creator (die Methode factoryMethod() ).

Kapselung, Geheimnisprinzip, Kommunikation unter Objekten und Polymorphismus sind hier nicht zu finden.

Im Observer findet man:
- Abstraktion: ConcreteOserver sind Abstraktionen vom Observer. Außerdem findet sich hier Abstraktion auch in der abstrakten Klasse Observer wieder.
- Berücksichtigung verschiedener Organisationsprinzipien: Dieses Prinzip ist vorhanden, da das Subject eine Observerliste enthält. Diese Observerliste bildet eine Hierarchieebene.
- Vererbung: ConcreteObserver erben vom Observer(die Methode notify() )
- Kommunikation unter Objekten, denn das beobachtete Objekt informiert den Beobachter über Änderungen. Oft wird an den Beobachter noch eine Nachricht geschickt.
- Polymorphismus: Eine Möglichkeit für Polymorphismus ist das Überschreiben einer geerbten Klasse aus einer abstrakten Klasse. Da die Klasse Observer abstrakt ist, und die ConcreteObserver von dieser abstrakten Klasse die Methode notify() erben, ist es möglich, dass sich die Methoden in den zwei Klassen jeweils unterschiedlich verhalten, trotz des identischen Methodenrumpfs. Hab ich das richtig verstanden?

Objektidientitäten, Kapselung und das Geheimnisprinzip sind hier nicht zu finden.

 

[Mr.Smith]

das mit dem oberserver und observable.. da gibt es verschiedene möglichkeiten das zu implementieren .. daher gibt es überall im netz verschiedene bilder zu
zum rest .. kp mehr

und mir fällt auf, jeder nennt die dinge anders lol

 

[holy_fish]

Hi Slight,

Singleton:
Ja hier ist die zurückgegebene Instanz identisch.
Kapselung ist vorhanden, wenn der/die PrüferIn das wissen will. Wenn brav gekapselt dann gilt das Geheimnisprinzip als erfüllt.

Builder:
- Objektidentitäten
Ein Objekt ist immer ident, insofern weiß ich nicht was du meinst die Identität muss vorhanden, denn das ist sie von Haus aus ^^
Die Aggregation bedeutet das du einen Director brauchst, ohne diesen Director darf ein Builder nicht existieren. D.h. fällt der Director, fällt auch der Builder.
- Kapselung: Auch hier wird im ConcreteBuilder gekapselt. https://en.wikipedia.org/wiki/Builder_pattern
- Polymorphismus: Sollte hier vll auch erwähnt werden, da gleiche Builder sich unterschiedlich verhalten können.

Factory:
- Objektidentitäten
Die verschieden erzeugten Objekt sind gleich, ein Objekt kann immer nur identisch mit sich selbst sein.

Observer:
Polymorphismus hast du hier richtig verstanden.

Noch ein paar Cents: Ich würde antworten wie "Erkennt man an dem Pfeil der von den ConcreteBuildern zum Builder geht." vermeiden wenn gar kein UML Diagramm gegeben ist ^^

Edit: Das mit der Abstraktion hab ich ganz übersehen das es hier vertauscht wurde, Nullpointer hat hier recht. Bei einer Vererbung ist die erbende Klasse die Konkretisierung und die vererbende Klasse die Abstraktion.

Greetings

 

[NullPointer]

Das Prinzip Abstraktion würde ich persönlich anders herum interpretieren: eine konkrete Klasse ist keine Abstraktion ihrer Elternklasse, sondern eben eine Konkretisierung.

 

[Slight]

Hallo holy_fish,

dankeschön für die hilfreiche Antwort!
Das mit den Objektidentitäten meine ich so:
In der Vorlesung steht, Objektidentitäten dienen zur Unterscheidung von Objekten. Es gibt Gleichheit (wenn wesentliche Eigenschaften gleich sind, mittel equals-Methode) und Identität (wenn Object Identifier übereinstimmen, mittel ==-Operator)
Jetzt soll ich ja sagen, ob dieses Prinzip z.B. im Builder Pattern zu finden ist. Und ich wollte das so begründen, dass das Builder viele Objekte vom selben Typ erzeugt, mit gleichen Eigenschaften. Kann ich dann einfach sagen, die Objekte vom Builder sind gleich?

Und habe ich es jetzt richtig von dir verstanden, dass es beim Factory Pattern die Gleichheit ist?

Wo wird denn beim Builder gekapselt? In dem UML-Diagramm aus der Vorlesung finde ich keine privaten Attribute.

Es sind ja UML-Diagramme gegeben, diese sollen wir dann wahrscheinlich auch in der Klausur zeichnen. Soll ich die vielleicht mal hier posten, oder ist es so schon verständlich genug?

Liebe Grüße !

 

[holy_fish]

Das Prinzip von Objektidentität und Objektgleichheit ist ja nicht nur eine Meinung sondern allgemein gültig
Ja genau das meinte ich, werden mehrere Objekte des selben Typs erzeugt sind die Objekt zueinander gleich, aber nicht ident, da ein Objekt immer nur ident zu sich selbst sein kann.

Naja du hast geschrieben

erzeugt viele Objekte vom selben Typ und mit gleichen Eigenschaften, dies wäre in dem Fall Identität

was ja nicht stimmt, denn auch wenn 2 Objekte den selben Typen und die gleichen Eigenschaften haben, können sie niemals ident sein.

Im Wikipedia-Beispiel, welches ich verlinkt habe, wird im Code-Beispiel der ConcreteBuilder gekapselt. Aber stimmt, rein aus dem UML ist keine vorhanden, da kein Attribut, mein Fehler.

Greetings

 

[Slight]

Okay dann habe ich das jetzt verstanden, danke Mein Prof hat dazu noch geschrieben:
Objektidentitäten: Im Observer Pattern sind die einzelnen Observer wohl unterscheidbar, d.h. hier müssen Objektidentitäten vorliegen.
Das habe ich jetzt nicht erkannt. Ich verstehe die Aussage nicht so ganz, also wieso sind die Observer/Beobachter unterscheidbar? Weil es einen ConcreteObserver1 und ConcreteObserver2 gibt (die vom Observer erben)? Dann könnte ich das ja auch einfach auf den Builder anwenden, dort gibt es auch einen ConcreteBuilder 1 und 2, oder?

Und im Oberserver Pattern ist ja auch noch Kapselung zu finden, durch das private Attribut Observer vom Typ List. Das Geheiminisprinzip ist dadurch aber noch nicht erfüllt oder?

Liebe Grüße

 

[holy_fish]

Ja genau, denn du hast >1 konkrete Klassen welche unterscheidbar sind.

 

[Foochan]

Im Singleton findet man
- Objektidentitäten, Singleton soll ja gewährleisten, dass eine bestimmte Komponente nur einmal innerhalb eines Systems vorkommt, dafür sorgt die getInstance-Methode, da ich von dieser immer das selbe Objekt zurück bekomme.

Folgendes ist für deine Klausur evtl. nicht relevant aber in Java gibt es seit 1.5 eine viel elegantere Variante einen Singleton zu implementieren.

enum Singleton {
    INSTANCE;

    public void doSomething(){ /* ...*/}
}

Mehr ist nicht nötig. Zudem ist das ganze Threadsicher. Mehr zu dem Thema kannst du im Buch Effective Java von Joshua Bloch (sollte in jeder Uni-/Hochschul-Bib zu finden sein) oder unter https://github.com/dlindner/vorlesung-se2-dhbw/tree/master/added_2014 nachlesen.

 

[Slight]

Danke für die Antwort!
Bei mir im Hefter steht das ohne public void doSomething() { }
Kann ich das dann auch ohne diese Methode machen?

 

[Foochan]

Ja. Die Methode doSomething soll einfach symbolisieren, dass es möglich ist in Enums Methoden zu deklarieren

 

[holy_fish]

Es ist einfach eine von mehreren Möglichkeiten ein Singleton zu realisieren.
Mir persönlich z.B. sagt die eager initialization einfach mehr zu ^^