GoF-Pattern im Programmierer-Alltag

Y

yfons123

Gast
weniger erfahrenen Programmierer
im game dev hast du meistens die situation dass singleton massenhaft verwendet wird von neuen programmierern

da es das "wie kann ich denn darauf zu greifen" problem löst und es ist einfach und verständlich umzusetzen
also gerade solche einfachen patterns sind für neue programmierer am einfachsten zu übernehmen, obs jetzt wirklich jedes mal ein singleton sein muss ist fragwürdig aber die übung im umgang patterns kann man damit fördern und das ist schon auch was wert
 

Wuast

Bekanntes Mitglied
Hallöchen, ich habe da auch mal direkt eine kurze Rückfrage zum ProxyPattern.
Und diese lautet: Was stimmt hier nicht?

Java:
public class WorkerInformationService {

    public static void main(String[] args) {

    //--------------------
    //this object normally would NOT be in here:
    WorkerDataManagement wdm = new WorkerDataManagement();
    
    wdm.setHoursWorked(135.5);
    wdm.setLeaveDaysTotal(30.0);
    wdm.setLeaveDaysTaken(19.5);
    
    wdm.getAmountHoursWorked();            //testing
    wdm.getAmountLeaveDaysLeft();        //testing
    //--------------------

        
    WorkerInterface workerProxy  = new WorkerDataManagementProxy(wdm);
    
    //information allowed to be accessed:
    workerProxy.getAmountHoursWorked();
    workerProxy.getAmountLeaveDaysLeft();

    }
}

public interface WorkerInterface {
    
    double getAmountLeaveDaysLeft();
    double getAmountHoursWorked();
    
}

public class WorkerDataManagement implements WorkerInterface {

    //some "random" instance variables chosen as examples for a class like this:
    double leaveDaysTotal;       
    double leaveDaysTaken;
    double leaveDaysLeft;
    double hoursWorked;
    double sickDays;
    double salaryPerHour;


    public void setLeaveDaysTotal (double newLeaveDaysTotal) { this.leaveDaysTotal = newLeaveDaysTotal; }
    public double getLeaveDaysTotal() { return leaveDaysTotal; }
    
    public void setLeaveDaysTaken (double newLeaveDaysTaken) { this.leaveDaysTaken = newLeaveDaysTaken; }
    public double getLeaveDaysTaken() { return leaveDaysTaken; }

    public void setHoursWorked (double newHoursWorked) { this.hoursWorked += newHoursWorked; }


    @Override
    public double getAmountLeaveDaysLeft() {
        leaveDaysLeft = leaveDaysTotal - leaveDaysTaken;
        System.out.println("From " + leaveDaysTotal + " days off already " + leaveDaysTaken + " days were taken. \n Days off left: " + leaveDaysLeft);
        return leaveDaysLeft;
    }

    @Override
    public double getAmountHoursWorked() {
    return hoursWorked;
    }

}


public class WorkerDataManagementProxy implements WorkerInterface{

    public WorkerDataManagementProxy(WorkerDataManagement wdm) {
    }

    @Override
    public double getAmountLeaveDaysLeft() {
        WorkerDataManagement wdm = new WorkerDataManagement();
        return wdm.getAmountLeaveDaysLeft();
    }

    @Override
    public double getAmountHoursWorked() {
        WorkerDataManagement wdm = new WorkerDataManagement();
        return wdm.getAmountHoursWorked();   
    }

}

Konsolenausgabe:
From 30.0 days off already 19.5 days were taken.

Days off left: 10.5

From 0.0 days off already 0.0 days were taken.

Days off left: 0.0


Check ich gerade mal wieder nicht, kann mich jemand erleuchten? :) Danke und schönen Abend an alle
 

Wuast

Bekanntes Mitglied
Also nochmal kurz zur Ergänzung, ganz so blöd bin ich hoffentlich nicht. :D Mir ist schon klar, warum die Ergebnisse 0.0 sind, aber wieso soll man denn in den zu überschreibenden Methoden ein neues Objekt beim ProxyPattern erzeugen, weil dann habe ich doch nie die Werte, die ich an anderer Stelle mal für ein Objekt gesetzt habe.

So würde es ja gehen, aber ist das noch das Proxy aus dem Lehrbuch?
Java:
public class WorkerDataManagementProxy implements WorkerInterface {
    
WorkerDataManagement wdm = new WorkerDataManagement();
    
    public WorkerDataManagementProxy(WorkerDataManagement wdm) {
        this.wdm = wdm;
    }

    @Override
    public double getAmountLeaveDaysLeft() {
        return wdm.getAmountLeaveDaysLeft();
    }

    @Override
    public double getAmountHoursWorked() {
        return wdm.getAmountHoursWorked();   
    }

}
 

mihe7

Top Contributor
So würde es ja gehen, aber ist das noch das Proxy aus dem Lehrbuch?
Die Frage ist die, die @thecain schon gestellt hat, nämlich wozu der Proxy dienen soll.

Du delegierst hier einfach die beiden Interface-Methoden an das tatsächliche Objekt. Wozu dann der Proxy? Das einzige, was Du dadurch erreichst, ist, dass ein Cast auf WorkerDataManagement einen Laufzeitfehler auslösen würde, insofern könnte man das noch als "protection proxy" erkennen, wobei den Aufwand hierfür niemand betreiben würde (einfach gegen das Interface programmieren lassen und gut ists).

Interessant würde es werden, wenn Du den Zugriff z. B. an Zugriffsrechte hängst:
Java:
if (mayAccessLeaveDays) {
    return wdm.getAmountLeaveDaysLeft();
} 
throw new IllegalAccessException("...");
 

Wuast

Bekanntes Mitglied
Das ist jetzt völlig aus der "Luft gegriffen", es ging nur um die Struktur des Proxys. Ich versuche aktuell die Design-Pattern nachzuvollziehen und einmal die groben Züge nachzubasteln - ohne, dass es jetzt ein konkretes "Drumherum" gibt.
In der Praxis würde dann z.B. das Sinn machen, wenn ich als Mitarbeiter vllt. eine Seite aufrufen möchte aber nur bestimmte Zugriffsrechte habe, wie @mihe7 ja andeutete. Z.B. könnte ich da Infos zu meinen Arbeitszeiten und noch übrigen Urlaubstagen abrufen, aber natürlich nicht selber eintragen, sonst hab ich ja unendlich Urlaubstage :)

Also wenn ich ein z.B. ein boolean in der Worker Klasse Habe, wie mayAcces..., dann wäre der Rest in Ordnung? Ich habe das so verstanden, dass der Kern des Proxys darin besteht, dass ich über das Interface eine "abgespeckte" Variante einer Klasse XYZ habe, die ich dann in bestimmten Programmteilen zur Verfügung stelle, damit eben die Klasse XYZ (bzw. besser gesagt das Objekt der Klasse) und deren Infos, Methoden, Variablen, ...) geschützt sind und nur so weit abgerufen werden können, wie es eben erlaubt und über das Interface definiert ist.
 

mihe7

Top Contributor
Ich habe das so verstanden, dass der Kern des Proxys darin besteht, dass ich über das Interface eine "abgespeckte" Variante einer Klasse XYZ habe
Was Du hier beschreibst ist ein ganz bestimmter Typ eines Proxys. Im Allgemeinen ist ein Proxy einfach ein Objekt, das stellvertretend (aus welchem Grund auch immer) für ein anderes Objekt steht.

Mal ein anderes Beispiel: nehmen wir mal einen auf eine Datenbank abgebildeten "Objektgraphen". Zum Beispiel habe ich Personen und jeder Person ist eine Firma zugeordnet. In der Klasse Person habe ich also Getter und Setter für die Firma. In der DB finde ich eine Tabelle PERSON und eine Tabelle FIRMA, beide hätten eine ID und in Tabelle PERSON findet man dann auch die ID der Firma.

Wenn ich jetzt Personen aus der DB lade, brauche ich dann immmer auch die Firmendaten? Nicht wirklich. Andererseits habe ich das Problem, dass die Klasse Person einen Getter für die Firma hat und da wäre es doch gut, irgendwas Vernünftiges zurückzugeben.

Hier kann dann ein Proxy zum Einsatz kommen, ich beschränke mich mal auf zwei Felder:
Java:
interface Firma {
    Long getId();
    void setId(Long id);
    String getName();
    void setName(String name);
}

Dazu gibts eine normale Implementierung:
Java:
public class FirmaImpl implements Firma { ... }

Und einen Proxy (nicht schön implementiert, aber um das Prinzip zu verdeutlichen, reichts):
Java:
class FirmaProxy implements Firma {
    private Firma firma;
    private boolean geladen;
    private Long id;

    public FirmaProxy(Long id) { this.id = id; }

    public Long getId() {
        return geladeneFirma().getId();
    }

    public void setId(Long id) {
        geladeneFirma().setId(id);
    }

    public String getName() {
        return geladeneFirma().getName();
    }

    public void setName(String name) {
        geladeneFirma().setName(name);
    }

    private Firma geladeneFirma() {
        if (!geladen) {
            // lade Firma aus DB
            geladen = true;
        }
        return firma;
    }
}
Wenn ich jetzt eine Person aus der DB lese, steht dort die Firmen-ID, die ich nutzen kann, um ein FirmaProxy-Objekt zu erstellen und der Person zuzuweisen. Die Person gibt beim Zugriff auf die Firma (getFirma()) das Proxy-Objekt zurück und erst, wenn ich auf ein Feld der Firma zugreife, wird das Objekt wirklich aus der DB geladen.
 

Wuast

Bekanntes Mitglied
Toll erklärt, danke dafür!

D.h. ich würde dann in der PERSON z.B. über
Java:
FirmaProxy fp = new FirmaProy();

Firma f = fp.geladeneFirma();
f.getID();
an die Inhalte kommen oder wie muss ich das verstehen? Ich denk nochmal drüber nach und korrigiere die Frage ggf :D Bin wieder schon etwas verbraucht für heute
 

mihe7

Top Contributor
an die Inhalte kommen oder wie muss ich das verstehen?
Nein, die Nutzer (Clients) wissen gar nicht, dass sie ein Proxy-Objekt erhalten. Dieses implementiert ja die Schnittstelle Firma und kann daher auch in dieser Weise verwendet werden.

Stell Dir mal einen Ausschnitt von Person wie folgt vor:
Java:
private Firma firma;

public void setFirma(Firma firma) { this.firma = firma; }
public Firma getFirma() { return firma; }

Wenn nun eine Person geladen wird:
Java:
public Person ladePerson(long id) {
    Person person = new Person(id);
    person.setName(...); // aus DB
    long firmenId = // aus DB
    person.setFirma(new FirmaProxy(firmenId));
    return person;
}

Als Client bekomme ich also ein Person-Objekt. Will ich dessen Firmendaten haben, greife ich einfach per getFirma() ein Objekt mit Firma-Schnittstelle ab. Dass das ein FirmaProxy und kein FirmaImpl ist, weiß ich nicht und muss mich auch nicht interessieren: mir reicht es zu wissen, dass das Objekt die Firma-Schnittstelle implementiert.

Wenn ich dann getFirma().getName() aufrufe, dann schaut der Proxy nach: hey, wurde die Firma schon aus der DB geladen? Wenn nicht, dann lade sie aus der DB. Wenn schon, dann delegiere den Aufruf einfach weiter an das bereits vorhandene Objekt.

Aber schau Dir mal den Link von @thecain an, da wird das schön erklärt.
 

Wuast

Bekanntes Mitglied
Mach ich! Ich warte auch noch auf das Entwurfsmuster von Kopf bis Fuß, was leider heute dann doch nicht angekommen ist. -.-
Ich muss und werde mir das morgen / später nochmal in Ruhe anschauen :)
 

Wuast

Bekanntes Mitglied
So, da ist das Buch auch endlich. Ist wirklich gut geschrieben, danke nochmal für die Empfehlung @White_Fox . Auch der Link von @thecain ist gut. Ich denke, mit beiden zusammen komme ich tatsächlich besser voran als mit den YT-Videos. 😄👍

Dann direkt eine Rückfrage zum Decorator-Pattern, was ich - wie ich glaube - auch soweit geschnallt habe.
Kann ich mehrere konkrete Komponenten für ein zu dekorierendes Objekt dekorieren?

also hier z.B. bei
Java:
public class WorkerOutfittery {

    public static void main(String[] args) {
        
        WorkerOutfit worker_1_outfit = new Clothes();       
        worker_1_outfit = new Boots(worker_1_outfit);        //hier ist es ein "clothes"
        worker_1_outfit = new Dungarees(worker_1_outfit);    //hier ist es ein "clothes"
        worker_1_outfit = new Overall (worker_1_outfit);    //hier ist es ein "clothes"
        worker_1_outfit = new Driller (worker_1_outfit);    //das wäre ein "tools"

        System.out.println(worker_1_outfit.getOutfitItem() + "total pledge is about " + worker_1_outfit.getPledge());
        
        //und hier nochmal im Prinzip das gleiche
        WorkerOutfit worker_2_outfit = new Hammer (new Driller (new Tools() ) );
        System.out.println(worker_2_outfit.getOutfitItem() + "total pledge is about " + worker_2_outfit.getPledge());
        worker_2_outfit = new Boots (new Dungarees ( new Overall (new Clothes()) ) );
        System.out.println(worker_2_outfit.getOutfitItem() + "total pledge is about " + worker_2_outfit.getPledge());

    }

/* Konsolenausgabe:
clothes: security Boots, Dungarees, Overall, Driller, total pledge is about 131.0
tools: Driller, Hammer, total pledge is about 65.0
clothes: Overall, Dungarees, security Boots, total pledge is about 81.0
*/
}

sodass auch die Zuordnungen zu Clothes und Tools beibehalten werden? Weil so wie hier beschrieben würde ja der Driller zum typ "clothes".
Ich würde mir eine Ausgabe wünschen wie z.B. "clothes: security Boots, Dungarees, Overall, tools: Driller, total pledge is about 131.0". Oder eignet sich das decorator da nicht, da ich hier auf einen konkreten Typ angewiesen wäre?
 

White_Fox

Top Contributor
So, da ist das Buch auch endlich. Ist wirklich gut geschrieben,
Das freut mich zu hören.

Kann ich mehrere konkrete Komponenten für ein zu dekorierendes Objekt dekorieren?
Naja, das kommt auf deine Implementierung drauf an. Mehrfachvererbung geht in Java nicht (aus gutem Grund), eine Klasse kann aber viele Interfaces implementieren.

Wichtiger ist aber die Frage: Wofür soll das gut sein? Eine Klasse sollte entweder ein Bauplan für ein Kleidungsstück ODER für ein Werkzeug sein. Gottklassen, die alles können, sind eigentlich immer eine schlechte Idee.
 

Wuast

Bekanntes Mitglied
Wichtiger ist aber die Frage: Wofür soll das gut sein? Eine Klasse sollte entweder ein Bauplan für ein Kleidungsstück ODER für ein Werkzeug sein.
Mal in Bezug auf das Beispiel: Ein Arbeitnehmer wird von seinem Arbeitgeber ausgerüstet - kein Plan, Arbeitnehmerleasing oder was auch immer.
Er erhält Kleidung, aber auch Ausrüstung. Müsste ich dann wohl unter "outfit" zusammenfassen und nicht weiter ausdifferenzieren? In meinem Fall jetzt habe ich zwei separate Komponenten, die ich dekorieren kann - nämlich die Tools (Werkzeug) und die Clothes (Arbeitsschutzkleidung etc.).

Ich habe es jetzt über abstrakte Klassen und Vererbung zwecks Klassentypen (wie in dem Buch beschrieben) umgesetzt. Das ginge dann also nur mit Interfaces
 

mihe7

Top Contributor
Beim Beispiel kann ich nicht mitreden, weil ich das Buch nicht habe. Beim Decorator geht es darum, Verhalten zu bestehenden Klassen "hinzuzufügen". Technisch läuft das ganz ähnlich wie beim Proxy ab, aber die Intention ist eine andere.

Beispiel aus der Praxis: java.io.BufferedReader ist ein Decorator, der Reader-Objekte derart dekoriert, dass er die Pufferung hinzufügt. Während also z. B. ein konkreter Reader ggf. tatsächlich nur einzelne Bytes liest, liest der BufferedReader einen ganzen "Block" auf einmal und kann nachfolgende read()-Anfragen aus dem Puffer bedienen. Der Witz ist also, dass einem x-beliebigen Reader die Puffer-Funktionaliät hinzugefügt werden kann, indem ich ihn mit einem BufferedReader "dekoriere".
 

Wuast

Bekanntes Mitglied
das kaffee beispiel in java erklärt es ganz gut was das decorator pattern macht
Das Kaffee-Bsp. habe ich auch aus dem Buch Entwurfsmuster 😶 -🦶 Ich denke, ich habe das decorator Pattern verstanden. Mir ging es bei meiner Rückfrage darum, ob ich theoretisch mehr als eine konkrete Komponente mit einem decorator dekorieren kann - Lösung scheint ja das Interface zu sein. :) Ob und wann das sinnvoll ist, steht ja auf einem anderen Blatt. Ich denke mal, ich hätte bei mir die Outfits auch einfach nicht in Tools und Clothes unterscheiden müssen und schon wäre die Frage gar nicht aufgekommen.
 

White_Fox

Top Contributor
Tools und Clothes könnte man auch als Equpiment zusammenfassen...wenn es dein Objektmodell erlaubt. Es kommt halt sehr darauf an, was du nachher wie aufdröseln willst. Anstelle einer Methode 'getPrice()' wie im Kaffeebeispiel kannst du ohne weiteres auch zwei Methoden 'getClothes()' und 'getTools()' hinzufügen. Jede Klasse muß dann halt wissen ob sie ein Werkzeug, ein Kleidungsstück oder gar beides ist.
 
Zuletzt bearbeitet:

Wuast

Bekanntes Mitglied
Genau, hatte wohl auch Wortfindungsstörungen :D
Und jetzt nochmal abschließend für mich: Eine Klasse kann Werkzeug UND Kleidungsstück sein indem es Interfaces implementiert, richtig?
In deinem Buchvorschlag wird ja mit abstrakten Klassen und Vererbungen gearbeitet. Aber da geht ja nur ein Erbe pro Klasse.
 

White_Fox

Top Contributor
Und jetzt nochmal abschließend für mich: Eine Klasse kann Werkzeug UND Kleidungsstück sein indem es Interfaces implementiert, richtig?
In deinem Buchvorschlag wird ja mit abstrakten Klassen und Vererbungen gearbeitet. Aber da geht ja nur ein Erbe pro Klasse.
Ja. Interfaces gingen mir etwas auf den Sack, den für sowas muß man jede Menge redudanten Code schreiben. Die Klassen machen ja alle dasselbe.

Oder was auch ginge: du schreibst eine abstrakte PlainDecorator-Klasse, wo du die eigentliche Dekoratorfunktionalität einbaust, und deklarierst deren Methoden als protected. Davon dann soviele Klassen ableiten wie du lustig bist, und aus dieser Klasse herraus die Methoden der Superklasse benutzen.

Aber wahrscheinlich hat temi noch eine bessere Idee...ich bin kein Softwerker und werde auch keiner mehr. ;)
 

osion

Bekanntes Mitglied
Hallo Leute,

ich brüte im Rahmen eines Kurses zum Software-Engineering über einem Buch, welches in einem Kapitel einige der GoF-Pattern vorstellt, z.B.
neben Observer auch Adapter, Fassade, Strategy, Abstrakt Factory, und viele weitere...

ich bin etwas erschrocken, wie sehr man das Programmieren in "richtigere" oder / gute "Lösungswege" einsortieren kann (was ja andere Lösungswege irgendwie erstmal entwertet).
Jedenfalls scheint mir zunächst vom ersten Lesen her das Erlernen der ganzen Pattern extrem schwierig, z.B. die alle erstmal überhaupt zu behalten und dann auch noch für mich umsetzbar zu machen. Bisher bin ich auch auf diese abstrakte, theoretische Art noch nicht an Pattern herangeführt worden, sondern nur sehr vereinzelt und dann ggf. über konkrete Aufgaben oder Hinweise von euch hier aus dem Forum. (also eigentlich kannte ich bisher "nur" Singleton, Observer, Factory)

Gehören diese ganzen anderen GoF-Pattern zum Standard-Werkzeug im Arbeitsalltag, also sitzt man dann da und denkt sich "ahh, hier nutze ich jetzt das Pattern xyz weil ... " und "macht das dann einfach"? Macht man das mit der Zeit oder muss ich das knüppelhart wie andere Grundlagen auch lernen, wie man ja auch z.B. lernen muss, was Variablen und Klassen sind etc. ?

Bin etwas erschrocken, was da alles noch lauert und wie sich ein etwaiger Erwartungshorizont an Entwickler noch verschieben kann...
Also meine Frage an Leute aus der Praxis: Wo, wie (oft) und wie bewusst begegnen euch diese ganzen GoF-Pattern im Berufsalltag?

Ich wünsche euch ein schönes Wochenende!
Es ist tatsächlich so, dass das Erlernen von Design Patterns wie den GoF-Patterns eine Herausforderung sein kann. Es ist wichtig, sich bewusst Zeit zu nehmen, um sie zu verstehen und zu lernen, wie man sie in der Praxis anwendet. Im Berufsalltag werden diese Patterns nicht immer bewusst verwendet. Oft werden sie unbewusst angewendet, ohne dass man sich bewusst darüber Gedanken macht. Es ist jedoch wichtig, sie zu kennen und zu verstehen, da sie bei der Lösung von bestimmten Problemen hilfreich sein können. Es lohnt sich daher, sich die Zeit zu nehmen, um sie zu lernen und in der Praxis anzuwenden.
 

Wuast

Bekanntes Mitglied
Hallo Leute, hoffe ihr hattet schöne Feiertage. Bevor es in den "guten Rutsch" geht wollte ich kurz etwas nachfragen. Ich frage einfach hier, weil mir das im Rahmen der Pattern-Bearbeitung auffällt.

Wo liegt der Vorteil darin, ein Interface als Instanzvariable in einer Klasse zu erstellen anstatt das Interface einfach zu implementieren?
(so z.B. bei der mir vorliegenden Vorstellung des Strategy-Pattern)
 
Y

yfons123

Gast
wenn du es einmal exakt so brauchst, warum solltest du dann eine klasse daraus machen?
außerdem kannst du lambda ausdrücke so umsetzen in einem Functional interface, stell dir vor du müsstest für jeden button klick eine klasse schreiben
 

KonradN

Super-Moderator
Mitarbeiter
Wo liegt der Vorteil darin, ein Interface als Instanzvariable in einer Klasse zu erstellen anstatt das Interface einfach zu implementieren?
(so z.B. bei der mir vorliegenden Vorstellung des Strategy-Pattern)
Ich bin mir nicht sicher, ob ich dich richtig verstehe.

Du willst wissen, wieso ich das Quaken der Ente nicht direkt in der Ente implementiere sondern statt dessen ein Interface dafür habe um dieses dann in eigenenständigen Klassen zu implementieren und dann bekommt die Ente eine entsprechende Instanz?

Das wird in dem Buch Entwurfsmuster von Kopf bis Fuß doch recht gut erklärt.

Das Problem in dem Buch war - so ich mich richtig erinnere - dass Enten quaken können sollen. Aber es gibt viele unterschiedliche Arten von Enten: Die lebende Ente, die "Badeente" deren Quaken dann mehr ein Quietschen ist, eine Holzente (deren Quaken dann vermutlich gar nichts ist) u.s.w.
==> Es gibt also nicht ein Verhalten in Ente sondern es gibt ganz viele

Dann könnte man es natürlich abstrakt machen in Ente und die ableitenden Klassen würden es dann implementieren.

Dann kommt aber das nächste Problem: zwei konkrete Klassen, die von Ente erben, haben das gleiche Quaken. Bei dem oben genannten Ansatz führt das zu einem Problem. Man kann sich da zwar noch mit eine weiteren Zwischenklasse behelfen, von der die dann beide erben, aber das geht nicht, sobald es mehrere Verhalten gibt:

Ich habe also eine Basisklasse "Basisklasse" mit den abstrakten Verhalten a und b
Für a gibt es diverse Implementationen: A1, A2, A3, ....
Ebenso für b: B1, B2, B3, ...
Nun habe ich abgeleitete Klassen: AKlasse1 braucht A1 und B1, AKlasse2 braucht A1 und B2, AKLasse3 braucht A2 und B2, ...

Wo packst Du nun die Implementationen hin? Doppelten Code will man ja nicht haben. Hier kann man dann auch sehr gut sehen, wie man ohne Strategy Pattern zu kennen sowas bauen kann: Die Klassen haben dann halt die Implementationen. A1, A2, B1, B2 sind dann konkrete Methoden. Diese sind dann natürlich doppelt. Doppelter Code bedeutet, dass man das heraus zieht und dann aufruft. In diesem Fall ziehen wir die Methode also heraus und rufen es dann auf. Man kommt da also relativ gut eben zu genau dem Aufbau - auch wenn man das Pattern nicht kennt.

War das etwas verständlich?
 

White_Fox

Top Contributor
Hallo Leute, hoffe ihr hattet schöne Feiertage. Bevor es in den "guten Rutsch" geht wollte ich kurz etwas nachfragen. Ich frage einfach hier, weil mir das im Rahmen der Pattern-Bearbeitung auffällt.

Wo liegt der Vorteil darin, ein Interface als Instanzvariable in einer Klasse zu erstellen anstatt das Interface einfach zu implementieren?
(so z.B. bei der mir vorliegenden Vorstellung des Strategy-Pattern)

Klassen beschreiben, was etwas ist. Ein Objekt vom Typ 'SUV', dessen Klasse von 'PKW' erbt die wiederum von 'Landfahrzeuge' erbt, ist ein SUV, ein PKW und ein Landfahrzeug. Mit Interfaces beschreibst du aber oft z.B. Zusatzfähigkeiten. Wenn es dir bei deiner Instanzvariable nicht darauf ankommt was etwas ist, sondern was es kann, was willst du dann mit der Klasse?

Beispiel:
Wenn die Digitaltussi der letzten Bundesregierung endlich mal ihre halluzinierten Flugtaxis bekommt, könntest du einfach eine Klasse 'Flugtaxi' von 'PKW' ableiten, und das Objekt wäre ein normaler PKW. Dem spendierst du jetzt ein Interface 'Flugfähig', und das Ding kann fliegen.

Wenn du dieses Interface jetzt noch in zwei oder drei weiteren Klassen (fliegenes Polizeiauto, fliegende Feuerwehr, der Ampel ist bestimmt auch nix zu doof) implementierst, und es kommt dir für deine Instanzvariable auf die Methoden des Interfaces an, nutzt dir die Klasse nichts. Es können ja mehrere Klassen sein und wenn du eine übergeordnete Klasse nimmst gerätst du in Konflikte, wenn eine andere abgeleitete Klasse das Interface nicht implementiert.


Anderes Beispiel: Manchmal willst du nur einen bestimmten Teilaspekt eines Objekts haben. Ich habe das mal als MVC-Struktur (kommt im Buch ganz am Ende, falls du da noch nicht bist) so aufgesetzt:
Meine Anwendung besteht aus drei Teilen, dem Model das alle Nutzdaten enthält, dem Controler der für die Programmlogkik zuständig ist, und die View als Benutzerschnittstelle.
Die View soll dabei vom Model nur lesen dürfen, jegliche Änderungsoperationen auf dem Model sind dem Controller vorbehalten der die Programmlogik steuert.
Also bekommt das Model zwei Interfaces: ModelsControlerside und ModelsViewside. ModelsControlerside enthält alle Methoden, mit denen der Controler auf dem Model tun kann was er für richtig hält, das Interface ModelsViewside ausschließlich Methoden mit denen die View Daten auslesen, aber eben nicht ändern kann.

Wenn Controller und View jetzt nicht auf der Klasse Model, sondern nur auf dem jeweiligen Interface arbeiten, lichtet das den Methodenwald ganz erheblich und macht die Autovervollständigung sehr viel übersichtlicher. Und du kommst gar nicht erst in Versuchung, aus einem Bereich in dem du nur lesen sollst heraus Änderungsoperationen durchzuführen.
 

mihe7

Top Contributor
Wenn die Digitaltussi der letzten Bundesregierung endlich mal ihre halluzinierten Flugtaxis bekommt
Die Andrea stammte auch von der CSU, die bekanntermaßen mit Bavaria One auch ein bayerisches Weltraumprogramm verfolgt. Da wird sich die Welt aber anschauen, wenn die erste Rakete in Weißwurstform den Planeten verlässt. SCNR.
 

temi

Top Contributor
Wo liegt der Vorteil darin, ein Interface als Instanzvariable in einer Klasse zu erstellen anstatt das Interface einfach zu implementieren?
Kommt darauf an, was dein Ziel ist. Wenn deine Klasse sich verhalten können soll wie das Interface es festlegt, dann muss sie es implementieren. Soll die Klasse nur eine Instanz davon speichern können, dann kann sie dieses als Instanzvariable haben und da kann es sinnvoll sein als Typ das Interface anzugeben, um flexibler zu sein.
 
Zuletzt bearbeitet:

mihe7

Top Contributor
Oder, um es anders zu formulieren: die Implementierung des Interface steht zum Zeitpunkt der Übersetzung des Quelltexts fest, eine Referenz auf eine Implementierung des Interface lässt sich dagegen zur Laufzeit ändern.
 

Wuast

Bekanntes Mitglied
wenn du es einmal exakt so brauchst, warum solltest du dann eine klasse daraus machen?
ich verstehe nicht, wie du das meinst. Die Klasse (interface) habe ich doch ohnehin schon, wenn ich daraus ein Objekt für eine Instanzvariable mache.
Dazu siehe https://www.baeldung.com/design-patterns-series -> https://www.baeldung.com/java-strategy-pattern (auch hier gilt es Änderungen oder Erweiterungen aller Art leichter implementieren zu können)
Jo danke für den Link. Lambdas waren für mich an der Stelle noch kein Ding. Ich bin ja gerade eher bei den grundsätzlichen Ideen der Patterns.
Ich bin mir nicht sicher, ob ich dich richtig verstehe.

Du willst wissen, wieso ich das Quaken der Ente nicht direkt in der Ente implementiere sondern statt dessen ein Interface dafür habe um dieses dann in eigenenständigen Klassen zu implementieren und dann bekommt die Ente eine entsprechende Instanz?
Ich bin mir nicht sicher, ob ich DICH jetzt richtig verstehe :D
Es geht z.B. konkret um Folgenden Code, den ich einmal mit eigenen Klassen nachgebaut habe (mal ein ganz dummes Bsp.):

Java:
public class WorkSheet {

    public static void main(String[] args) {

        Worker programmer = new Programmer();
            programmer.setName("The Nerd");
       
        System.out.println("We need someone to write a code!");
        System.out.println("");
       
       
        // ------------------------
       
        System.out.println(programmer.getName() + " answers: " + programmer.getSkilledOrNot());
       
        System.out.println(programmer.getName() + " got struck by lightning and lost his memory.");
       
        programmer.setSkilledOrNot(new NoCodingSkills());
       
        System.out.println(programmer.getName() + " says " + programmer.getSkilledOrNot());

Konsolenausgabe:
We need someone to write a code!
The Nerd answers: I can code! (Anmerkungen: Ich hoffe doch, "Nerd" ist kein negativer Ausdruck, für mich jedenfalls nicht :D Nicht, dass sich hier jemand diffamiert fühlt)
The Nerd got struck by lightning and lost his memory.
The Nerd says I can definitley not code!

Code:
public interface SkilledOrNotInterface {
   
    String skillSetup();
       
}

//hier ist das Interface implementiert
public class CodingSkills implements SkilledOrNotInterface {

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

//hier ist das Interface ebenfalls implementiert
public class NoCodingSkills implements SkilledOrNotInterface {

    @Override
    public String skillSetup() {
        return "I can definitley not code!";
    }
}


//hier ist das Interface nicht implementiert, sondern es taucht als Instanzvariable auf
public class Worker {

    private String profession;
    private String name;
    private String tools;
   
    public void setProfession(String prof) { this.profession = prof; }
    public String getProfession() { return profession; }
   
    public void setName(String name) { this.name = name; }
    public String getName() { return name; }
   
    public void setTools(String tools) { this.tools = tools; }
    public String getTools () { return 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;
    }
}

public class Programmer extends Worker {

    public Programmer() {
        super();
        setProfession("Programmer");
        setTools("Computer");
        skilledOrNot = new CodingSkills();
    }
}

War das etwas verständlich?

Noch nicht so richtig ehrlich gesagt. Kannst du das einmal in zwei Sätzen auf meinen obigen Code übertragen?

Kommt darauf an, was dein Ziel ist. Wenn deine Klasse sich verhalten können soll wie das Interface es festlegt, dann muss sie es implementieren. Soll die Klasse nur eine Instanz davon speichern können, dann kann sie dieses als Instanzvariable haben und da kann es sinnvoll sein als Typ das Interface anzugeben, um flexibler zu sein.
Ok, damit nähere ich mich glaube ich dem "Problem" in meinem Kopf: Warum oder in welchen Fällen sollte ich nur eine Instanz des Interfaces brauchen anstatt jenes zu implementieren? Ich mein.. ich habe Interfaces doch aus dem Grund, damit ich sie implementieren kann und die Methoden dann in verschiedenen Klassen unterschiedlich überschreiben und nutzbar machen kann. Was bringt es mir, sie wie in meinem obigen Code beschrieben als Instanzvariable zu haben?

Vielleicht habe ich auch noch den genauen Ablauf dessen, was da im Strategy in meinem Fall passiert, nicht richtig durchdrungen und die Antwort darauf ist genau das:
Oder, um es anders zu formulieren: die Implementierung des Interface steht zum Zeitpunkt der Übersetzung des Quelltexts fest, eine Referenz auf eine Implementierung des Interface lässt sich dagegen zur Laufzeit ändern.

? Also der Effekt ist mir klar - ich übergebe ein SkilledOrNotSkilled und darüber ändere ich den Zustand des Programmers, da in Abhängigkeit davon CodingSkills or NoCodingSkills greift. Aber warum.. da stehe ich gerade etwas auf dem Schlauch.

Ich verwirre mich mal wieder maximal selbst. xD LG
 

osion

Bekanntes Mitglied
Hallo Leute,

ich brüte im Rahmen eines Kurses zum Software-Engineering über einem Buch, welches in einem Kapitel einige der GoF-Pattern vorstellt, z.B.
neben Observer auch Adapter, Fassade, Strategy, Abstrakt Factory, und viele weitere...

ich bin etwas erschrocken, wie sehr man das Programmieren in "richtigere" oder / gute "Lösungswege" einsortieren kann (was ja andere Lösungswege irgendwie erstmal entwertet).
Jedenfalls scheint mir zunächst vom ersten Lesen her das Erlernen der ganzen Pattern extrem schwierig, z.B. die alle erstmal überhaupt zu behalten und dann auch noch für mich umsetzbar zu machen. Bisher bin ich auch auf diese abstrakte, theoretische Art noch nicht an Pattern herangeführt worden, sondern nur sehr vereinzelt und dann ggf. über konkrete Aufgaben oder Hinweise von euch hier aus dem Forum. (also eigentlich kannte ich bisher "nur" Singleton, Observer, Factory)

Gehören diese ganzen anderen GoF-Pattern zum Standard-Werkzeug im Arbeitsalltag, also sitzt man dann da und denkt sich "ahh, hier nutze ich jetzt das Pattern xyz weil ... " und "macht das dann einfach"? Macht man das mit der Zeit oder muss ich das knüppelhart wie andere Grundlagen auch lernen, wie man ja auch z.B. lernen muss, was Variablen und Klassen sind etc. ?

Bin etwas erschrocken, was da alles noch lauert und wie sich ein etwaiger Erwartungshorizont an Entwickler noch verschieben kann...
Also meine Frage an Leute aus der Praxis: Wo, wie (oft) und wie bewusst begegnen euch diese ganzen GoF-Pattern im Berufsalltag?

Ich wünsche euch ein schönes Wochenende!
Antwort von chatGPT:
Hey! Keine Sorge, du musst nicht alle GoF-Pattern auf einmal lernen. Es ist wichtig, dass du dich mit ihnen auseinandersetzt und ein grundlegendes Verständnis davon hast, aber es ist nicht notwendig, dass du sie alle auswendig kennst oder in jedem Projekt anwendest. In der Praxis wirst du wahrscheinlich nur einige wenige dieser Muster immer wieder verwenden, und wenn du ein bestimmtes Muster brauchst, das du nicht kennst, kannst du immer noch nachschlagen oder jemanden um Hilfe bitten. Denke daran, dass es auch viele andere Muster gibt, die nicht zu den GoF-Pattern gehören und die du vielleicht auch lernen wirst. Es ist wichtig, dass du dich immer weiterbildest und deine Fähigkeiten als Softwareentwickler verbesserst, aber es gibt keine Notwendigkeit, alles auf einmal zu lernen. Ich hoffe, das hilft dir etwas!

Meine Antwort zur Ergänzung:
Es ist ein "learning by doing". Du wirst nicht alle Pattern brauchen und die, die du brauchst, wirst du mit der Zeit lernen. Es hängt auch stark davon ab, ob du mit einem Framework arbeitest, das dir die Struktur vorgibt, oder ob du selbst ein System planen und entwickeln musst. Generell sind die GoF-Pattern oder Teile davon weit verbreitet, zum Beispiel in Java.
 
Y

yfons123

Gast
dir werden die meisten pattern sowieso nichts bringen wenn sie schon fest in die sprache integriert sind, in c# wirst du kaum Builder sehen

genauso wie delegation wird anders in c# gehandhabt als wie damals weil es fest eingebaut ist
 

KonradN

Super-Moderator
Mitarbeiter
klar, warum sollte ich sprachen integrierte features hernehmen wenn es auch auf einem längeren weg geht
Ähm, kannst Du das bitte einmal näher erläutern?

Wenn die Sprache oder das Framework irgend ein Pattern nutzt an irgend einer Stelle bedeutet das doch nicht, dass man das Pattern nicht an anderer Stelle benutzen kann - alleine schon, weil es ja um das Grundverständnis geht und es daher Variationen geben kann.

Und es wäre mir neu, dass ein Sprachfeature ein Pattern komplett umsetzen / ersetzen könnte. Kannst Du das einmal im Detail erläutern?
 

LimDul

Top Contributor
Pattern sind Entwurfsmuster - keine Sprachfeatures. Die werden von manchen Sprachen besser und von manchen schlechter unterstützt.

Aber kein Sprach-Feature kann die komplett ersetzen. Einen Builder wird man auch mal selber schreiben, weil man Builder auch nicht nur für simple Datenklassen schreibt. Und natürlich wird man auch Delegates selber schreiben, unabhängig was die Sprache anbietet.

Man braucht sie vielleicht seltener - aber sie werden nicht ersetzt.
 

osion

Bekanntes Mitglied
Es ist wie bei einem Polier im Bau. Der Polier muss nicht selbst alles bauen, aber er sollte im Grundkonzept verstehen, wie die einzelnen Arbeiten im Grundgerüst ablaufen, um auf Probleme reagieren und gegebenenfalls selbst Anpassungen vornehmen oder bauen zu können.

Patern (Baupläne) sind keine Verpflichtungen, sondern Praktiken, die sich in Projekten bewährt haben. Es gibt neben den GOF auch andere Baupläne, die in bestimmten Bereichen weit verbreitet sind.

Die Java-Syntax ist nicht die einzige existierende, aber es gibt Features, die in vielen Sprachen vorkommen, weil sie sich bewährt haben und viele sie anwenden und kennen (als Vergleich). Ist nicht die gleiche Basis das Ziel von vordefinierten Pattern, welche alle verstehen und effizient sind?
 

temi

Top Contributor
Ok, damit nähere ich mich glaube ich dem "Problem" in meinem Kopf: Warum oder in welchen Fällen sollte ich nur eine Instanz des Interfaces brauchen anstatt jenes zu implementieren?
"Instanz des Interfaces" war schlecht von mir formuliert, da sich ein Interface nicht instantiieren lässt. Besser ist: "Instanz einer Klasse, die das Interface implementiert". Dies zur Richtigstellung.

Wenn du z. B. die Schnittstelle deiner Klasse möglichst flexibel haben möchtest, was nur ein Beispiel ist.
Java:
public void doSomething(ArrayList<MyType> list) {
 
}

//vs.

public void doSomething(Collection<MyType> list) {
 
}

Im ersten Fall kannst du als Parameter eine ArrayList<> übergeben. Im zweiten Fall gibt es schon mehr Möglichkeiten:
Das lässt sich noch "verbessern" mit:
Java:
public void doSomething(Iterable<MyType> list) {

}
Im letzten Fall kannst du dann natürlich nur noch mit den Methoden von Iterable<> zugreifen.
Java:
class Foo {
    // die Instanzvariable wird als List<> deklariert (Interface)
    // dadurch kann die tatsächliche Implementation später noch leicht
    // gewechselt werden, auf jeden Typen der List<> implementiert.
    private List<MyType> list = new ArrayList<>();
 
    public void doSomething(Iterable<MyType> list) {
        for (var item : list) {
            this.list.add(item);
        }
    }
}
 
Zuletzt bearbeitet:

Wuast

Bekanntes Mitglied
"Instanz des Interfaces" war schlecht von mir formuliert, da sich ein Interface nicht instantiieren lässt. Besser ist: "Instanz einer Klasse, die das Interface implementiert". Dies zur Richtigstellung.
direkt dazu: Habe ich das aber nicht getan; eine Instanz des Interfaces erzeugt und jenes somit zur Instanzvariable gemacht?
Aber die Richtigstellung macht es mir schon mal deutlicher, warum das dann so funktioniert wie es das tut.
Das finde ich nämlich ja auch bei anderen Patterns, wie z.B. dem Command Pattern. Und eigentlich geht es ja an der Stelle gar nicht mehr so sehr um die Patterns an sich, sondern um die Instanzen von Interfaces vs Interface implementieren ^^
 
Ähnliche Java Themen
  Titel Forum Antworten Datum
D was ist der vorteil vom Builder-design pattern? Java Basics - Anfänger-Themen 11
D Java Pattern mit X Ausgabe Stern Java Basics - Anfänger-Themen 4
J Methoden Observer-Pattern mit Consumer und accept( ) Java Basics - Anfänger-Themen 6
Dimax Erste Schritte Pattern.matcher,die Besonderheiten. Java Basics - Anfänger-Themen 12
N Best Practice Frage zum MVC-Pattern Java Basics - Anfänger-Themen 2
J Implementierung von Observer und Singleton-Pattern Java Basics - Anfänger-Themen 9
F Design pattern Java Basics - Anfänger-Themen 29
W RegEx Matcher + Pattern und Emails Java Basics - Anfänger-Themen 8
M Schlüsselworte Unterschied: String.matches und Pattern.compile Java Basics - Anfänger-Themen 2
C Best Practice JTable in MVC Pattern Java Basics - Anfänger-Themen 7
D Design Pattern Command Java Basics - Anfänger-Themen 3
Bregedur Methoden Matcher und Pattern bei sich wiederholenden Werten Java Basics - Anfänger-Themen 1
fLooojava MVC Pattern und Observer Pattern Java Basics - Anfänger-Themen 6
S Regex Pattern Java Basics - Anfänger-Themen 3
Z Pattern und Matcher substring zu String möglich? Java Basics - Anfänger-Themen 4
B Pattern für Email Liste Java Basics - Anfänger-Themen 3
J Builder Pattern implementieren Java Basics - Anfänger-Themen 3
Tarrew Proxy Design-Pattern Java Basics - Anfänger-Themen 1
M Methoden Pattern Matching Vokal Java Basics - Anfänger-Themen 2
agent47 Pattern split Java Basics - Anfänger-Themen 2
J MVC Pattern, mehrere Controller/Views/Models Java Basics - Anfänger-Themen 0
B Strategy Pattern - Rechner Java Basics - Anfänger-Themen 6
I Vertändnisfrage zu Prototype Pattern Java Basics - Anfänger-Themen 0
L Kompositum-Pattern Hilfe :O Java Basics - Anfänger-Themen 4
F eigenes Listener Pattern mit Interface Java Basics - Anfänger-Themen 1
S Je nach erhaltene Daten unterschiedlich reagieren (Design Pattern?) Java Basics - Anfänger-Themen 3
B Pattern Matching ohne Match-Methoden Java Basics - Anfänger-Themen 11
Furtano OOP Memento Pattern | übergabe einer Kopie des Arrays Java Basics - Anfänger-Themen 0
F Erste Schritte Pattern zum Zerlegen von selbstdefinierten Dateinamen Java Basics - Anfänger-Themen 7
M MVC + Strategy Pattern Ansatz (mit Code) Java Basics - Anfänger-Themen 5
A Design Pattern - Welche? Java Basics - Anfänger-Themen 33
Rudolf OOP Übungen zu Design Pattern in Java Java Basics - Anfänger-Themen 6
A Observer Pattern Problem Java Basics - Anfänger-Themen 15
J Interface Frage zu Interfces am Beispiel Observer Pattern Java Basics - Anfänger-Themen 8
S OOP Regex Pattern Java Basics - Anfänger-Themen 2
P Grundsatzfrage zu Decorator-Pattern Java Basics - Anfänger-Themen 6
L Pattern Matching Java Basics - Anfänger-Themen 3
L RegExp bzw Pattern in Java Java Basics - Anfänger-Themen 6
Helgon Observer Pattern - hasChanged() immer false Java Basics - Anfänger-Themen 10
R aktualisierung des View im MVC-Pattern Java Basics - Anfänger-Themen 5
M RegEx Pattern Matcher Java Basics - Anfänger-Themen 16
R Pattern bzw. Regex HTML-Code Java Basics - Anfänger-Themen 10
N Regexp Pattern & Matcher Problem Java Basics - Anfänger-Themen 4
I OOP Verständnisfrage zu Singelton Pattern Java Basics - Anfänger-Themen 21
R Welches Design pattern Java Basics - Anfänger-Themen 10
B static und Pattern matching Java Basics - Anfänger-Themen 22
T pattern klappt nicht so Java Basics - Anfänger-Themen 6
T Decorator Pattern Java Basics - Anfänger-Themen 7
A Pattern und Matcher Java Basics - Anfänger-Themen 9
T Frage zu Pattern/Matcher Java Basics - Anfänger-Themen 6
D Pattern in Midi-Sequencer Java Basics - Anfänger-Themen 2
V Frage zu Decorator-Pattern Java Basics - Anfänger-Themen 4
S OOP Factory Pattern Java Basics - Anfänger-Themen 2
C OOP Observer Pattern Java Basics - Anfänger-Themen 2
M Regex-Pattern Java Basics - Anfänger-Themen 2
Haubitze_Broese Pattern für Links in RSS-Reader Java Basics - Anfänger-Themen 6
Raidri Pattern liefert false Java Basics - Anfänger-Themen 9
megachucky regex-Problem ( mit den Klassen Matcher / Pattern) --> XML prüfen Java Basics - Anfänger-Themen 11
O useDelimiter / Muster im Parameter (Pattern) Java Basics - Anfänger-Themen 6
S Problem mit Pattern Java Basics - Anfänger-Themen 2
S Pattern.matches mit Ignore Case Java Basics - Anfänger-Themen 2
N in int array einen pattern(eine zahl) finden Java Basics - Anfänger-Themen 21
A Hilfe zu Pattern Java Basics - Anfänger-Themen 2
Y Pattern Java Basics - Anfänger-Themen 2
A Proxy Pattern implementieren Java Basics - Anfänger-Themen 2
N OOP MVC Pattern Java Basics - Anfänger-Themen 3
G Probleme mit Pattern und Aussagenlogik Java Basics - Anfänger-Themen 6
H Verständnis Strategy Pattern Java Basics - Anfänger-Themen 4
D regexp-pattern .. letzter schliff Java Basics - Anfänger-Themen 6
A ist das ein Singleton-Pattern? Java Basics - Anfänger-Themen 6
Z regexp/pattern für dateipfad Java Basics - Anfänger-Themen 5
A Factory Pattern Java Basics - Anfänger-Themen 2
D Objekte anlegen und Singleton Pattern Java Basics - Anfänger-Themen 21
O Erklärung für Pattern Java Basics - Anfänger-Themen 5
U Java Pattern Regex Java Basics - Anfänger-Themen 9
0 Probleme mit Pattern und Matcher Java Basics - Anfänger-Themen 5
K Observer Pattern notifyObservers Java Basics - Anfänger-Themen 9
S geeignetes Such Pattern Java Basics - Anfänger-Themen 6
J Zugriff mit Visitor Pattern auf eigen erstellte verk. Liste Java Basics - Anfänger-Themen 3
J Visitor Pattern Java Basics - Anfänger-Themen 4
W Observer-Pattern Java Basics - Anfänger-Themen 3
M Singleton Pattern Java Basics - Anfänger-Themen 35
J Singleton Pattern Java Basics - Anfänger-Themen 5
J Ant pattern Erklaerung Java Basics - Anfänger-Themen 4
G Aufbau MVC-Pattern Java Basics - Anfänger-Themen 6
M Pattern Matching Java Basics - Anfänger-Themen 2
S Singleton Pattern passend hierfür? Java Basics - Anfänger-Themen 60
M Factory Pattern Ansatz falsch? Java Basics - Anfänger-Themen 6
Y Hilfe bei Pattern-Regexp Java Basics - Anfänger-Themen 5
U pattern Java Basics - Anfänger-Themen 2
A Pattern.matches(); Java Basics - Anfänger-Themen 14
A Problem mit Obser-Pattern Java Basics - Anfänger-Themen 2
P pattern/match Java Basics - Anfänger-Themen 2
K Probleme mit RegEx (Pattern und Matcher) Java Basics - Anfänger-Themen 2
K Regex Pattern Java Basics - Anfänger-Themen 4
G Vorteile Reflection bezüglich MVC-Pattern Java Basics - Anfänger-Themen 9
F regex pattern problem Java Basics - Anfänger-Themen 4
S Regex Pattern Problem Java Basics - Anfänger-Themen 2
G Singleton Pattern Java Basics - Anfänger-Themen 7
F Pattern und Matcher Java Basics - Anfänger-Themen 4

Ähnliche Java Themen

Neue Themen


Oben