Was ist ein Anti-Muster?

Ich studiere Muster und Anti-Muster. Ich habe eine klare Vorstellung von Mustern, aber ich bekomme keine Anti-Muster. Definitionen aus dem Internet und Wikipedia verwirren mich sehr.

Kann mir jemand in einfachen Worten erklären, was ein Anti-Muster ist? Was ist der Zweck? Was machen Sie? Ist es eine schlechte oder eine gute Sache?

Anti-Patterns sind bestimmte Muster in der Softwareentwicklung, die als schlechte Programmierpraktiken gelten.

Im Gegensatz zu Entwurfsmustern, bei denen es sich um gängige Ansätze für häufig formulierte Probleme handelt, die formalisiert wurden und allgemein als gute Entwicklungspraxis angesehen werden, sind Anti-Muster das Gegenteil und unerwünscht.

Bei der objektorientierten Programmierung besteht die Idee beispielsweise darin, die Software in kleine Teile zu unterteilen, die als Objekte bezeichnet werden. Ein Anti-Muster in der objektorientierten Programmierung ist ein Gott-Objekt, das viele Funktionen ausführt, die besser in verschiedene Objekte unterteilt werden könnten.

Beispielsweise:

class GodObject {
    function PerformInitialization() {}
    function ReadFromFile() {}
    function WriteToFile() {}
    function DisplayToScreen() {}
    function PerformCalculation() {}
    function ValidateInput() {}
    // and so on... //
}

Das obige Beispiel hat ein Objekt, das alles macht . Bei der objektorientierten Programmierung wäre es vorzuziehen, genau definierte Verantwortlichkeiten für verschiedene Objekte zu haben, um den Code weniger gekoppelt und letztendlich wartbarer zu halten:

class FileInputOutput {
    function ReadFromFile() {}
    function WriteToFile() {}
}

class UserInputOutput {
    function DisplayToScreen() {}
    function ValidateInput() {}
}

class Logic {
    function PerformInitialization() {}
    function PerformCalculation() {}
}

Unter dem Strich gibt es gute Möglichkeiten, Software mit häufig verwendeten Mustern ( Entwurfsmustern ) zu entwickeln, aber es gibt auch Möglichkeiten, Software zu entwickeln und zu implementieren, die zu Problemen führen können. Muster, die als schlechte Softwareentwicklungspraktiken gelten, sind Anti-Muster.

Immer wenn ich von Anti-Mustern höre, erinnere ich mich an einen anderen Begriff, nämlich. Designgeruch.

"Designgerüche sind bestimmte Strukturen im Design, die auf eine Verletzung grundlegender Designprinzipien hinweisen und sich negativ auf die Designqualität auswirken." (Aus "Refactoring für Software-Designgerüche: Verwaltung technischer Schulden")

Es gibt viele Designgerüche, die aufgrund von Verstößen gegen Designprinzipien klassifiziert wurden:

Abstraktion riecht

Fehlende Abstraktion: Dieser Geruch entsteht, wenn Datenklumpen oder codierte Zeichenfolgen verwendet werden, anstatt eine Klasse oder eine Schnittstelle zu erstellen.

Imperative Abstraktion: Dieser Geruch entsteht, wenn eine Operation in eine Klasse umgewandelt wird.

Unvollständige Abstraktion: Dieser Geruch entsteht, wenn eine Abstraktion komplementäre oder miteinander verbundene Methoden nicht vollständig unterstützt.

Vielfältige Abstraktion: Dieser Geruch entsteht, wenn einer Abstraktion mehr als eine Verantwortung zugewiesen ist.

Unnötige Abstraktion: Dieser Geruch tritt auf, wenn eine Abstraktion, die tatsächlich nicht benötigt wird (und daher hätte vermieden werden können), in ein Software-Design eingeführt wird.

Nicht genutzte Abstraktion: Dieser Geruch entsteht, wenn eine Abstraktion nicht verwendet wird (entweder nicht direkt verwendet oder nicht erreichbar).

Doppelte Abstraktion: Dieser Geruch entsteht, wenn zwei oder mehr Abstraktionen identische Namen oder identische Implementierungen oder beides haben.

Verkapselung riecht

Mangelhafte Kapselung: Dieser Geruch tritt auf, wenn die deklarierte Zugänglichkeit eines oder mehrerer Mitglieder einer Abstraktion zulässiger ist als tatsächlich erforderlich.

Leaky Encapsulation: Dieser Geruch entsteht, wenn eine Abstraktion Implementierungsdetails über ihre öffentliche Schnittstelle „aufdeckt“ oder „verliert“.

Fehlende Kapselung: Dieser Geruch tritt auf, wenn Implementierungsvariationen nicht in einer Abstraktion oder Hierarchie gekapselt sind.

Nicht ausgenutzte Kapselung: Dieser Geruch entsteht, wenn Client-Code explizite Typprüfungen verwendet (unter Verwendung verketteter if-else- oder switch-Anweisungen, die nach dem Typ des Objekts suchen ), anstatt die Variation der bereits in einer Hierarchie gekapselten Typen auszunutzen.

Modularisierung riecht

Defekte Modularisierung: Dieser Geruch entsteht, wenn Daten und / oder Methoden, die idealerweise in einer einzigen Abstraktion lokalisiert sein sollten, getrennt und auf mehrere Abstraktionen verteilt werden.

Unzureichende Modularisierung: Dieser Geruch entsteht, wenn eine Abstraktion existiert, die nicht vollständig zerlegt wurde, und eine weitere Zerlegung ihre Größe, Implementierungskomplexität oder beides verringern kann.

Zyklisch abhängige Modularisierung: Dieser Geruch entsteht, wenn zwei oder mehr Abstraktionen direkt oder indirekt voneinander abhängen (wodurch eine enge Kopplung zwischen den Abstraktionen entsteht).

Hub-ähnliche Modularisierung: Dieser Geruch entsteht, wenn eine Abstraktion Abhängigkeiten (sowohl eingehende als auch ausgehende) von einer großen Anzahl anderer Abstraktionen aufweist.

Hierarchie riecht

Fehlende Hierarchie: Dieser Geruch entsteht, wenn ein Codesegment bedingte Logik verwendet (normalerweise in Verbindung mit „markierten Typen“), um Abweichungen im Verhalten explizit zu verwalten, bei denen eine Hierarchie hätte erstellt und zur Kapselung dieser Abweichungen verwendet werden können.

Unnötige Hierarchie: Dieser Geruch entsteht, wenn die gesamte Vererbungshierarchie nicht erforderlich ist, was darauf hinweist, dass die Vererbung für den jeweiligen Entwurfskontext unnötig angewendet wurde.

Nicht faktorisierte Hierarchie: Dieser Geruch entsteht, wenn zwischen Typen in einer Hierarchie unnötige Duplikate auftreten.

Breite Hierarchie: Dieser Geruch entsteht, wenn eine Vererbungshierarchie „zu“ breit ist, was darauf hinweist, dass möglicherweise Zwischentypen fehlen.

Spekulative Hierarchie: Dieser Geruch entsteht, wenn ein oder mehrere Typen in einer Hierarchie spekulativ bereitgestellt werden (dh basierend auf imaginären Bedürfnissen und nicht auf realen Anforderungen).

Tiefe Hierarchie: Dieser Geruch entsteht, wenn eine Vererbungshierarchie „übermäßig“ tief ist.

Rebellische Hierarchie: Dieser Geruch entsteht, wenn ein Subtyp die von seinen Supertypen bereitgestellten Methoden ablehnt.

Unterbrochene Hierarchie: Dieser Geruch entsteht, wenn ein Supertyp und sein Subtyp konzeptionell keine „IS-A“ -Beziehung teilen, was zu einer unterbrochenen Substituierbarkeit führt.

Multipath-Hierarchie: Dieser Geruch entsteht, wenn ein Subtyp sowohl direkt als auch indirekt von einem Supertyp erbt, was zu unnötigen Vererbungspfaden in der Hierarchie führt.

Zyklische Hierarchie: Dieser Geruch entsteht, wenn ein Supertyp in einer Hierarchie von einem seiner Subtypen abhängt.

Die obige Definition und Klassifizierung wird unter "Refactoring für Software-Design-Gerüche: Verwaltung technischer Schulden " beschrieben. Weitere relevante Ressourcen finden Sie hier .

Ein Muster ist eine Idee, wie ein Problem einer Klasse gelöst werden kann. Ein Anti-Pattern ist eine Idee, wie man es nicht lösen kann, da die Implementierung dieser Idee zu einem schlechten Design führen würde.

Ein Beispiel: Ein "Muster" wäre die Verwendung einer Funktion zur Wiederverwendung von Code, ein "Anti-Muster" wäre die Verwendung von Copy-Paste für dasselbe. Beide lösen das gleiche Problem, aber die Verwendung einer Funktion führt normalerweise zu besser lesbarem und wartbarem Code als das Kopieren und Einfügen.

Ein Anti-Pattern ist ein Weg, ein Problem nicht zu lösen. Aber es steckt noch mehr dahinter: Es ist auch ein Weg, der häufig bei Versuchen gesehen wird, das Problem zu lösen.

Wenn Sie AntiPatterns wirklich studieren möchten, lesen Sie das Buch AntiPatterns (ISBN-13: 978-0471197133).

Darin definieren sie "Ein Anti-Muster ist eine literarische Form, die eine häufig vorkommende Lösung eines Problems beschreibt, das entschieden negative Folgen hat."

Wenn es sich also um eine schlechte, aber keine übliche Programmierpraxis handelt, die auf eine Anwendung, ein Unternehmen oder einen Programmierer beschränkt ist, entspricht sie nicht dem Teil "Muster" der AntiPattern-Definition.

Ein üblicher Weg, um ein Chaos zu machen. Wie zum Beispiel die God / Kitchensink-Klasse (macht alles).

Interessanterweise kann eine bestimmte Art der Problemlösung sowohl ein Muster als auch ein Anti-Muster sein. Singleton ist das beste Beispiel dafür. Es wird in beiden Literatursätzen erscheinen.

Ein Anti-Muster ist die Ergänzung eines Entwurfsmusters . Ein Anti-Pattern ist eine Vorlagenlösung, die Sie in einer bestimmten Situation nicht verwenden sollten.

Genau wie bei einem Entwurfsmuster ist auch ein Anti-Muster eine Vorlage und eine wiederholbare Methode zur Lösung eines bestimmten Problems, jedoch auf nicht optimale und ineffektive Weise.

Heutzutage verwenden Softwareentwickler und -praktiker die Begriffe „Anti-Pattern“ und „Geruch“ häufig synonym. Sie sind jedoch konzeptionell nicht gleich. Der Wikipedia-Eintrag von Anti-Pattern besagt, dass sich ein Anti-Pattern durch mindestens zwei Faktoren von einer schlechten Praxis oder einer schlechten Idee unterscheidet. Ein Anti-Muster ist

"Ein häufig verwendeter Prozess, eine häufig verwendete Struktur oder ein häufig verwendetes Aktionsmuster, das, obwohl es zunächst als angemessene und wirksame Antwort auf ein Problem erscheint, in der Regel mehr schlimme Folgen als vorteilhafte Ergebnisse hat."

Es zeigt deutlich, dass ein Anti-Muster in der Überzeugung gewählt wird, dass es eine gute Lösung (als Muster) für das vorgestellte Problem ist; Es bringt jedoch mehr Verbindlichkeiten als Vorteile. Andererseits ist ein Geruch einfach eine schlechte Praxis, die sich negativ auf die Qualität eines Softwaresystems auswirkt. Zum Beispiel ist Singleton ein Anti-Pattern und God Class (oder Insufficient Modularization) ist ein Designgeruch.

Anti-Muster sind übliche Methoden, mit denen Menschen dazu neigen, falsch oder zumindest nicht so gut zu programmieren.

Jedes Entwurfsmuster, das der gegebenen Softwareentwicklungsumgebung mehr schadet als nützt, wird als Anti-Muster betrachtet.

Einige Anti-Muster sind offensichtlich, andere nicht. Zum Beispiel Singleton, obwohl viele es für ein gutes altes Designmuster halten, aber es gibt andere, die dies nicht tun.

Sie können die Frage überprüfen, was an Singletons so schlecht ist. um die unterschiedlichen Meinungen dazu besser zu verstehen.

Wie im Algorithmus können Sie die Lösung mit Brute Force erreichen, aber Sie müssen viel bezahlen, wenn die Situation komplex wird.