Design-patterns zu vermeiden

Viele Menschen scheinen zu vereinbaren, dass das Singleton-Muster hat einige Nachteile, und einige vermuten sogar, dass die Vermeidung der Muster vollständig. Es gibt eine ausgezeichnete Diskussion hier. Bitte richten Sie alle Kommentare über das Singleton-Muster auf diese Frage.

Meine Frage: gibt es weitere design-patterns, die vermieden werden sollten oder verwendet werden, mit großer Sorgfalt?

InformationsquelleAutor der Frage Brian Rasmussen | 2009-01-16

  1. 141

    Muster sind Komplex

    Alle design-Muster sollte mit Vorsicht verwendet werden. Meiner Meinung nach sollten Sie umgestalten in Richtung Musterwenn es einen gültigen Grund, so zu tun, statt mit der Umsetzung eines Muster sofort. Das Allgemeine problem bei der Verwendung von mustern ist, dass Sie die Komplexität. Die übermäßige Verwendung von mustern macht eine bestimmte Anwendung oder ein system, umständlich zu weiter zu entwickeln und zu pflegen.

    Meisten der Zeit, gibt es eine einfache Lösung, und Sie brauchen sich nicht zu bewerben, keine spezifischen Muster. Eine gute Faustregel ist, um ein Muster verwenden, wenn code-Stücken, die dazu neigen, oder ersetzt werden, müssen oft ausgewechselt werden und bereit sein, auf die Einschränkung von komplexen code, wenn Sie mit einem Muster.

    Denken Sie daran, dass Ihr Ziel sollte sein, die Einfachheit und verwenden ein Muster, wenn Sie sehen, eine praktische Notwendigkeit zur Veränderung in Ihrem code.

    Grundsätze über die Muster

    Kann es scheinen, wie ein strittiger zum Muster, wenn Sie offensichtlich führen zu over-engineered und komplexe Lösungen. Aber stattdessen ist es viel interessanter für einen Programmierer zu Lesen, auf design-Techniken und Prinzipiendie die Grundlage für die meisten der Muster. In der Tat eines meiner Lieblings-Bücher über "design patterns", betont dieser durch das wiederholen, was Prinzipien sind anwendbar auf die Muster in Frage. Sie sind einfach genug, um nützlich zu sein, als Muster in Bezug auf die Relevanz. Einige der Prinzipien sind allgemein genug, um umfassen mehr als die objektorientierte Programmierung (OOP), wie Liskov-Substitution-Prinzipso lange wie Sie können, bauen die Module des Codes.

    Gibt es eine Vielzahl von design-Prinzipien, aber diejenigen, beschrieben in der erstes Kapitel von der GoF-Buch sind sehr nützlich, um mit zu beginnen.

    • Programm einer 'Schnittstelle', nicht eine 'Umsetzung'. (Gang of Four 1995:18)
    • Zugunsten 'Objekt-Komposition' über 'Vererbung'. (Gang of Four 1995:20)

    Lassen Sie diese Senke in auf Sie für eine Weile. Es sollte angemerkt werden, dass beim GoF war geschrieben ein Schnittstelle etwas bedeutet, ist eine Abstraktion (und das heißt auch super-Klassen), nicht zu verwechseln mit dem interface als Typ in Java oder C#. Das zweite Prinzip kommt aus den beobachteten übernutzung der Vererbung, die ist leider heute immer noch üblich ist.

    Von dort können Sie Lesen, auf SOLID Prinzipiendie bekannt gemacht wurde von Robert Cecil Martin (aka. Onkel Bob). Scott Hanselman interviewt Onkel Bob in einem podcast über diese Grundsätze:

    • SSingle Responsibility Prinzip
    • OStift-Geschlossen-Prinzip
    • Liskov substitutionsprinzip
    • Ichinterface Segregation Prinzip
    • Dependency Inversion Prinzip

    Diese Prinzipien sind ein guter Anfang, zum Lesen und diskutieren mit Ihren Kollegen. Sie können feststellen, dass die Grundsätze verweben sich miteinander und mit anderen Prozessen wie Trennung der Anliegen und dependency injection. Nach TDD für eine Weile, Sie kann auch finden, dass diese Grundsätze kommen natürlich in der Praxis, wie Sie benötigen, um Ihnen zu Folgen, zu einem gewissen Grad, um zu erstellen isoliert und wiederholbare unit-tests.

    InformationsquelleAutor der Antwort

  2. 21

    Dem einen, dass die Autoren von Design-Patterns, die sich selbst am meisten beunruhigt, war die "Visitor" - pattern.

    Es ist ein "notwendiges übel" - aber das ist oft mehr verwendet, und die Notwendigkeit, Sie Häufig zeigt sich eine weitere fundamentale Fehler in Ihrem design.

    Ein alternativer name für das "Visitor" - pattern ist "Multi-dispatch", weil das Besucher-Muster ist das, was Sie end up mit, wenn Sie möchten, verwenden Sie einen single-Typ dispatch OO-Sprache zu wählen, den code zu verwenden, basierend auf der Art der von zwei (oder mehr) verschiedene Objekte.

    Das klassische Beispiel ist, dass Sie die Kreuzung zwischen beiden Formen, aber es gibt einen noch einfacheren Fall, die oft übersehen wird: vergleicht man die Gleichheit zweier heterogener Objekte.

    Sowieso, oft Sie am Ende mit etwas wie dieses:

    interface IShape
{
    double intersectWith(Triangle t);
    double intersectWith(Rectangle r);
    double intersectWith(Circle c);
}

    Das problem mit diesem ist, dass Sie miteinander gekoppelt alle Ihre Implementierungen von "IShape". Sie haben angedeutet, dass, Wann immer Sie möchten fügen Sie eine neue Form der Hierarchie, Sie wird sich ändern müssen alle anderen "Form" - Implementierungen zu.

    Manchmal, das ist das richtige minimale design - aber denken, es durch. Hat Ihr design wirklich Mandat, die Sie benötigen, zu versenden auf zwei Arten? Sind Sie bereit, zu schreiben, jeder der kombinatorischen explosion von multi-Methoden?

    Oft, durch die Einführung ein anderes Konzept, Sie können reduzieren die Anzahl der Kombinationen ist, dass Sie tatsächlich gehen zu müssen, zu schreiben:

    interface IShape
{
    Area getArea();
}

class Area
{
    public double intersectWith(Area otherArea);
    ...
}

    Natürlich, es kommt darauf an - manchmal Sie wirklich brauchen, um code zu schreiben, um alle diese verschiedenen Fällen, aber es lohnt sich anzuhalten und ein denken, bevor Sie den Sprung Wagen und mit Besucher. Es könnte sparen Sie eine Menge Schmerz später.

    InformationsquelleAutor der Antwort Paul Hollingsworth

  3. 16

    Singleton - Klasse mit singleton-X hat eine Abhängigkeit, die schwer zu sehen und schwer zu isolieren, zum testen.

    Sind Sie sehr Häufig verwendet, weil Sie bequem und einfach zu verstehen, aber Sie können wirklich erschweren das testen.

    Sehen Singletons sind Pathologische Lügner.

    InformationsquelleAutor der Antwort orip

  4. 14

    Glaube ich, dass die Template Methode-Muster im Allgemeinen ist ein sehr gefährliches Muster.

    • Eine Menge Zeit verbraucht er Ihre Vererbungshierarchie für "den falschen Gründen".
    • Basis-Klassen haben eine Tendenz, übersät mit allen Arten von unerelated code.
    • Es zwingt Sie dazu, lock-down-Konstruktion, die oft schon früh in den Entwicklungsprozess. (Vorzeitiger Verschluss nach unten in eine Menge von Fällen)
    • Ändern Sie diese zu einem späteren Zeitpunkt wird nur härter und härter.

    InformationsquelleAutor der Antwort krosenvold

  5. 9

    Ich glaube nicht, dass Sie sollten es vermeiden, Design Patterns (DP), und ich glaube nicht, sollten Sie sich zwingen, zu verwenden DPs bei der Planung Ihrer Architektur. Wir sollten nur DPs, wenn Sie Natürliche entstehen von unserer Planung.

    Definieren wir von Anfang an, dass wir wollen, zu einem gegebenen DP, viele unserer zukünftigen design-Entscheidungen werden Einfluss durch die Wahl, ohne Garantie, dass die DP, die wir wählten ist geeignet für unsere Bedürfnisse.

    Eine Sache, die wir auch nicht tun sollten behandeln Sie eine DP als eine unveränderliche Entität, die wir anpassen sollten, das Muster auf unsere Bedürfnisse.

    So, sumarizing, ich glaube nicht, dass wir sollten vermeiden, DPs, sollten wir Sie umarmen, wenn Sie bereits Gestalt an in unserer Architektur.

    InformationsquelleAutor der Antwort Megacan

  6. 7

    Denke ich, dass Active Record ist eine etwas abgedroschene Muster, das fördert die Vermischung der Geschäftslogik mit der Persistenz-code. Es nicht machen einen sehr guten job zu verstecken, die storage-Implementierung von der Modell-Ebene und Krawatten, die Modelle in einer Datenbank. Es gibt genügend alternativen (beschrieben in PoEAA) wie Table Data Gateway, Row Data Gateway-und Daten-Mapper, die bieten oft eine bessere Lösung, und sicherlich helfen, um eine bessere Abstraktion zu Speicher. Auch dein Modell sollte nicht müssen werden in einer Datenbank gespeichert, was die Speicherung als XML-oder den Zugriff auf diese mittels web-services? Wie einfach wäre es zu ändern, die Lagerhaltung Ihrer Modelle?

    Sagte, Active Record ist nicht immer schlecht und ist ideal für einfachere Anwendungen, wo die anderen Optionen wäre übertrieben.

    InformationsquelleAutor der Antwort Tim Wardle

  7. 7

    Es ist einfach ... zu vermeiden, Design-Patterns, die nicht klar Ihnen oder diejenigen, die Sie fühlen sich nicht wohl in.

    Einige zu nennen ...

    gibt es einige unpraktisch Musterwie z.B.:

    • Interpreter
    • Flyweight

    gibt es auch einige schwerer zu fassenwie z.B.:

    • Abstract Factory - Volle abstrakte-Fabrik-Muster mit den Familien der erstellten Objekte ist nicht so einfach wie es zu sein scheint
    • Bridge - Können zu Abstrakt, wenn Abstraktion und Implementierung unterteilt sind, um Teilbäume, aber sehr brauchbare Muster in einigen Fällen
    • Visitor - Double dispatch Mechanismus verstehen, ist wirklich ein MUSS

    und es gibt einige Muster, die Blick sehr einfachaber sind nicht so klar Wahl aus verschiedenen Gründen in Bezug auf Ihre Prinzipien oder Umsetzung:

    • Singleton - nicht wirklich Total schlecht-Muster, einfach ZU overused (oft dort, wo es nicht geeignet ist)
    • Observer - tolles Muster ... einfach nur der code dadurch sehr viel schwieriger zu Lesen und zu Debuggen
    • Prototype - trades compiler-Prüfungen für die Dynamik (das kann gut oder schlecht sein ... hängt)
    • Chain of responsibility - oft nur erzwungen/künstlich eingeschoben design

    Für diejenigen, die "unpraktisch" sind, sollte man wirklich darüber nachdenken, bevor Sie Sie verwenden, denn es ist in der Regel elegantere Lösung irgendwo.

    Für die "schwer zu greifen" ... Sie sind wirklich eine große Hilfe, wenn Sie an geeigneten stellen und wenn Sie gut umgesetzt ... aber Sie sind der Alptraum, wenn Sie falsch benutzt wird.

    Nun, was kommt als Nächstes ...

    InformationsquelleAutor der Antwort Thetam

  8. 5

    Ich hoffe, dass ich nicht geschlagen werde zu viel für diese. Christer Ericsson hat zwei Artikel geschrieben (einzwei) auf das Thema design patterns in seine Echtzeit-Kollisionserkennung blog. Sein Ton ist ziemlich hart, und vielleicht ein wenig provokativ, aber der Mann versteht sein Handwerk, so würde ich das nicht abtun, es als Raserei eines wahnsinnigen.

    InformationsquelleAutor der Antwort falstro

  9. 5

    Einige sagen, dass service locator ist ein anti-pattern.

    InformationsquelleAutor der Antwort Arnis Lapsa

  10. 2

    Ich glaube das observer-Muster hat eine Menge zu verantworten, es funktioniert in sehr Allgemeinen Fällen, sondern als Systeme komplexer werden, wird es ein Alptraum, benötigen OnBefore(), OnAfter (Benachrichtigungen), und oft Entsendung von asynchronen Aufgaben zu vermeiden, re-entrancy. Eine viel bessere Lösung zu entwickeln, die ein automatisches system, Analyse der Abhängigkeiten, die Instrumente alle objektzugriffe (mit lese-Barrieren) bei Berechnungen und erstellt automatisch eine Kante im abhängigkeitsgraphen.

    InformationsquelleAutor der Antwort Jesse Pepper

  11. 2

    Ergänzung zu Spoike post Refactoring to Patterns ist gut zu Lesen.

    InformationsquelleAutor der Antwort Adeel Ansari

  12. 0

    Iterator ist eine weitere GoF-Muster zu vermeiden, oder zumindest verwenden Sie es nur, wenn keine alternativen zur Verfügung stehen.

    Alternativen sind:

    1. for-each-Schleife. Diese Konstruktion ist in den meisten mainstream-Sprachen und kann verwendet werden, um zu vermeiden, Iteratoren in der Mehrheit der Fälle.

    2. Selektoren à-la-LINQ oder jQuery. Sie sollte verwendet werden, wenn für jede nicht geeignet ist, da nicht alle Objekte vom container verarbeitet werden soll. Im Gegensatz zu Iteratoren, Selektoren erlauben, sich zu manifestieren in einer Stelle, welche Art von Objekten bearbeitet werden.

    InformationsquelleAutor der Antwort Volodymyr Frolov

Schreibe einen Kommentar