Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
Diese Umfrage wurde während der Migration geschlossen.
0 voters
Klausurumfrage
Wie liefs bei euch so ?
Und um welches Entwurfsmuster hat es sich denn gehandelt?
observer.
und es lief kacke
wasn das fuer ne umfrage? 
Eine Umfrage ohne Ankreuzmöglichkeiten? 8-( 
TOTALSCHADEN Klausurumfrage.
NIE WIEDER SOSY \o/
Man muss den Leuten vom LS11 ja lassen, dass
es endlich mal eine anständige Klausur war. Keine dumme
Stichpunktaufzählfrage.
Habe mich als Beobachter beim Subjekt Vorlesung angemeldet, wurde jedoch nie vom Subjekt benachrichtigt, dass man das Observer Pattern lernen müsse.
Keine Informationen zu aktualisieren , keine melde an, melde ab , und benachrichtige methoden in der Messstationklasse … die zwei Stationen fördern die messwerte erst bei bedarf. Also kein observer sondern proxy
[quote=Eden]
Keine Informationen zu aktualisieren , keine melde an, melde ab , und benachrichtige methoden in der Messstationklasse[/quote]
Deswegen lässt du die Messstation ja diese Sachen von einer anderen Klasse erben.
Wann führt man geerbte Methoden in der erbenden Klasse erneut auf? Immer? Oder nur wenn die geerbten Methoden in der Oberklasse abstract sind? Oder nie?
Die Frage kommt jetzt etwas spät, aber man lernt ja für’s Leben 
Eigentlich wie im Code.
Wenn du eine Methode in der Oberklasse aufgeführt hast, dann wird sie in der Unterklasse aufgeführt, wenn:
[quote=ceptoplex]
Proxy macht trotzdem viel mehr sinn meiner meinung nach ( es gibt ja keine daten bzw. Informationen gleichzeitig zu aktualisieren , somit macht observer kein sinn mehr)
Beim Observer geht’s ja darum, dass die Beobachter nicht pollen müssen, ob beim Subjekt eine Änderung vorliegt. Das macht schon Sinn bei einem Sensor. Eine ähnliche Aufgabe hatten wir doch in den Übungen.
aber Erdbebeninformationen und Tsunamisinformationen sind nicht die gleichen , beim beobachter gehts um die gleichen Informationen aber bloß Anders dargestellt ( wie z.b. Digitalanzeige und Säule beide Liefern die Gleiche Information , und wenn sich diese Information sich bei der Säule ändert dann muss sie sich auch Bei der Digianzeige ändern) aber Erdbeben und Tsunami sind zwei unterschiedliche Sachen und haben Jeweils vollkommen unterschiedliche Informationen. das ist der punkt 
war es nicht so, dass es schon die gleichen Infos waren und nur der Wertebereich entscheidend war? (leider ist meine Erinnerung schon wieder verblasst )
man kann aber die gesamten Informationen auch als ein einziges „Objekt“ ansehen und schon passt der Observer wieder, weil es dann nur eine andere Verarbeitung mit Folgeaktionen ist
Ein normaler Erdbeben ist kein Tsunami , aber bei der Säule und der Digianzeige geht es um die gleiche Temperatur in Grad°
und es gibt auch ein Schlüßelwort in der Aufgabe : die beiden Stationen erfordern die Messwerte von der Messstation erst bei BEDARF … und das ist ein typische Eigenschaft von Proxy
Beim Observer-Pattern geht es grundsätzlich erstmal nicht darum, dass die Informationen, die das Subjekt besitzt und an alle Beobachter verteilt, gleich sein müssen. Der Hauptaspekt ist meiner Meinung nach:
Einer verteilt statt alle fragen einen.
Ob dieser jetzt allen gleichzeitig die gleichen Informationen liefert oder ob er diese einfach benachricht, worauf diese sich um die Übertragung der von ihnen gebrauchten Informationen selbst kümmern - spielt dabei keine Rolle. Es geht lediglich darum, aktives Warten der Beobachter zu vermeiden, indem das Subjekt Bescheid gibt, wenn sich etwas geändert hat.
Ich hab dabei jetzt noch nicht über eine Argumentation nachgedacht, irgendwie das Proxy-Pattern da mit einzubauen, aber zu behaupten dass Observer nicht korrekt wäre finde ich falsch.
Ohne Observer geht es meiner Meinung nach garnicht. Wie soll denn sonst die Messstelle wissen, welche Forschungseinrichtungen alles die Daten brauchen, ohne, dass die Forschungseinrichtungen alle dauernd selbst pollen (was Observer eben vermeidet)?
Bei mir ist’s ein Observer-Pattern für den Sensor und eine Bridge für die Filterung geworden - die Aufgabe war mies…
Proxy statt Bridge hat mit nicht gefallen, weil da die selbe Basisklasse verwendet wird - der Filter braucht aber Infos zu den Werten, die FStationen aber holen sich die Werte selbst, also werden die wohl nicht in der ( kostenintensiven! 
) Benachrichtigung vom Zwischenzeugs an die Station drinstehen.
IMHO geht es beim Observer Pattern primär darum, dass sich mehrere Beobachter bei einem Subjekt anmelden können und bei Änderungen von diesem benachrichtigt werden. Das Subjekt hat dabei eher wenig Kenntnis darüber, was die einzelnen Beobachter von ihm wollen, denn darum kümmern sich die Beobachter selbst, indem sie von ihrem konkreten Subjekt die Daten abfragen, die genau sie brauchen.
Proxy finde ich sehr weit hergeholt. Klar holen sich die beiden Forschungsstationen genau die Werte, die sie haben wollen, aber der grundsätzliche Kontrollfluss ist ein ganz anderer. Beim Beobachter ändert sich ein Subjekt (Sensor) und meldet dies an alle Interessenten (Forschungsstationen). Beim Proxy müssten die Forschungsstationen regelmäßig die Daten abfragen (stündlich? täglich? …?)
Das Problem ist, woher der Bedarf kommt: Nämlich von der Messstation (eben wenn neue Messwerte da sind). Bei dem Beispiel aus der Vorlesung mit einem „BildObjekt“ ist das anders: Das Dokument enthält ein Bild, der User scrollt und nun will das Dokument das Bild darstellen. Daraufhin lädt der Proxy das Bild nachträglich in den Speicher.