Diskussion:Zustand (Entwurfsmuster)

Guter Artikel --AFI 10:44, 4. Jun 2005 (CEST)

Zu Implementation: Ich bin mir nicht so sicher, ob die Verwendung eines Singletons zur Erzeugung der States ein so gute Idee ist. Schließlich handelt es sich bei einem Zustand per Definition zunächst einmal um etwas temporäres, ein Singleton ist aber so ziemlich das Gegenteil davon. Allerdings verleitet das Zustands-Muster auch leicht dazu ein Singleton zu verwenden (gerade wenn man mal wieder am Optimieren ist).

--Mtaege 23:42, 16. Jun 2005 (CEST)

Das ist ja genau der Grund warum dort zwei Möglichkeiten angeboten werden!

Möglichkeit A)

Das SW-System wird mit Singletons entworfen d.h. die Zustände werden nur einmal erzeugt und nie zerstört! D.h. Wenn ein Zustand weiter existiert, kann man bei jedem Wechsel in diesen Zustand auf dessen Membervariablen zurück greifen. Dies ist bei Variante B nicht möglich.

Möglichkeit B)

Ein Zustand (in diesem Sinne temporär) wird immer nach seinem Verlassen im Speicher 'zerstört'.

Was jetzt von Vorteil ist, muss jeder SW-Architekt selbst entscheiden. -- Rovanu 12:30, 17. Jun 2005 (CEST)

Ich finde, dass das mit dem Singleton ganz rausgenommen bzw. davon abgeraten werden sollte. Ich habe auch schonmal als erste Alternative "der Kontext die Zustände als Attribute hält" eingefügt. Argument gegen die Verwendung des Singletonmusters ist z.B. folgendes: Es wäre nicht möglich einen konkreten Zustand in einem anderen Kontext wiederzuverwenden. --Rayx 11:34, 22. Mai 2006 (CEST) geändert 10:12, 23. Mai 2006 (CEST)

Wenn Du die Sache in Abhängikeit des Kontexts aufziehst, so kannst Du darauf wiederrum das Singelton anwenden, Singelton im Sinne von einem Zustandsobjekt für einen Kontext. Ich würde es so lassen, aber eine optionale Abhänigkeit vom Kontext aufnehmen. Rovanu 21:30, 23. Mai 2006 (CEST)

Ich verstehe nicht ganz, wie man den Singleton auf den Kontext beschränken soll. Wenn das tatsächlich so gemeint ist, dass es den Zustand pro Kontext nur einmal geben soll, dann finde ich es verwirrend, das mit dem Entwurfsmuster in Verbindung zu bringen. -- rayx Diskussion 17:38, 7. Jun 2006 (CEST)

"Sauberer für Programmablauf"

Was soll genau soll der folgende Punkt heißen: "bei jedem Zustandswechsel der vorherige Zustand gelöscht und ein neuer Zustand instantiiert wird, was zwar rechentechnisch aufwendiger aber sauberer für den Programmablauf ist. D.h. dass alle Membervariablen eines jeden Zustands gelöscht werden und ein evtl. späteres Debuggen von Anfang an ausschließt."? Ich schlage vor, diesen Punkt ganz zu löschen. Der Hinweis auf das Singleton schließt obigen Punkt ein.

Dann würde Dein Code wie folgt aussehen:

class Door {
        
    /*...*/
    internal void ChangeState( State s ) {
        myState.dispose(); // wenn er disposeable wäre
        myState = s;
    }
    /*...*/
};

class ClosedState : State {
    internal override void  OpenDoor( Door d ) {
        Console.Write("ClosedState::OpenDoor will open door now.");
        d.ChangeState( new OpenState() ); // <-----------------------------
        Console.WriteLine(" The door is now open.");  
    }        
};

Ja, klar. Aber ich verstehe nicht, was daran "sauberer für den Programmablauf" ist und inwiefern dies das Debuggen erleichtert. Zudem stört mich das Adjektiv "rechentechnisch". Dass beim Destruieren eines Zustandes (also eines Objektes) alle "Membervariablen gelöscht" werden, ist jedem Leser auch klar, oder? Wikiplex 18:30, 17. Nov. 2006 (CET)

Warum hast Du nicht das Filebeispiel, wie beschrieben gecoded? Du bist C++ Coder oder (ClosedState::OpenDoor gg)?

Rovanu 19:43, 16. Nov. 2006 (CET)

Ja, bin ich. Hast mich erwischt (gg). Ich bringe mir gerade C# bei und wollte das mit etwas Nützlichem verbinden, nämlich Artikel für Wikipedia schreiben. Ich ändere die "::" in ein "." Danke!

Das Filebeispiel ist nicht gut, denn es nicht nicht realistisch, obwohl es den Eindruck erweckt. Bei meinem Beispiel ist klar, dass es nur zu Demonstrationszwecken dient (ich sage ja auch explizit „Automat simuliert Tür“). Außerdem muss das Filebeispiel für open() und close() auf die C#-Library zurückgreifen, das macht es noch komplexer. Wikiplex 18:30, 17. Nov. 2006 (CET)

Entschuldige, wenn ich Deinen Text löschte und das Beispiel umgebaute. Ich finde, dass du nicht so viel Text dazu schreiben musst, dass hält den Leser nur ab es zu lesen. In diesem Abschnitt geht es eher um den Code (Umsetzung) - nicht um Vorteile, Nachteile, Alternativen, Verständnis des allgmeinen Prinzipes zu erlangen. Das sollte schon vorher im Text aufgenommen sein. Eher sollte man sich auf die allgemeine Beschreibung des Musters begrenzen. Ziel ist es doch die allgmeine Beschreibung so verständlich zu machen, dass Beispiele nur im geringem Maße benötigt werden. Versuch den Artikel als ein Ganzes zu sehen.

Grüße, Rovanu 17:49, 19. Nov. 2006 (CET)

Kleine Korrektur: Mehrzahl von "Der Status" ist "die Status" (mit langem u); "Stati" gibt es nicht. 192.109.190.88 15:35, 11. Jun. 2008 (CEST)

Klassendiagramm unter "Einfache Zustände"

Es geht um dieses Bild:

Klassendiagramm

Die ConcreteStates sollten hier alle Methoden der FileState Klasse implementieren, die schliesslich als abstract deklariert wurde. Das entspricht auch dem State Pattern, da ja jeder der States das angebotene Verhalten implementieren muss. Meinungen? Sonst aender ich das mal. --Bravebart 01:28, 21. Jan. 2009 (CET)

Ich sehe keine Hinweise darauf, dass die Methoden abstrakt sein müssen. Sie könnten auch über einen Hook (ein nicht-abstrakte leere Methode) implementiert werden. In dem Fall müssten sie auch nicht überschrieben werden. --Christian 14:25, 25. Sep. 2009 (CEST) (ohne Benutzername signierter Beitrag von 84.161.22.250 (Diskussion | Beiträge) )

Zustandsübergänge

Auf die Übergänge zwischen den Zuständen wird im Artikel gar nicht eingegangen. In der englischen Version wird im Java-Beispiel dargestellt, dass dem Zustand der Kontext übergeben werden kann, so dass der Zustand selbst dem Kontext mitteilt in welchen Folgezustand dieser wechseln soll. In der deutschen Version sieht es aus als wäre der Kontext (im Beispiel "File") für die Übergänge verantwortlich. Sollte also der Kontext oder der Zustand die Übergänge definieren? Oder gehören die Zustandsübergänge gar nicht zum Entwurfsmuster? --Christian 10:39, 2. Feb. 2010 (CET) (ohne Benutzername signierter Beitrag von 84.161.20.70 (Diskussion | Beiträge) )

Die State-Objekte sind für den Zustandswechsel zuständig. So ist es auch in GoF:305 beschreiben. Und das ist ja auch gerade der Sinn dieses Musters: Der Kontext weiß von den Zuständen nur, wie man mit ihnen umgeht. Die ganze Arbeit machen die State-Objekte selbst. So kann man den Automaten ganz einfach ändern, indem man die Zustandsklassen ändert. Der Kontext muss nicht angefasst werden. Der wichtigste Satz im GoF-Book: "Encapsulate the concept that varies." --Der Hâkawâti ✉ 12:01, 2. Feb. 2010 (CET)

Java 1.5 und enums

Was soll der Hinweis auf enums in diesem Zusammenhang bewirken? Wie kann man damit Aufwand sparen? Bitte dies etwas deutlicher herausarbeiten, oder den Hinweis entfernen. --195.212.29.171 13:49, 5. Mär. 2010 (CET)

Angeblicher Vorteil bei Erweiterung?

Kann mir jemand erklären, wieso das Statepattern als Vorteil genannt bekommt, dass man einen neuen Zustand leichter einpflegen kann? Genau das Gegenteil ist doch der Fall! Wenn ich ein funktionierendes Programm um einen neuen Zustand mit einer neuen Methode erweitern will, muss ich im Gegensatz zu einer Verzweigungs-basierten Anwendung sämtliche Zustandsklassen und die Schnittstelle um die neue Methode erweitern. Es ist allenfalls sicherer, weil man so auf keinen Fall vergessen kann, sich bei jedem Zustand Gedanken zu machen, was beim Aufruf der neuen Aktion in einem der alten Zustände passieren soll. Aber aufwandsärmer ist sicherlich, die Verzweigung um eine Abfrage zu erweitern und den Rest so zu lassen. - Chris (Diskussion) 17:24, 11. Mai 2013 (CEST)

Unübersichtliches Code-Beispiel

Ich denke, es wäre dem unerfahrenen Leser mit einem abstraktem Pseudocode-Beispiel mehr geholfen. Ich bin seit vielen Jahren Programmierer, ich beherrsche Java und mir war das State-Pattern schon bekannt, bevor ich den Artikel gelesen habe; trotzdem hatte ich ernsthafte Probleme, das Beispiel zu verstehen, besonders weil der Zustandsübergang hier mit einem ausgelagerten Aufrufzähler sehr gekünstelt ist und sich der mit vielen technischen Kommentaren gespickte Code über fast zwei Bildschirmseiten erstreckt. Hat jemand ernstliche Einwände, wenn ich ihn durch Pseudocode ersetze? - Chris (Diskussion) 17:31, 11. Mai 2013 (CEST)

Code unnötig komplex

Ich bin kein Java-Entwickler, aber mich hat stutzig gemacht, dass in firstLetterToUpper() das erste Zeichen sehr umständlich in eine Majuskel gewandelt wird, obwohl auch die substring()-Methode für den Rest zum Einsatz kommt. Ein Test bei http://www.compileonline.com/compile_java_online.php hat mir gezeigt, dass die Methode auch auf

 public static String firstLetterToUpper(final String WORDS) { 
        return WORDS == null ? "" : WORDS.toUpperCase().substring(0,1) + WORDS.toLowerCase().substring(1);
    }

eingedampft werden könnte. Zur Veranschaulichung ist hier eine if-Bedingung statt ?-Operator sicher besser. Außerdem fällt auf, dass die Funktion alle Buchstaben außer dem ersten in Minuskeln umwandelt. Das ist weder aus dem Namen noch der Beschreibung ersichtlich. Der Test am Ende veranschaulicht die Funktionsweise schlecht. Es sind alles korrekt geschriebene Wochennamen, somit hat firstLetterToUpper() überhaupt keinen Effekt. Dann sollte man lieber Strings wie "mONTag", "DIENstag" etc. verwenden. Und wenn das manch einem zu blöd ist, empfehle ich die Variante in der englischen Wikipedia. Dort macht die eine Funktion alles zu Minuskeln, die andere alles zu Majuskeln. Dann muss sich keiner mit diesem undurchsichtigen und unnützen Code herumschlagen. Damit sollte auch LWChris' Einwand an Gültigkeit verlieren. Der Code ist mir auch so schon verständlich und ich bin ja wie gesagt nicht mal Java-Entwickler. Deshalb überlasse ich auch die Überarbeitung lieber einem solchen. P.S.: Warum heißt der Eingabeparameter eigentlich "WORDS", also ein Plural? (nicht signierter Beitrag von WikiVerarbeiter (Diskussion | Beiträge) 19:40, 11. Nov. 2013 (CET))

Ich schließe mich dem an. Die Klasse Common hat mit dem Entwurfsmuster überhaupt nichts zu tun und verschlechtert die Verständlichkeit, zumal sie im gewählten Beispiel keinen Einfluss auf die Schreibweise hat. Die Variante in der englischen Wikipedia sollte hier bevorzugt werden. Der Zähler ist nicht intuitiv aber für mich ok. --95.91.250.12 18:49, 2. Dez. 2013 (CET)

Obfuscating

Ich bin immer wieder erstaunt, wie man unsinnige Beispiele aus der englischen Wikipedia entnehmen kann, die mich mehr an 'Obfuscating' erinnern.

GROß oder klein zu schreiben hat doch wahrlich nichts mit einem Zustand zu tun. Das Beispiel ist so willkürlich, dass man es in die Tonne treten sollte. (nicht signierter Beitrag von 80.187.110.125 (Diskussion) 10:04, 4. Jun. 2015 (CEST))

Vermutlich hast du recht. Darum solltest du ein besseres Beispiel bringen. WP:Sei mutig --Sebastian.Dietrich ✉ 21:06, 4. Jun. 2015 (CEST)

Deutsche Sprache

Der Artikel sollte besser in Deutsch verfasst sein, nicht in außerirdischen Sprachen wie "C+-" oder "Jawa". Längere Fremdsprachen-Passagen bedingen grundsätzlich eine Übersetzung, damit der Artikel lesbar und verständlich bleibt. --2001:A62:1A29:C501:D7D7:97D:B277:259C 21:54, 16. Feb. 2024 (CET)