Welche Design Patterns sollte man kennen?

[Ululu]

Welche Patters verwendet ihr häufig?

[hustbaer]

was ich häufig verwende:

pimpl
decorator
abstract factory
adapter
composite
facade
observer

das sind zumindest mal die häufigsten.

was man kennen sollte: möglichst viel, sonst kennt man garantiert genau das nicht was man brauchen könnte

check dir auf jedenfall das gof buch ("design patterns", addison wesley)

[Bashar]

hustbaer: Iterator hast du mit Sicherheit nur vergessen.

Man sollte BTW Design Patterns nicht nur kennen, sondern auch erkennen, wann sie nicht angebracht sind.

[HumeSikkins]

hustbaer schrieb:

was ich häufig verwende:
pimpl

Das würde ich nicht als DP, sondern als Sprach-Idiom bezeichnen. Ein verwandtes DP wäre das Bridge (aka. Handle/Body) Pattern.

Man sollte BTW Design Patterns nicht nur kennen, sondern auch erkennen, wann sie nicht angebracht sind

Jup, sehe ich auch so. Deshalb sollte man meiner Meinung nach Bücher wie das GoF-Buch immer mit einem Buch wie z.B. "Refactoring to Patterns" kombinieren. Ansonsten fängt man schnell mal an jedes if zu einer Strategy-Hierarchie zu abstrahieren

[pattern-freak]

Ululu schrieb:

Welche Patters verwendet ihr häufig?

• Abstract Factory
• Builder
• Factory Method
• Prototype
• Singleton
• Adapter
• Bridge
• Composite
• Decorator
• Facade
• Flyweight
• Proxy
• Chain of Responsibility
• Command
• Interpreter
• Iterator
• Mediator
• Memento
• Observer
• State
• Strategy
• Template Method
• Visitor

[erzählmal]

pattern-freak schrieb:

Ululu schrieb:

Welche Patters verwendet ihr häufig?

• State

Was machst du den mit dem so häufig? Ich kann das fast nie brauchen. Oder hast du nur alles aufgezählt was dir einfällt?

[der echte *-freak]

erzählmal schrieb:

Oder hast du nur alles aufgezählt was dir einfällt?

das war ich nicht. ich verwende fast nie patterns.

[thordk]

ich benutz gern patterns. hat nen wunderbaren wiedererkennungswert für alle anderen, die mit meinem code arbeiten müssen.

[elise]

ich rutsche immer nur ausversehen in patterns rein.
nu, dann musses wohl...

[Helium]

HumeSikkins schrieb:

hustbaer schrieb:

was ich häufig verwende:
pimpl

Das würde ich nicht als DP, sondern als Sprach-Idiom bezeichnen.

Sind nicht alle Design-Pattern im Grunde Sprach-Idiome, auch wenn sie sich nicht auf eine einzelne, sondern auf eine Gruppe von Sprachen beziehen? Immer wenn eine Sprache keine Möglichkeit ein gewisses Muster wegzuabstrahieren, dann muss ich dieses Muster immer wieder ausprogrammieren. Wie man dieses notwendige Übel dann halbwegs sinnvoll umsetzt nennt sich Design Pattern.

Etliche der Standard-Gof-Pattern sind in abstrakteren Sprachen deswegen ziemlich sinnlos. Einige Pattern sind in sehr vielen Sprachen unsinn, z.B. das Command Pattern, einige sind für so gut wie alle interessant, z.B. das Interpreter Pattern.

[thordk]

die GoF pattern sind die essenz dessen, wie eine vielzahl an wiederkehrenden problemen gelöst werden kann. wenn man bedenkt, wie alt diese pattern schon sind, ist es kein wunder, dass sie in aktuellen sprachen nicht mehr implementiert werden müssen. aktuelle sprachen bieten bereits features, die diesen pattern nachempfunden sind.

[xindon]

Ein sehr sehr sehr sehr sehr schönes Buch ist auch Head First Design Patterns.

Kann ich nur empfehlen, mir hat's super gut gefallen.

[comment]

als ich das erste mal von "design patterns" gehört hab, hab ich gemerkt das ich einige davon schon lang unbewusst benutzt hab.

ich finde daher das man sowas nicht unbedingt lernen muss. bei passender gelegenheit kommt man selbst auf die gedanken dinge so zu machen wie es sinn macht.

[hustbaer]

comment schrieb:

als ich das erste mal von "design patterns" gehört hab, hab ich gemerkt das ich einige davon schon lang unbewusst benutzt hab.

ich finde daher das man sowas nicht unbedingt lernen muss. bei passender gelegenheit kommt man selbst auf die gedanken dinge so zu machen wie es sinn macht.

Also bis man alle die Patterns die z.B. im GoF Buch aufgelistet sind selbst "entdeckt" hat wird man ziemlich lange programmieren müssen. Dazu kommt dann noch dass man dann vielleicht die Patterns anwenden kann, aber nicht unbedingt auch deren Schwächen kennt. Praktisch sind auch die Listen verwandter Patterns, wenn man sich z.B. denkt "hier würde ich gerne X anwenden, geht aber nicht weil ...", dann kann man nachgucken ob nicht ein anderes Pattern hier abhilfe schafft.

Und natürlich ist es gut wenn man die Namen der wichtigsten Patterns kennt, sonst guckt man u.U. ganz schön doof (oder muss dauernd nachfragen) wenn jmd. einem erklärt wie irgendwas umgesetzt ist.
Namen wie "abstract factory" sind relativ einfach intuitiv zu verstehen, allerdings glaube ich nicht dass irgendjemand "visitor" richtig interpretiert wenn er den Namen nicht kennt.

[EXDW]

comment schrieb:

als ich das erste mal von "design patterns" gehört hab, hab ich gemerkt das ich einige davon schon lang unbewusst benutzt hab.

ging mir damals auch so, hatte schon immer eine bestimmte methode fuer einmal-klassen verwendet, bis ich das design patterns gelesen hab und so dachte "huch, das ist singleton, interessant, benutz ich schon lang" #gg

[thordk]

comment schrieb:

als ich das erste mal von "design patterns" gehört hab, hab ich gemerkt das ich einige davon schon lang unbewusst benutzt hab.

ich finde daher das man sowas nicht unbedingt lernen muss. bei passender gelegenheit kommt man selbst auf die gedanken dinge so zu machen wie es sinn macht.

bei design patterns gehts zwar zum einen darum, dass man schnell eine gute lösung für ein bestimmtes problem findet, zum anderen aber auch darum, dass andere wiedererkennen, was man gemacht hat. genau deshalb sollte man sich auch keine komplett eigenen namen ausdenken. eigenes prefix + pattern als suffix. so haben andere leser deines codes es wesentlich leichter, grosse einheiten als funktionalitätsblock zu erkennen. das spart gewaltig zeit bei der analyse

[Helium]

thordk schrieb:

die GoF pattern sind die essenz dessen, wie eine vielzahl an wiederkehrenden problemen gelöst werden kann. wenn man bedenkt, wie alt diese pattern schon sind, ist es kein wunder, dass sie in aktuellen sprachen nicht mehr implementiert werden müssen. aktuelle sprachen bieten bereits features, die diesen pattern nachempfunden sind.

Nur das es solche Sprachen schon laaaange vor dem Gof-Buch gab. Und es sind auch nicht Umsetzungen der Pattern, sondern allgemeinere Abstraktionsmechanismen, die die Pattern einfach überflüssig machen.

Stell dir vor du arbeitest in einem alten Basic oder Pascal oder was auch immer, und brauchst einen Stack für Integer. Also schreibst du dir einen, inklusive zugehöriger Standardfunktionen, wie push, pop, etc. Dann brauchst du einen Stack für Strings. Was machst du? Du schreibst nochmal einen Stack für Strings inklusiver zugehöriger Funktionen. Du hast zwar das Muster des Stacks erkannt, bist aber nicht in der Lage es wegzuabstrahieren.
Jetzt könnte ein Sprachdesigner merken, dass Leute ab und zu Stacks für verschiedene Typen brauchen und einen speziellen Typoperator in die Sprache einbauen. So wie es schon einen gibt um aus einem Typ ein Array dieses Typs zu erstellen könnte er also auch einen einbauen, der aus einem Typ einen Stack dieses Typs erstellt. Was aber wenn ich eine Queue brauche? Dann müsste ein witeres Sprachmittel eingebaut werden.
Das wäre die analogie zu einem Versuch ein spezielle Design Pattern mit einem dafür passenden Sprachkonstrukt zu ersetzen.

Jetzt stell dir aber vor du lernst eine Sprache mit parametrischer Polymorphie kennen und bist plötzlich selber in der Lage entsprechende Typoperatoren zu entwickeln. Du hast keinen speziellen mehr für Stacks etc. sondern kannst dir selbst genau die bauen, die du brauchst für Stacks, Queues, ... was auch immer. Ein allgemeineres Abstraktionsmittel (hier parametrische Polymorphie) hat dir ermöglicht dein immer weiderkehrendes Muster des Stacks wegzuabstrahieren, ohne ein spezielle Stack-Sprachmittel zur Verfügung zu stellen.

Genau so sieht es auch bei den üblichen Design Pattern aus. Statt ein spezielles Command-Pattern-Sprachmittel einzubauen und ein spezielles Strategy-Pattern-Sprachmittel einzubauen, etc. kann man mit einem allgemeineren Abstraktionsmittel diese beiden und noch viel mehr Dinge umsetzten.

[antwort]

Helium schrieb:

HumeSikkins schrieb:

hustbaer schrieb:

was ich häufig verwende:
pimpl

Das würde ich nicht als DP, sondern als Sprach-Idiom bezeichnen.

Sind nicht alle Design-Pattern im Grunde Sprach-Idiome, auch wenn sie sich nicht auf eine einzelne, sondern auf eine Gruppe von Sprachen beziehen? Immer wenn eine Sprache keine Möglichkeit ein gewisses Muster wegzuabstrahieren, dann muss ich dieses Muster immer wieder ausprogrammieren. Wie man dieses notwendige Übel dann halbwegs sinnvoll umsetzt nennt sich Design Pattern.

Nein, es sind Design Patters. Dir ist der Unterschied zwischen Design und Implementierungsdetail bekannt?

[hustbaer]

@dumme antwort: viele der sog. Design Patterns sind aber Implementierungs-Details. Ist dir der Unterschied zwischen Architektur und Design bekannt?

[antwort]

hustbaer schrieb:

@dumme antwort: viele der sog. Design Patterns sind aber Implementierungs-Details.

Also irgendwann muss man das ganze implementieren. Ob ich z.B. ein Observerpattern mit Interface/Klassen und virtuellen Methoden, Strukturen und Funktionpointern oder einfach mit ein Sprachfeature umsetze ist ein Detail. Deswegen ändert sich nicht das Design.
Wenn du jetzt von sogenannten Design Pattern redest, weiß ich nicht was du meinst, aber es sind wohl dann keine richtigen.

Ist dir der Unterschied zwischen Architektur und Design bekannt?

Ja und nein und vorallem was hat das damit zu tun?