informatik beleg?

[luftraudi]

hallo,
ich studiere maschinenbau im 2. semester und wir müssen in informatik einen
beleg anfertigen der es in sich hat. die aufgabeist hier!

ich hab speziel die teilaufgabe 2 (lagerverwaltung). ich weiß echt nicht wie man da ran gehen
soll. wieviel klassen muss man erstellen und wie muss das ganze in äbhängigkeit gebracht
werden?



wäre cool wenn mir jemand auf die sprünge helfen könnte, einen schönen abend noch!

 

[Marco13]

Habs jetzt nur überflogen - ist ja schon ziemlich viel. Erstmal vorneweg: Du solltest UNBEDINGT zusehen, dass du das irgendwie in einer Gruppe machst, und wenn ihr es nicht direkt in einer Gruppe machen dürft, dann zumindest mit Kommilitonen darüber reden, wie die da ran gegangen sind, und bei konkreten Fragen auch mal an die Tutoren wenden. Ein 10-Minütiges Gespräch mit kurzen Fragen und ebenso kurzen klaren Antworten (von Leuten, die das gleiche Problem haben, oder genau wissen, worum es dabei geht) ist viel effizienter, als so ein Thread hier...

Um die Frage (ZU knapp?) zu beantworten: Du benötigst erstmal die Klassen, die im ersten Diagramm von Teilaufgabe 2 angegeben sind:
abstract class Lager
class FestLager extends Lager
class ChaosLager extends Lager
class LagerFactory
Das "Observer"-Pattern, das im zweiten Diagramm aufgemalt ist, verwendet man, wenn eine Klasse mehrere andere Klassen beobachten können soll. Codebeispiele für diese Design patterns findet man übrigens recht schnell mit Websuchen wie "Design Pattern Observer" oder "Design Pattern Factory".

Wie genau die Verwaltung "innerhalb" dieser Lager aussehen soll, ist mir (nach dem ersten Überfliegen(!)) nicht klar, aber das findet man schon raus. Vermutlich soll aber zumindest schonmal das "Lager" dem "Subjekt" aus dem Observer-Pattern entsprechen. Nur WER dann die Observer sind, muß man sich noch überlegen...

 

[luftraudi]

hallo, danke für die schnelle anwort. ich hab mir mal ein paar gedanken gemacht was die folgenden klassen für aufgaben übernehmen sollen:

Lager(abstact):

Atribute Operationen
ID Einlagern(Lagerelement Teil, int anzahl)
Lägerplätze Auslagern(Lagerelement Teil, int anzahl)
Kapazität

jetzt kommt die frage auf was man denn für eine datenstruktur verwenden kann
um das lager zu realisieren? es soll ja eine art matrix aus lagerplatz mal
kapazität ergeben?


Festlager/Chaoslager extends Lager

hier dann die vordefinierten operationen von lager genau festlegen
wie das lager (datentyp?) zu belagern ist.

weiterhin kontruktormethode

Lagerelement

wie auf der letzten seite beschrieben. dieses wird dann beim hinzufügen und
entnehmen aus den lagern jeweils an die entsprechenden operationen übergeben

allerdings können doch jetzt die methoden hinzufügen elemente/entnehmen elemente weggelassen werden, da das doch jetzt direkt über das lager gemacht wird oder?


LAgerverwaltung
verbindet das lagerelement mit dem lager letztendlich und überwacht alle vorgänge
darüber zerbrech ich mir später den kopf, wenn das andere so halbwegs klar ist.


ist das so in etwa schonmal richtig oder sollte es aufgrund von methodischen gegebenheiten anders gemacht werden? bin für jede hilfe dankbar. wir sind
zwar schon zu 5. aber meine kommilitonen haben noch weniger ahnung als
ich und der beleg scheint schon nich ganz ohne zu sein.

 

[Guest]

hallo,
um nochmal auf die aufgabe zurückzukommen.
ich hab erstmal grob ein klassendiagramm erarbeitet und das sieht so aus:

ich hab mir überlegt die lagerelemente und lager die ich erzeuge in den
jeweiligen containerklassen zu verwalten. im lagerelement stehen die
eigenschaften der elemente(mindestanzahl,maximalzahl,....).

wenn ich nun was ein lagern will soll die die entsprechende (eindeutige) id
vom entsprechenden lagerelement und die id vom lager sowie die anzahl
an die entsprechende methode gegeben werden die dann wiederrum die
entsprechende methode im entsprechenden lager(aufgrund der id) mit dem
einlagern aufruft und durch die id vom lagerelementcontainer das
entsprechende lagerelementobjekt bekommt.

müsste ja eigentlich so funktionieren oder?


wenn ich ein lager erzeugen will (erstmal nur ein Festlager)
dann rufe ich die methode auf und übergebe ihr die anzahl
der lagerplätze und die kapazität.
drauf hin werden dann soviel objekte wie lagerplätze vorhanden
sein sollen erzeugt, die Lagerplätze haben die attribute:

int zuordnunug --> damit dort wird die id des lagerelementes eingetragen

int reihe[kapazität] --> es werden also soviel reihen erzeugt wie man an kapazität
zur verfügung hat
ist eine bestimmte reihe belegt wird sie mit 1 gefüllt
ist die reihe leer mit 0

bei diesem beispiel gehen wir einfach mal davon aus das jedes element nur
eine reihe eines lagerplatzes belegt. die verfeinerung kommt später.

aufgrund der zuordnung mit der id kann man jederzeit die weiter daten aus dem element auslesen und kommt jederzeit ran.
wird zum beispiel ein objekt eingelagert wird so verfahren wie grad beschrieben
und wenn das der fall ist, dann wird über den container die entsprechende die
aktuelle zahl der elemente geändert mit einer entsprechenden methode in der klasse lagerelement.

kann man das so machen? mir scheint die lösung erstmal recht gut

allerdings hab ich noch ein problem ich weiß nicht wie ich die das
observer-entwurfsmuster einbauen soll:
in der beschreibung vom beleg ist ja das folgende uml diagramm
verzeichnet

ich nehme an das subjekt soll das lager sein, allerdings steht da das das
subjekt ne unterklasse der klasse beobachtende ist und das wäre ja
dann die klasse lager. aber isses nich besser die beobachter über
die lagerverwaltung zu hinzuzufügen?

danke für eure hilfe

 

[luftraudi]

Hi,
Also das Ganze nochmal gut lesbarem Deutsch:

Zuerst einmal zu den Containerklassen. Die hab ich eingeführt weil ich da die Lager- sowie die Elemente nicht in der Klasse Lagerverwaltung unterbringen muss und somit mehr Ordnung und übersicht hab, da aber beide in in etwa die gleiche Aufgabe haben und auch ähnlich arbeiten könnte ich sie eigentlich auch von einer abstrakten Klasse erben lassen.

Das Lagerelement beschreibt jeweils immer einen Typ den man in ein Lager einlagern kann. Dabei hat er folgende Eigenschaften(Atrribute):

Name
ID
Meldebestand
Mindestbestand
Maximalbestand
Aktueller Bestand

und folgende Mehtoden:

Konstruktor
GetMeldebestand
GetMinestbestand
GetMaximalbestand
GetAktueller Bestand
Hinzufügen Elemente(Anzahl)
Entnehmen Elemente(Anzahl)
Prüfen Entnahme
Prüfen Hinzufügen

Diese Methoden und Attribute sind von der aufgabenstellung vorgegeben!

Das ganze ist so gemeint (ich hab einen Tutor gefragt) das wenn man etwas Einlagert das dann die Methode Hinzufügen Elemente(Anzhal) aufgerufen wird und dann dort das Attribut Aktuell Bestand erhöht wird um die entsprechende Anzahl.
Das war ja auch meine Frage anfangs ob es Sinn macht das Einlagern über die Lagerelemente zu regeln aber wie gesagt die Methode Hinzufügen Elemente/Entnehmen Elemente ist nur dazu da um den Zustand des Elementes zu ändern (Aktueller Bestand).
Das wirkliche Einlagern (in ein Lager) soll schon über die Lagerverwaltung durchgeführt werden.

Dazu wollte ich wie folgt vorgehen:

In Klasse Lagerverwaltung gibt es eine Methode Einlagern(LagerID,LagerelementID,Anzahl), unter der Annahme es existieren bereits mit einer ID eindeutig unterscheidbare Lager und mit einer eindeutigen ID unterscheidbare Lagerelemente).

die Methode macht dann folgendes:

sie ruft dann vom Objekt der LagerelementContainerklasse die Mehtode
getLagerelement(ID) auf die zu der entsprechenden ID das enstprechende
Lagerelementobjekt zurückgibt.
Darüber wird dann ersteinmal geprüft(Methode im Lagerelement) ob ein Einlagern unter den Umstanden (Anzahl einzulagernder Elemente, Maximalzahl, Aktuellzahl) möglich ist.

Sofern ein Einlagern möglich ist, wird das entsprechende Lagerelement an die Methode Einlagern(Lagerelement, Anzahl) des Lagers gegeben.
Dafür kommt die Klasse LagerContainer zum Einsatz.
Hier kann man genau wie im LagerelementContainer auf über eine Methode getLager(ID) das entsprechende Lagerobjekt zurückgeben lassen und damit arbeiten um das Einlagern(Lagerelement, Anzahl) zu veranlassen.

Dabei prüft das Lager erstmal ob es genug Platz hat um die entsprechende Anzahl an Lagerelementen aufzunehemen. Ist dies der Fall dann werden diese eingelagert.
wie genau ich mir das mit dem Einlagern vorstelle schreibe ich ganz zum Schluss.

Wurden die Elemente im Lager erfolgreich eingelagert dann wird wieder über den LagerelementContainer die Methode HinzufügenElemente(Anzahl) der Aktuell Bestand des enstsprechenden Lagereelementes erhöht, so das das Lagerelement "nun auch weiß das es einlagert wurde".

So stell ich mir das ganze unter der gegebenen Aufgabenstellung vor!
Meiner Meinung nach ist das ganze recht logisch und ich finde ich sollte die ContainerKlassen drin lassen weil man damit sehr leicht auf die Objekt in den Containern zurückgreifen kann.


So jetzt noch meine Grundüberlegung wie ich die ganze Sache mit dem Einlagern im Lager bewerkstelligen will.
Erstens gehen wir jetzt einmal davon aus das Es sich um ein Festlager handelt, mit einer vorgegebenen Kapazität(die auf jedem Lagerplatz gleich ist) und mit einer festgelegten Anzahl an Lagerplätzen.

Die Klasse Lagerplatz hat folgende Attribute: (im Fall Festlager)

Zuordnung = Lagerelement
int[] Reihe = new Integer[Kapazität]

Somit entspricht die Reihe der Kapazität!

Im Lagerobjekt wird ein LagerplatzArray der Länge (Anzahl der Lagerplätze) erstellt.

Wir nehmen an wir haben 5 Lagerplätze mit der Kapazität 4.
Auf dem ersten Lagerplatz befinden sich nur Lagerelemente mit der ID 82! (Festlager)
Außerdem sind nicht alle Reihen belegt sondern nur Reihe 1 und Reihe 3!

Damit sieht die Zuordnung nun so aus:

LagerplatzArray[1].Zuordnung= 82;

LagerplatzArray[1].Reihe[1]=1;
LagerplatzArray[1].Reihe[2]=0;
LagerplatzArray[1].Reihe[3]=1;
LagerplatzArray[1].Reihe[4]=0

Wobei 1 für Belegt steht und 0 für nicht belegt. Aufgrund der Zuordnung kann man jederzeit über die ID über getLagerelent(ID) -->ContainerKlasse<-- zugreifen und da noch weitere Daten auslesen.

Das Beispiel ist jetzt sehr verallgemeinert aber ich denke man erkennt wie ich die
ganze sache strukturieren will. natürlich muss man das ganze noch weiter ausbauen weil ja bestimmte Elemente auf mehrere Plätze belegen können aber das sollte hier erstmal nicht das Hauptproblem sein.

Beim Chaoslager würde ich dann den Array wahrscheinlich 2 Spaltig machen so das man eine Art Matrix hat wo zu jeder Belegung die Entsprechende Zuordnung hat.

Die feinheiten wie genau und unter welchen Kriterien die ganze Einlagerung ablaufen soll muss ich nochmal mit dem Tutor besprechen.

 

[Tobias]

Nur schnell zu deinem UML-Diagramm:

1. Es gibt keine Lager, die keine Lagerplätze beinhalten. Deshalb sollte diese Aggregation von Lager verwaltet werden und nicht von den Subklassen.

2. Wenn LagerContainer direkt von den Subklassen abhängig ist, wirst du den LagerContainer ändern müssen, wenn du einen weiteren Lagertyp hinzufügst. Hier wäre es geschickter, wenn LagerContainer eine Collection von Lager(n) enthielte - da rein könnte man auch beliebige neue Subklassen schieben und nicht nur die beiden aktuell existierenden.

Zum Observer-Pattern findest du eine Beispielimplementierung für ein ganz ähnliches Problem wie deines in der FAQ. Such mal nach 'Listener' in der FAQ. Das Hinzufügen der Observer über die Lagerverwaltung erscheint mir schlüssig (je nachdem, wie du dir die Implementierung denn letztlich vorgestellt hat). Hierzu ist zu sagen, dass die Pattern nur als Best Practises anzusehen sind, die im Bedarfsfall natürlich angepasst werden können. Du mußt also nichtsklavisch dem gegebenen UML-Diagramm folgen, auch wenn das in den meisten Situationen der beste Weg wäre.

mpG
Tobias

Nachtrag: Bevor du bei den Belegungen mit 0 und 1 rumhantierst, solltest du lieber boolean verwenden - das ist zusammen mit einem "vernünftigen" Variablennamen (z. B. "belegt") besser lesbar und vermeidet Fehlerquellen wie "Was passiert, wenn ich in diese Variable 1089367 reinschreibe?".

 

[Marco13]

Oh ja da war ja noch was (manchmal gehen solche Threads unter...).

Nochmal: Die Posts und die Aufgabenstellung sind sher viel Text und Information, und kaum jemand wird (grundlos) die Arbeit aufwenden, die notwendig ist, um das alles nachzuvollziehen, und deine Fragen zu beantworten, wenn sie aus einer langen Beschreibung dessen, was du dir überlegt hast, und der Frage "Ist das OK so?" bestehen - für letzteres wäre eher der Tutor der Ansprechpartner.

Als Ergänzung zu Tobias' Aussage bzgl. der Belegung: FALLS ich dich richtig verstanden habe, ist diese Belegung, die du mit "0" und "1" beschreibst, nur vorläufig. FALLS dort auch mal andere Werte stehen müssen, ist es vermutlich(!) so OK, wie es es ist. FALLS es aber immer nur 0 oder 1 ist, sollten es stattdessen booleans sein.

Das mit den Containerklassen konnte ich auf die schnelle nicht ganz nachvollziehen. Vllt. könntest du (falls da noch Unsicherheiten sind) nochmal kurz und prägnant sagen, WAS die genau für einen Zweck erfüllen, und WARUM du sie eingeführt hast.

Und noch zu der Frage
ich nehme an das subjekt soll das lager sein, allerdings steht da das das
subjekt ne unterklasse der klasse beobachtende ist und das wäre ja
dann die klasse lager. aber isses nich besser die beobachter über
die lagerverwaltung zu hinzuzufügen?

Das eigentliche Hinzufügen kann ja von der Lagerverwaltdung übernommen werden. Die Lagerverwaltung nimmt einen Beobachter, und fügt ihn dem Lager hinzu. Dazu muß aber doch das Lager eine Methode anbieten, um neue Beobackter bekommen zu können...!?

Hm. Dem Diagramm nach ist der Name "Beobachtende" eigentlich unpassend. Der Beobachter ist beobachtend, aber das WAS beobachtet WIRD wäre etwas "Beobachtetes". Aber das ist wohl jetzt nicht so wichtig :roll:

 

[SnooP]

Zum Thema Observer-Pattern... - in java findet sich bereits eine Implementierung des Patterns in Form der Klasse Observable (dein Beobachtender) sowie dem Interface Observer... wenn sich an dem Datum was ändert (erbt von Observable - daher die Observable-Klasse in der Hierarchie ganz nach oben) wird notifyObservers aufgerufen, die nacheinander die update-Methode der registrierten Observer aufruft, die daraufhin halt entsprechend reagieren können...

sinnig ist das wenn man an mehreren Stellen eines Systems Veränderungen an dem Datum/Modell mitbekommen möchte.

Eigentlich ist das Konzept inzwischen von dem EventListener Prinzip in Java abgelöst... - das ist aber prinzipiell mehr GUI gebunden.

 

[Guest]

Nur schnell zu deinem UML-Diagramm:

1. Es gibt keine Lager, die keine Lagerplätze beinhalten. Deshalb sollte diese Aggregation von Lager verwaltet werden und nicht von den Subklassen.

2. Wenn LagerContainer direkt von den Subklassen abhängig ist, wirst du den LagerContainer ändern müssen, wenn du einen weiteren Lagertyp hinzufügst. Hier wäre es geschickter, wenn LagerContainer eine Collection von Lager(n) enthielte - da rein könnte man auch beliebige neue Subklassen schieben und nicht nur die beiden aktuell existierenden.

Zum Observer-Pattern findest du eine Beispielimplementierung für ein ganz ähnliches Problem wie deines in der FAQ. Such mal nach 'Listener' in der FAQ. Das Hinzufügen der Observer über die Lagerverwaltung erscheint mir schlüssig (je nachdem, wie du dir die Implementierung denn letztlich vorgestellt hat). Hierzu ist zu sagen, dass die Pattern nur als Best Practises anzusehen sind, die im Bedarfsfall natürlich angepasst werden können. Du mußt also nichtsklavisch dem gegebenen UML-Diagramm folgen, auch wenn das in den meisten Situationen der beste Weg wäre.

mpG
Tobias

Nachtrag: Bevor du bei den Belegungen mit 0 und 1 rumhantierst, solltest du lieber boolean verwenden - das ist zusammen mit einem "vernünftigen" Variablennamen (z. B. "belegt") besser lesbar und vermeidet Fehlerquellen wie "Was passiert, wenn ich in diese Variable 1089367 reinschreibe?".

zu 1. und 2.) ist schon geändert, Danke für den Hinweis

Das Oberserver-Pattern hab ich jetzt erstmal so umgesetzt wie auf dem Bild zu sehen.

Und das mit den Belegung war wie Marco schon vermutet hat nur vorläufig wie genau das ganze
dann belegt wird hängt von den genauen Möglichkeiten wie das Lager belagert werden kann und
das will ich nochmal mit meinem Tutor klären und is dann auch mein Bier und eigentlich nicht so
relevant weil das ja alles Details sind um die es mir hier nicht geht.

Nochmal: Die Posts und die Aufgabenstellung sind sher viel Text und Information, und kaum jemand wird (grundlos) die Arbeit aufwenden, die notwendig ist, um das alles nachzuvollziehen, und deine Fragen zu beantworten, wenn sie aus einer langen Beschreibung dessen, was du dir überlegt hast, und der Frage "Ist das OK so?" bestehen - für letzteres wäre eher der Tutor der Ansprechpartner.

........

Das mit den Containerklassen konnte ich auf die schnelle nicht ganz nachvollziehen. Vllt. könntest du (falls da noch Unsicherheiten sind) nochmal kurz und prägnant sagen, WAS die genau für einen Zweck erfüllen, und WARUM du sie eingeführt hast.

Es hat dich keiner gezwungen hier zu antworten und ich weiß das das es nicht selbverständlich das ihr mir versucht zu helfen. Aber ihr könnt mir glauben ich bzw. meine Gruppe sind über jeden konstruktiven Post eurer Seite der uns weiterbringt sehr dankbar. Natürlich frage ich, speziell wenn es um Details geht den Tutor. Aber wenn mann noch nie mit Programmierung zu tun hatte und jetzt sowas vorgeworfen bekommt isses schon mal gut wenn man die Meinung von "Experten" hört oder zumindest von Leuten die schon Erfahrung mit der OOP in Java haben um zumindest zu wissen das man sich nicht total in der falschen Richtung bewegt. Aber gut nun.
Wie gesagt herzlichen Dank an alle die hier tatkräftig mitposten, im Namen von mir und meinen Kommilitonen!


Zu den Containerklassen:
Der Zweck ist lediglich das ich die Objekte der erzeugten Lagerelemente und Lager ordnen und gezielt nach Informationen (zum Beispiel über die eindeutige ID) auf die Objekte zugreifen zu können ohne das in der
Lagerverwaltung zu bewerkstelligen.
Ich erhoffe mir damit, das ich eine klarere Struktur in das Programm bekomme!



Aber jetzt nochmal zu dem Observer-Pattern:


Hi,
also das Klassendiagramm sieht jetzt so aus:

Hauptbestandteil der Überwachung ist natürlich das Lager. Sobald eine Meldung
eingeht das ich etwas geändert hat im Lager werden die KonkretenBeobachter
benachrichtigt und inspizieren das Lager. Über die Lagerbelegung kommen die
Beobachter dann auch automatisch zu den Lagerelementen. Ich weiß selber auch nicht was alles Gegenstand der Überwachung sein soll, aber das spielt ja im Moment auch keine Rolle.


Jetzt stellt sich die Frage ob man die abstrakte Klasse nicht einfach weglassen kann, weil im Prinzip gibts ja nur eine Unterklasse(bis jetzt :lol: ).
Was meint ihr dazu? Solang ich keine Unterschiedlichen konkretenBeobachter für
die 2 Lagerarten benötige, brauch ich ja nicht unbedingt die aktrakte Klasse Observer....meine ich zumindest :?

So Richtig verstehe ich es aber noch nicht wie man es bewerkstelligen soll das über eine Änderung am Lager alle Konkreten Beobachter gleichzeitig benachrichtigt werden sollen. kann man das über eine Klassenmethode umsetzen? wie würdet ihr das machen?

Übrigens die zwei Assoziationen zwischen den Containerklassen hab ich mit absicht gelassen und nicht allgemein auf dei Superklasse Container vereinfacht weil man meiner Meinung nach dann nicht ganz klar ist was für Container explizit in der Lagerverwaltung verwaltet werden sollen.

 

[SnooP]

Jetzt stellt sich die Frage ob man die abstrakte Klasse nicht einfach weglassen kann, weil im Prinzip gibts ja nur eine Unterklasse(bis jetzt :lol: ).
Was meint ihr dazu? Solang ich keine Unterschiedlichen konkretenBeobachter für
die 2 Lagerarten benötige, brauch ich ja nicht unbedingt die aktrakte Klasse Observer....meine ich zumindest :?

Ich glaub so ganz hast du das noch nicht verstanden ... - warum willst du denn eigentlich das deine Lager gleichzeitig die Untersuchungsgegenstände sind (Observable) aber auch die Beobachter des Gegenstands selbst? Das wäre genauso, wie wenn ich mich ständig selbst mit einer Webcam filmen würde, nur um feststellen zu können, dass ich mir grad in der Nase popel! ... in der Regel sollte ich das selbst schon wissen, dazu brauch ich keine Webcam (mal Unterbewustseinsgeschichten außen vor gelassen).

Also ein vernünftiger Observer wäre imho entweder eine Anwendungsklasse die alles mitprotokolliert (sysouts) - oder bei dir evtl. die Lagerverwaltung bzw. auch Loggerklassen oder aber ein GUI-Element. Wenn sich in einem der Lager etwas ändert wird per notifyObserver der oder die Observer aufgerufen und die können dann entsprechend ausgeben, was sich geändert hat, da die update-Methode von Observer ja als Parameter sowohl das Observable (das Lager) selbst, als auch ein beliebiges Objekt mitbekommen (z.B. auch ein String oder halt der veränderte Wert auf der geachtet werden soll).

Konkreter: Lasse deine Lagerklasse nochmals erben von einer abstrakten Oberklasse Observable, die du entweder selbst implementierst oder aber du verwendest Observable aus java.util. Dadurch sind alle deine Lager konkrete Subjects oder Beobachtungsgegenstände... eine weitere beliebige Klasse sollte dann das Interface Observer implementieren (mindestens eine weitere - zu Testzwecken würde ich schon zwei nehmen... evtl. eine halt die beim Aufruf der Methode update die Veränderung in eine Datei schreibt: Logging). Bei dir bietet sich imho die Lagerverwaltung an... ich hab jetzt nicht genau den Anwendungshintergrund im Kopf was am Ende dann tatsächlich passieren soll... evtl. müssen ja bestimmte Objekte von den Veränderungen am Lager eh benachrichtigt werden?

So Richtig verstehe ich es aber noch nicht wie man es bewerkstelligen soll das über eine Änderung am Lager alle Konkreten Beobachter gleichzeitig benachrichtigt werden sollen. kann man das über eine Klassenmethode umsetzen? wie würdet ihr das machen?

Gleichzeitig sowieso nicht ... parallel kann man in Java nicht wirklich programmieren - aber hintereinander reicht hier auch. Die Methode notifyObserver iteriert (Iterator, foreach-Schleife in Java 5) über alle registrierten Observer (Lagerverwaltung, Logger,...) die per addObserver dem Observable mitgeteilt wurden. Beim iterieren wird in jedem Durchlauf die Methode update des aktuellen Observers aufgerufen... fertig ist die Laube ... beim Aufruf von Update kann dann wie gesagt das Observable selbst + ein weiteres Objekt übergeben werden... je wie man lustig ist und wie man will...

hth

 

[Marco13]

Es hat dich keiner gezwungen hier zu antworten

:?
Wie auch immer.
LagerContainer und LagerelementContainer erben ja beide von "Co(n)tainer" - die Container scheinen eine Art verwaltende Aufgabe zu übernehmen - sie werden aber selbst von der Lagerverwaltung verwaltet ...?! Wie sieht denn die "Container" Klasse aus?

Und zu dem Observer/Observable hat SnooP schon den wichtigsten Punkt genannt: Der Observer/Observable-Teil sollte (so weit wie möglich) "unabhängig" von der Lagerverwaltung sein - damit wird der Teil nämlich leichter wiederverwendbar.

 

[Guest]

Konkreter: Lasse deine Lagerklasse nochmals erben von einer abstrakten Oberklasse Observable, die du entweder selbst implementierst oder aber du verwendest Observable aus java.util. Dadurch sind alle deine Lager konkrete Subjects oder Beobachtungsgegenstände... eine weitere beliebige Klasse sollte dann das Interface Observer implementieren (mindestens eine weitere - zu Testzwecken würde ich schon zwei nehmen... evtl. eine halt die beim Aufruf der Methode update die Veränderung in eine Datei schreibt: Logging). Bei dir bietet sich imho die Lagerverwaltung an... ich hab jetzt nicht genau den Anwendungshintergrund im Kopf was am Ende dann tatsächlich passieren soll... evtl. müssen ja bestimmte Objekte von den Veränderungen am Lager eh benachrichtigt werden?
hth

Hi,
Also sieht das ganze so aus:

Lagerklasse erbt von Oberklasse Observable (java.util).
Darüber werden die die Observer angemeldet. Wenn sich jetzt was ändert in dem Lager dann wird die Mehtode update aufgerufen in allen erzeugten konkretenObservern, die das entsprechende Lagerobjekt überwachen.

müssen noch irgendwelche Aggregationen hin? Warum muss Observer ein Interface sein und keine abstakte Klasse?

 

[Tobias]

Der Observer-Teil sieht jetzt gut aus - bis auf die Tatsache, dass Lager derzeit keine Observer haben kann, weil hier eine entsprechende Aggregation fehlt.

Darüberhinaus verstehe ich den Part mit den Container noch nicht so richtig: Was macht der Container, was die Lagerverwaltung nicht direkt machen könnte? Zugriff auf die einzelnen Lager sollte doch auch die Lagerverwaltung anbieten, oder? Für mich sieht das nach einem unnötigen Delegate aus.

mpG
Tobias

Nachtrag: Ein Observer könnte auch eine abstrakte Klasse sein. Da Implementierungsmehrfachvererbung in Java aber nicht existiert, wäre man damit wesentlich eingeschränkter als mit einem Interface.