Verhaltensmuster STATE-Pattern (Zustandsmuster) in objective-C

Original von moozoom
Ich kann deinen Einwand nicht so ganz nachvollziehen.

Aha.

Du bekommst den Fehler:
2010-03-16 15:38:16.077 StatePattern[4054:207] *** -[State initWithState:]: unrecognized selector sent to instance 0x3b03b00

Dein Code lautet sinngemäß:


Dein Problem ist nicht irgend ein Pattern, dessen Sinn ich bis jetzt noch nicht verstanden habe.
Dein Problem ist, dass du keine Ahnung von Klassen, Methoden, Selektoren und ähnlichen grundlegenden Konzepten hast.

Dies wird aber in jedem mir bekannten Büchlein ausführlichst behandelt.

Es handelt sich für mich um eine stinknormale Klasse, die irgend einen Wert speichert.

Warum ignorierst du meine Ausführungen?

Mag sein, dass in Java dieses State interface Teil eines grösseren Frameworks ist, dass vielleicht etwas mehr macht. Grafische Darstellungen anhand von Klassen die State implementieren. Ist aber nur Spekulation.
Im Grunde ist es tatsächlich nur eine Klasse die einem Wert speichert, nix wildes.
Wüsste auch nicht wieso man darauf so rumreiten sollte.


Manfred

Original von asrael
Im Grunde ist es tatsächlich nur eine Klasse die einem Wert speichert, nix wildes.

Das eben nicht. Bei diesem Muster wird der Zustand im Typ des Objekts gespeichert. Also jeder mögliche Zustand hat seine eigene (Unter-) Klasse. Die Operationen auf den Zuständen sind Methoden der Zustandsklassen, die jede Zustandsklasse anders implementieren kann. Dadurch spart mensch sich eklige If-Ketten oder Switches. (de.wikipedia.org/wiki/Zustand_(Entwurfsmuster))

@moozoom: Mach doch erstmal was Einfacheres als so ein abstraktes Entwurfsmuster, das Du augenscheinlich nicht verstanden hast.

Original von macmoonshine

Original von asrael
Im Grunde ist es tatsächlich nur eine Klasse die einem Wert speichert, nix wildes.

Das eben nicht. Bei diesem Muster wird der Zustand im Typ des Objekts gespeichert. Also jeder mögliche Zustand hat seine eigene (Unter-) Klasse. Die Operationen auf den Zuständen sind Methoden der Zustandsklassen, die jede Zustandsklasse anders implementieren kann. Dadurch spart mensch sich eklige If-Ketten oder Switches. (de.wikipedia.org/wiki/Zustand_(Entwurfsmuster))

Für was es nicht alles ein Pattern gibt.
Das ist doch alleine schon durch Subclassing gegeben, dass Methoden überschrieben werden können und dem Objekt dadurch eine andere Spezialisierung geben.


Manfred

Original von asrael
Für was es nicht alles ein Pattern gibt.
Das ist doch alleine schon durch Subclassing gegeben, dass Methoden überschrieben werden können und dem Objekt dadurch eine andere Spezialisierung geben.

So gesehen sind die meisten Patterns relativ einfach. Der Kniff dieses Patterns ist, dass der Zustand eben nicht in einem Aufzählungstyp abgelegt ist und die Fallunterscheidung nur einmal (wenn überhaupt) bei der Konstruktion des Zustands gemacht werden muss.

Original von macmoonshine

Original von asrael
Für was es nicht alles ein Pattern gibt.
Das ist doch alleine schon durch Subclassing gegeben, dass Methoden überschrieben werden können und dem Objekt dadurch eine andere Spezialisierung geben.

So gesehen sind die meisten Patterns relativ einfach. Der Kniff dieses Patterns ist, dass der Zustand eben nicht in einem Aufzählungstyp abgelegt ist und die Fallunterscheidung nur einmal (wenn überhaupt) bei der Konstruktion des Zustands gemacht werden muss.

Naja, sicher. Irgendwo muss eine Fallunterscheidung gemacht werden.

Ich wäre der Meinung, dass man auf viele Implementierungs-Kniffe mit etwas nachdenken selbst kommt. Manche sind einfach nur sozusagen gesunder Menschenverstand.
Einige kompliziertere sind es sicherlich Wert "Pattern" genannt zu werden.
Was mich etwas nervt, wenn man sich heutzutage Jobanzeigen anschaut steht da nur noch Du musst dies und das und jenes Pattern können. Totaler Schwachsinn.


Manfred

Original von asrael
Naja, sicher. Irgendwo muss eine Fallunterscheidung gemacht werden.

Häufig ist das nicht nötig, wenn die verwendete Programmiersprache Introspektion unterstützt.

Original von asrael
Ich wäre der Meinung, dass man auf viele Implementierungs-Kniffe mit etwas nachdenken selbst kommt. Manche sind einfach nur sozusagen gesunder Menschenverstand.

Die Gang of Four sind ja ein bisschen die Brüder Grimm der Objektorientierung. Die haben die meisten Muster ja nicht erfunden sondern nur aufgeschrieben. Sie haben auch den Begriff Muster nicht für die Ingenieurswissenschaften entdeckt. Sie haben ihn adaptiert. Letztendlich haben sie lauter bekannte Dinge zu einem großen Zusammenhang kombiniert. Hinterher ist es immer leicht zu sagen: Das ist aber einfach.

Original von asrael
Einige kompliziertere sind es sicherlich Wert "Pattern" genannt zu werden.

Nein, das halte ich für falsch. Es geht bei Mustern nicht darum, dass sie besonders kompliziert sind. Es geht darum, für wiederkehrende Aufgaben einfache und elegante Lösungen zu finden. Wenn das Zusandsmuster so einfach ist, warum hast Du es in Deinem ersten Beitrag falsch wiedergegeben? Warum begegnet mir andauernd Code, wo es nicht eingesetzt wird?

Original von asrael
Was mich etwas nervt, wenn man sich heutzutage Jobanzeigen anschaut steht da nur noch Du musst dies und das und jenes Pattern können. Totaler Schwachsinn.

Da hast Du sicherlich recht. Einzelne Muster oder eine feste Musterliste zu können, macht nicht viel Sinn. Sinnvoller ist es in Mustern zu denken und Muster auf neue Situationen adaptieren zu können.


Manfred[/quote]

Original von macmoonshine
Häufig ist das nicht nötig, wenn die verwendete Programmiersprache Introspektion unterstützt.

Die meisten gängigen Sprachen unterstützen das. Das bedeutet aber nicht unbedingt, dass man Reflection APIs dafür nutzen sollte. Mit Generics wäre sowas sicher auch möglich, zumindest in den Statisch-Typisierten Sprachen.

Original von macmoonshine
Die Gang of Four sind ja ein bisschen die Brüder Grimm der Objektorientierung. Die haben die meisten Muster ja nicht erfunden sondern nur aufgeschrieben. Sie haben auch den Begriff Muster nicht für die Ingenieurswissenschaften entdeckt. Sie haben ihn adaptiert. Letztendlich haben sie lauter bekannte Dinge zu einem großen Zusammenhang kombiniert. Hinterher ist es immer leicht zu sagen: Das ist aber einfach.

GoF war mir bis jetzt kein Begriff. Ich habe auch nicht gesagt, dass das State Pattern einfach ist.

Original von macmoonshine
Nein, das halte ich für falsch. Es geht bei Mustern nicht darum, dass sie besonders kompliziert sind. Es geht darum, für wiederkehrende Aufgaben einfache und elegante Lösungen zu finden.

Für einfache Sachverhalte spielt es nur eine geringe Rolle ob man sich strikt an Muster hält.

Original von macmoonshine
Wenn das Zusandsmuster so einfach ist, warum hast Du es in Deinem ersten Beitrag falsch wiedergegeben? Warum begegnet mir andauernd Code, wo es nicht eingesetzt wird?

Hab ich das wo wiedergegeben?
Das ist nun ein Pattern, was man nicht unbedingt braucht.

Original von macmoonshine
Da hast Du sicherlich recht. Einzelne Muster oder eine feste Musterliste zu können, macht nicht viel Sinn. Sinnvoller ist es in Mustern zu denken und Muster auf neue Situationen adaptieren zu können.

In Mustern zu denken, hmm, weiss nicht. Als Mensch möchte man eher nicht in Mustern denken denn eher die starren Denkmuster aufbrechen.
Braucht man für das Handwerk Software-Entwicklung nicht auch ein wenig Freiheit um flexibel und kreativ zu sein anstatt stur Muster zu implementieren. Das können sicherlich irgendwann auch Maschinen.
Ich will nicht Muster generell schlecht reden, wie könnte ich da ich ja auch einige, wenige verwende. Aber ich denke man muss da schon differenzieren.


Manfred

Auch noch mein Kommentar zum Thema "Patterns":
Ich bin jetzt nicht der glühende Verfechter davon, aber man sollte zumindest die wichtigsten kennen und verwenden, insbesondere da sie ja auch so einfach sind. Grade Dinge wie Singleton, Factory, Visitor und MVC braucht man andauern und der Versuch, entsprechende Probleme anders zu lösen endet so gut wie immer in schlechtem Code.
Von daher finde ich es auch nicht verkehrt, wenn ein Arbeitgeber darauf besteht, dass seine Angestellten gewisse Pattern kennen - warum sollte man sich dem auch verwehren, grade weil man diese doch auch schnell verstanden hat. Leider wird das ganze aber, wie ich finde, etwas "gehyped" und was an sich selbstverständlich sein sollte als grosse Kenntniss deklariert. Das passt so schön in die Welt, in der Nicht-Softwareingineure Design-Enscheidungen treffen, und in dieser leben wir ja..mehr oder weniger

Original von asrael
Die meisten gängigen Sprachen unterstützen das. Das bedeutet aber nicht unbedingt, dass man Reflection APIs dafür nutzen sollte. Mit Generics wäre sowas sicher auch möglich, zumindest in den Statisch-Typisierten Sprachen.

Mit Generics geht das nicht. Generics (in Java) oder Templates (in C++) existieren nur zur Compilezeit. Du brauchst dazu Introspektion, wenn Du Zustände ohne Fallunterscheidung erzeugen möchtest.

Original von asrael
GoF war mir bis jetzt kein Begriff.

Du redest über Entwurfsmuster und Dir sagt Gang of Four (de.wikipedia.org/wiki/Gang_of_Four_%28Design_Patterns%29) nichts?

Original von asrael
Ich habe auch nicht gesagt, dass das State Pattern einfach ist.

Dafür drückst Du Dich aber ungewöhnlich aus.

Original von asrael

Original von macmoonshine
Nein, das halte ich für falsch. Es geht bei Mustern nicht darum, dass sie besonders kompliziert sind. Es geht darum, für wiederkehrende Aufgaben einfache und elegante Lösungen zu finden.

Für einfache Sachverhalte spielt es nur eine geringe Rolle ob man sich strikt an Muster hält.

Muster sind keine Gesetze, an die mensch sich strikt halten muss. Muster sind eine Denkweise.

Original von asrael

Original von macmoonshine
Wenn das Zusandsmuster so einfach ist, warum hast Du es in Deinem ersten Beitrag falsch wiedergegeben? Warum begegnet mir andauernd Code, wo es nicht eingesetzt wird?

Hab ich das wo wiedergegeben?

Ja, hast Du:

Original von asrael (um 16:56)
Im Grunde ist es tatsächlich nur eine Klasse die einem Wert speichert, nix wildes.

Was daran falsch ist, habe ich bereits erläutert.

Original von asrael
Das ist nun ein Pattern, was man nicht unbedingt braucht.

Das sehe ich anders.

Original von asrael

Original von macmoonshine
Da hast Du sicherlich recht. Einzelne Muster oder eine feste Musterliste zu können, macht nicht viel Sinn. Sinnvoller ist es in Mustern zu denken und Muster auf neue Situationen adaptieren zu können.

In Mustern zu denken, hmm, weiss nicht. Als Mensch möchte man eher nicht in Mustern denken denn eher die starren Denkmuster aufbrechen.

Widersprichst Du Dir deswegen andauernd selber und erinnerst Dich nicht an Deine Aussagen?

Original von asrael
Braucht man für das Handwerk Software-Entwicklung nicht auch ein wenig Freiheit um flexibel und kreativ zu sein anstatt stur Muster zu implementieren. Das können sicherlich irgendwann auch Maschinen.
Ich will nicht Muster generell schlecht reden, wie könnte ich da ich ja auch einige, wenige verwende. Aber ich denke man muss da schon differenzieren.

Wie geschrieben Muster sind keine Gesetze oder Vorschriften. Es sind Vorgehensweisen bei wiederkehrenden Problemstellungen. Wieso soll mensch da immer das Rad neu erfinden? Und falls für so ein Problem da mal eine bessere Lösung gefunden werden sollte, wird das halt ein neues Muster.

Original von zermelo
Auch noch mein Kommentar zum Thema "Patterns":
Ich bin jetzt nicht der glühende Verfechter davon, aber man sollte zumindest die wichtigsten kennen und verwenden, insbesondere da sie ja auch so einfach sind. Grade Dinge wie Singleton, Factory, Visitor und MVC braucht man andauern und der Versuch, entsprechende Probleme anders zu lösen endet so gut wie immer in schlechtem Code.

Sicher. Deine genannten sind ja quasi nicht mehr weg zu denken.

Original von zermelo
Von daher finde ich es auch nicht verkehrt, wenn ein Arbeitgeber darauf besteht, dass seine Angestellten gewisse Pattern kennen - warum sollte man sich dem auch verwehren, grade weil man diese doch auch schnell verstanden hat.

Nein, verkehrt ist es nicht. Das meinte ich auch nicht.

Original von zermelo
Leider wird das ganze aber, wie ich finde, etwas "gehyped" und was an sich selbstverständlich sein sollte als grosse Kenntniss deklariert. Das passt so schön in die Welt, in der Nicht-Softwareingineure Design-Enscheidungen treffen, und in dieser leben wir ja..mehr oder weniger

Wahrscheinlich ist es genau das womit ich ein Problem habe.
Fehlt gerade noch, dass Patterns zu intellektuellen Besitz werden.

Original von moozoom
@Lucas de Vil
Wie hast du mit ObjC angefangen?

Mit nem Grundlagenbuch natürlich.

Original von moozoom
Ich werde mich jetzt nicht weiter zu dir äußern.

Du ignorierst mindestens zwei völlig unterschiedliche Compilerwarnungen
(Sinngemäß "enthält return obwohl als void deklariert" und "antwortet eventuell nicht auf initWithState:"); machst dabei trotz angeblich intensiver Einarbeitung Fehler, die in jedem Grundlagenbuch auf den ersten 80 Seiten erklärt werden und reagierst überhaupt nicht auf irgendwelche Ausführungen, die nach erstem Überfliegen des Quelltextes in Verbindung mit der Fehlermeldung mit einer Wahrscheinlichkeit von mindestens 80% die Lösung deines Problems darstellen.

Ich denke nicht, dass ich gewillt bin dir noch einmal zu helfen.
Du kannst so lange über die zwischenmenschliche Komponente des Forums meckern wie du willst, aber fass dir ruhig mal an die eigene Nase.

Original von moozoom
Ich habe 4 Bücher die das Objective-C und Cocoa gut behandeln.

Zudem habe ich ein paar Tutarials im Web durchgearbeitet um mich in die iPhone SDK einzuarbeiten.

Leider behandeln die Bücher das Thema Design Pattern nur am Rande.

Nun wollte ich mit Hilfe des Forums - learning by doing - das State-Design-Pattern erarbeiten. Hierbei handelt es sich um eigene kleine Programme um den Umgang mit ObjC und Cocoa besser kennenzulernen.

Ich kann nicht so ganz verstehen wieso Anfängerfragen hier im Forum nicht erwünscht sind.
Ich bin für jede konstruktive Kritik offen, nur aber dann wenn auch die Absichten der Kritik einer konstruktiven Lösungsfindung beitragen.

Entschuldige mal, aber du bekommst nicht mal einen Initialisierer gebaut. Entweder du hast die Bücher nicht durchgearbeitet oder du bist vollständig untalentiert.

Original von macmoonshine

Original von asrael
Im Grunde ist es tatsächlich nur eine Klasse die einem Wert speichert, nix wildes.

Das eben nicht. Bei diesem Muster wird der Zustand im Typ des Objekts gespeichert. Also jeder mögliche Zustand hat seine eigene (Unter-) Klasse. Die Operationen auf den Zuständen sind Methoden der Zustandsklassen, die jede Zustandsklasse anders implementieren kann. Dadurch spart mensch sich eklige If-Ketten oder Switches. (de.wikipedia.org/wiki/Zustand_(Entwurfsmuster))

@moozoom: Mach doch erstmal was Einfacheres als so ein abstraktes Entwurfsmuster, das Du augenscheinlich nicht verstanden hast.

Genau das hat er aber nicht implementiert.

Ich schrieb ja schon, dass man das in Objective-C ganz toll machen kann. Allerdings müsste er erst einmal Objective-C lernen.

Original von Amin Negm-Awad

Original von moozoom
Ich habe 4 Bücher die das Objective-C und Cocoa gut behandeln.

Zudem habe ich ein paar Tutarials im Web durchgearbeitet um mich in die iPhone SDK einzuarbeiten.

Leider behandeln die Bücher das Thema Design Pattern nur am Rande.

Nun wollte ich mit Hilfe des Forums - learning by doing - das State-Design-Pattern erarbeiten. Hierbei handelt es sich um eigene kleine Programme um den Umgang mit ObjC und Cocoa besser kennenzulernen.

Ich kann nicht so ganz verstehen wieso Anfängerfragen hier im Forum nicht erwünscht sind.
Ich bin für jede konstruktive Kritik offen, nur aber dann wenn auch die Absichten der Kritik einer konstruktiven Lösungsfindung beitragen.

Entschuldige mal, aber du bekommst nicht mal einen Initialisierer gebaut. Entweder du hast die Bücher nicht durchgearbeitet oder du bist vollständig untalentiert.

naja, talent braucht man dafür wirklich keines...