GoF-Pattern im Programmierer-Alltag

[LimDul]

Man muss trennen zwischen dem Objekt, was einer Variablen zugewiesen ist und dem Typ der Variablen

List list = new ArrayList();

Der Typ der Variable ist List. Das Objekt da drin ist aber eine ArrayList. In den weiteren Zeilen kannst du nur auf Methoden zugreifen, die von List definiert sind.

Betrachte es Brille, die du aufsetzt. Du betrachtest das Objekt durch die Brille "List" und siehst es nur noch List - alles andere wird beim Blick drauf ausgefiltert.

 

[Wuast]

Man muss trennen zwischen dem Objekt, was einer Variablen zugewiesen ist und dem Typ der Variablen

List list = new ArrayList();

Der Typ der Variable ist List. Das Objekt da drin ist aber eine ArrayList. In den weiteren Zeilen kannst du nur auf Methoden zugreifen, die von List definiert sind.

Betrachte es Brille, die du aufsetzt. Du betrachtest das Objekt durch die Brille "List" und siehst es nur noch List - alles andere wird beim Blick drauf ausgefiltert.

Ahhhh... BING! 💡
also habe ich

public class Worker {

    private String profession;
    private String name;
    private String tools;
    
    // ...
    
    //use interface as instance variable
    SkilledOrNotInterface skilledOrNot;
    
    public String getSkilledOrNot() {
        return skilledOrNot.skillSetup();
    }
    
    //let strategy pattern be dynamic:
    public void setSkilledOrNot(SkilledOrNotInterface skilledOrNot) {
        this.skilledOrNot = skilledOrNot;
    }
}

hier eine Variable vom Typ des

public interface SkilledOrNotInterface {
    String skillSetup();   
}

und über den Setter wird das Objekt zur dem, was ich übergebe - also entweder

public class CodingSkills implements SkilledOrNotInterface {
    @Override
    public String skillSetup() {
        return "I can code!";
    }
}

oder eben das Pendant dazu?! Und deswegen kann ich dann auch den Zustand von Objekten dynamisch zur Laufzeit entsprechend ändern. Ich glaube, jetzt hab ich es geschnallt.. (oder?)

 

[yfons123]

Wenn die Sprache oder das Framework irgend ein Pattern

warum sollte ich einen umständlichen builder in c# bauen wenn ich properties bzw init properties hab mit dem property initializer? warum soll ich mir die arbeit machen wenn ich es schon in der sprache habe das ziel leichter zu erreichen

 

[KonradN]

Die Init Properties sind nur eine andere Syntax für das Builder Pattern. Daher ist Deine Aussage Quatsch.

Das Builder Pattern ist so wichtig, dass es sogar eine vereinfachte Syntax dafür gibt. Aber es ist das Pattern.

Ebenso nutzt man dieses Pattern, wenn man einfach @Builder vor die Datenklasse setzt in Java mit Lombok.

 

[yfons123]

und warum sollte ich den "traditionellen" builder schreiben mit extra klasse usw wenn ich die vereinfachungen schon habe

gibt keinen grund das rad neu zu erfinden

 

[KonradN]

und warum sollte ich den "traditionellen" builder schreiben mit extra klasse usw wenn ich die vereinfachungen schon habe

gibt keinen grund das rad neu zu erfinden

a) hat das niemand behauptet. Es geht um die Verwendung des Patterns. Und natürlich nutzt Du das Builder-Pattern, wenn Du etwas hast wie:

var s = new Student()
{
    FirstName = "Jared",
    LastName = "Parosns",
};

// Mit FirstName / LastName init Properties

Es geht nicht darum, irgendwas selbst zu schreiben. Es ist normal, dass man immer weniger selbst schreiben muss, weil einem vieles generiert wird. Es geht um ein einfaches Grundverständnis! Man sollte schon verstehen, was man da eigentlich macht! Fehlt Dir dieser Überblick? Das .Net Framework macht irgend welche tollen magischen Dinge und Du freust Dich, dass da was zu gehen scheint? Sorry, aber da fehlt mir das Verständnis.

b) Diese "abgespeckten Builder" reichen nicht immer aus. Der traditionelle Builder sammelt die Daten um dann z.B. einen Konstruktor mit allen Argumenten aufzurufen. Damit kann eine Validierung der Werte statt finden. Diese Möglichkeit hast Du da nicht oder nicht so einfach.

Also so typische Dinge wie: Die Validierung von a benötigt den Wert von b. Also mal ein Beispiel aus den Fingern gesaugt: eine Frühverrentung geht nur, wenn Du eine Invalidität vorweisen kannst. Oder wenn Du einen Wert für A setzt, musst Du auch einen Wert für B setzen. Das haut da alles nicht hin.

Wenn Du eine vernünftige Validierung einer Instanz brauchst (bei der Erstellung), dann ist ein vollwertiger Builder wichtig. Und so ein einfaches Sprachfeature reicht dann eben nicht aus.

 

[mihe7]

Und deswegen kann ich dann auch den Zustand von Objekten dynamisch zur Laufzeit entsprechend ändern. Ich glaube, jetzt hab ich es geschnallt.. (oder?)

Ja, wobei die Formulierung

und über den Setter wird das Objekt zur dem, was ich übergebe

nicht richtig ist.

Die Instanzvariable ist kein Objekt, sondern speichert eine Referenz auf ein Objekt. Durch den Setter wird also die mit dem Parameter übergebene Objektreferenz in der Instanzvariablen abgelegt. Der Typ der Instanzvariablen ändert sich dadurch nicht.

 

[Wuast]

Ja, wobei die Formulierung

nicht richtig ist.

Die Instanzvariable ist kein Objekt, sondern speichert eine Referenz auf ein Objekt. Durch den Setter wird also die mit dem Parameter übergebene Objektreferenz in der Instanzvariablen abgelegt. Der Typ der Instanzvariablen ändert sich dadurch nicht.

Danke!

 

[Wuast]

Hallöchen,
mal wieder eine kurze Rückfrage zu einem Design-Pattern. Konkret dem StatePattern.

Ich habe ein Interface (oder ein abstrakte Klasse), welches ich dann implementiere (oder erben lasse) von den Zustandsklassen. Dadurch hat dann ja jede "spezielle Zustandsklasse" alle Methoden des Interfaces. Macht es Sinn, nur die passenden zu überschreiben und die übrigen nicht anzurühren, oder über die übrigen Pattern eine Art Exception auszugeben, oder die passende Interface-Methode aufzurufen oder was wäre am sinnvollsten?

Also z.B. bei folgender Situation:

public interface WorkerStateInterface {

    void isSick(boolean isSick);
  
    void isAtWork(boolean isAtWork);
}

public class WorkerStateSickness implements WorkerStateInterface {

    Worker worker;
  
    WorkerStateSickness (Worker newWorker){
        this.worker = newWorker;
    }
  
    @Override
    public void isSick(boolean isSick) {
        if (isSick == true) {    //ja ich weiß, ohne den == operator ists schöner aber für den Überblick fand ich es an dieser Stelle besser
        System.out.println("Worker is sick!"); 
        }
    }


    @Override
    public void isAtWork(boolean isAtWork) {
    }

bleibt der isAtWork jetzt leer oder sollte da dann die isSick(true) - Methode aufgerufen werden? Bin mir gerade nämlich nicht so sicher, wozu ich überhaupt ein Interface benötige wenn ich für jeden Zustand ohnehin eine eigene Zustandsklasse brauche und die dann gezielt aufrufe. Reichte da nicht dann die Injektion des Worker-Objekts auch aus?
Oder ist das Bsp. hier einfach nicht so der Knüller?
liebe Grüße

 

[yfons123]

State Pattern - Javatpoint

State Pattern with Patterns, design, Creational Design, Abstract Factory Pattern, singleton design patterns, Adapter, Visitor Pattern, Template Pattern, Command Pattern, State Pattern, java etc.

www.javatpoint.com

du hast es umgedreht

class Player
{
    Movement movement = new Forward();
    public void Process(float delta){
        movement = movement.Process();
    }
}
interface Movement
{
    public Movement Process();   
}
class Forward implements Movement
{
    public Movement Process(){
        if(KeyInput.SpaceBar)
            return new Jump().Process();
        System.out.println("Move");
    }   
}
....

 

[Wuast]

was hab ich umgedreht?

Deine Player-Klasse entspräche meiner Worker-Klasse (die ich hier nicht reinkopiert habe).
Movement Interface = workerStateInterface und Forward ist doch das, was in Abhängigkeit vom Zustand passiert. In meiner Vorlage hieß das ZustandXYZ, bei mir halt WorkerStateSickness und WorkerStateAtWork.

Oder was meinst du?

 

[yfons123]

du hast einfach nur eine composition gemacht und an die klasse das wort "state" dran gehängt, das macht es nicht zum state pattern

 

[mihe7]

Bin mir gerade nämlich nicht so sicher, wozu ich überhaupt ein Interface benötige wenn ich für jeden Zustand ohnehin eine eigene Zustandsklasse brauche und die dann gezielt aufrufe.

Das hast Du völlig richtig erkannt: der State wird ja gerade durch den Typ dargestellt. Das Interface brauchst Du, um die Methode(n) zu deklarieren, die aufgerufen wird (werden). Im Prinzip ist das State Pattern nichts anderes als das Strategy Pattern, nur dass die "Strategie" eben abhängig vom internen Zustand ist (das Objekt wählt also die Strategie selbst, beim Strategy Pattern wird das von außen festgelegt).

 

[Wuast]

ok ich guck nochmal danke