Co to jest anty-wzór?

Studiuję wzory i anty-wzory. Mam jasne pojęcie o wzorach, ale nie dostaję anty-wzorów. Definicje z internetu i Wikipedii bardzo mnie mylą.

Czy ktoś może mi wyjaśnić prostymi słowami, czym jest anty-wzór? Co jest celem? Co oni robią? Czy to zła czy dobra rzecz?

Anty-wzorce to pewne wzorce w rozwoju oprogramowania, które są uważane za złe praktyki programistyczne.

W przeciwieństwie do wzorców projektowych, które są powszechnym podejściem do typowych problemów, które zostały sformalizowane i są ogólnie uważane za dobrą praktykę rozwojową, anty-wzorce są odwrotne i są niepożądane.

Na przykład w programowaniu obiektowym chodzi o podzielenie oprogramowania na małe części zwane obiektami. Anty-wzorzec w programowaniu obiektowym jest obiektem Boga, który wykonuje wiele funkcji, które lepiej byłoby podzielić na różne obiekty.

Na przykład:

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

Powyższy przykład ma obiekt, który robi wszystko . W programowaniu obiektowym lepiej byłoby mieć dobrze określone obowiązki dla różnych obiektów, aby kod był mniej sprzężony, a ostatecznie łatwiejszy w utrzymaniu:

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

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

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

Najważniejsze jest to, że istnieją dobre sposoby tworzenia oprogramowania z powszechnie używanymi wzorcami (wzorce projektowe ), ale są też sposoby opracowywania i wdrażania oprogramowania, które mogą prowadzić do problemów. Wzorce uważane za złe praktyki opracowywania oprogramowania są anty-wzorce.

Ilekroć słyszę o anty-wzorach, przypominam sobie inny termin mianem. Zapach projektowy.

„Zapachy projektowe są pewnymi strukturami w projekcie, które wskazują na naruszenie podstawowych zasad projektowania i negatywnie wpływają na jakość projektu” (z „Refaktoryzacji zapachów związanych z projektowaniem oprogramowania: zarządzanie długiem technicznym”)

Istnieje wiele zapachów projektowych sklasyfikowanych na podstawie naruszających zasady projektowania:

Abstrakcja pachnie

Brakująca abstrakcja: ten zapach powstaje, gdy zamiast tworzenia klasy lub interfejsu używane są skupiska danych lub zakodowane ciągi.

Imperatywna abstrakcja: ten zapach powstaje, gdy operacja zamienia się w klasę.

Niekompletna abstrakcja: ten zapach powstaje, gdy abstrakcja nie obsługuje całkowicie metod komplementarnych lub powiązanych.

Wielowymiarowa abstrakcja: ten zapach powstaje, gdy abstrakcja ma przypisaną więcej niż jedną odpowiedzialność.

Niepotrzebna abstrakcja: ten zapach pojawia się, gdy abstrakcja, która faktycznie nie jest potrzebna (a zatem można jej uniknąć) zostaje wprowadzona do projektu oprogramowania.

Niewykorzystana abstrakcja: ten zapach powstaje, gdy abstrakcja pozostaje nieużywana (nie jest używana bezpośrednio lub nie jest osiągalna).

Duplikat abstrakcji: Ten zapach powstaje, gdy dwie lub więcej abstrakcji ma identyczne nazwy lub identyczną implementację lub oba.

Kapsułka pachnie

Deficient Encapsulation: Ten zapach pojawia się, gdy deklarowana dostępność jednego lub więcej członków abstrakcji jest bardziej dopuszczalna niż faktycznie wymagana.

Przeciekająca enkapsulacja: Ten zapach powstaje, gdy abstrakcja „ujawnia” lub „przecieka” szczegóły implementacji za pośrednictwem publicznego interfejsu.

Brak enkapsulacji: ten zapach występuje, gdy warianty implementacji nie są enkapsulowane w ramach abstrakcji lub hierarchii.

Niewykorzystana enkapsulacja: Ten zapach powstaje, gdy kod klienta używa jawnych kontroli typu (przy użyciu łańcuchowych instrukcji if-else lub switch, które sprawdzają typ obiektu), zamiast wykorzystywać odmianę typów już zawartych w hierarchii.

Modularyzacja pachnie

Zepsuta modularyzacja: ten zapach powstaje, gdy dane i / lub metody, które najlepiej powinny być zlokalizowane w pojedynczej abstrakcji, są oddzielone i rozłożone na wiele abstrakcji.

Niewystarczająca modularyzacja: ten zapach powstaje, gdy istnieje abstrakcja, która nie została całkowicie rozłożona, a dalszy rozkład może zmniejszyć jej rozmiar, złożoność implementacyjną lub jedno i drugie.

Cyklicznie zależna modularyzacja: Ten zapach powstaje, gdy dwie lub więcej abstrakcji zależą od siebie bezpośrednio lub pośrednio (tworząc ścisłe połączenie między abstrakcji).

Modularyzacja podobna do koncentratora: ten zapach powstaje, gdy abstrakcja ma zależności (zarówno przychodzące, jak i wychodzące) z dużą liczbą innych abstrakcji.

Hierarchia pachnie

Brakująca hierarchia: ten zapach powstaje, gdy segment kodu wykorzystuje logikę warunkową (zazwyczaj w połączeniu z „typami otagowanymi”) w celu jawnego zarządzania zmiennością w zachowaniu, w której można by stworzyć hierarchię i wykorzystać ją do enkapsulacji tych odmian.

Niepotrzebna hierarchia: ten zapach powstaje, gdy cała hierarchia dziedziczenia jest niepotrzebna, co wskazuje, że dziedziczenie zostało niepotrzebnie zastosowane w określonym kontekście projektowym.

Niefaktoryzowana hierarchia: ten zapach powstaje, gdy zachodzi niepotrzebne powielanie między typami w hierarchii.

Szeroka hierarchia: ten zapach powstaje, gdy hierarchia dziedziczenia jest „zbyt” szeroka, co wskazuje na brak typów pośrednich.

Hierarchia spekulacyjna: ten zapach powstaje, gdy jeden lub więcej typów w hierarchii jest dostarczanych spekulacyjnie (tj. W oparciu o wyobrażone potrzeby, a nie rzeczywiste wymagania).

Głęboka hierarchia: ten zapach powstaje, gdy hierarchia dziedziczenia jest „nadmiernie” głęboka.

Zbuntowana hierarchia: ten zapach powstaje, gdy podtyp odrzuca metody zapewniane przez jego nadtyp (y).

Broken Hierarchy: Ten zapach powstaje, gdy nadtyp i jego podtyp koncepcyjnie nie mają związku „IS-A”, co skutkuje zerwaną substytucyjnością.

Hierarchia wielościeżkowa: ten zapach powstaje, gdy podtyp dziedziczy zarówno bezpośrednio, jak i pośrednio od nadtypu, co prowadzi do niepotrzebnych ścieżek dziedziczenia w hierarchii.

Cykliczna hierarchia: ten zapach powstaje, gdy nadtyp w hierarchii zależy od dowolnego z jego podtypów.

Powyższą definicję i klasyfikację opisano w „Refaktoryzacji zapachów projektowych: Zarządzanie długiem technicznym ”. Niektóre bardziej odpowiednie zasoby można znaleźć tutaj .

Wzór to pomysł na rozwiązanie problemu jakiejś klasy. Anty-wzorzec to pomysł, jak go nie rozwiązać, ponieważ wdrożenie tego pomysłu spowodowałoby zły projekt.

Przykład: „wzorzec” oznacza użycie funkcji do ponownego wykorzystania kodu, „anty-wzorzec” to użycie do tego samego polecenia kopiuj-wklej. Oba rozwiązują ten sam problem, ale użycie funkcji zwykle prowadzi do bardziej czytelnego i łatwiejszego do utrzymania kodu niż kopiowanie-wklejanie.

Anty-wzór jest sposobem na rozwiązanie problemu. Ale jest coś więcej: jest to również sposób, który często można zobaczyć w próbach rozwiązania problemu.

Jeśli naprawdę chcesz studiować AntiPatterns, zdobądź książkę AntiPatterns (ISBN-13: 978-0471197133).

W nim definiują: „AntiPattern to forma literacka, która opisuje często występujące rozwiązanie problemu, który generuje zdecydowanie negatywne konsekwencje”.

Tak więc, jeśli jest to zła praktyka programistyczna, ale nie jest powszechna - ograniczona do jednej aplikacji, jednej firmy lub jednego programisty, nie spełnia części „Wzorzec” definicji AntiPattern.

Popularny sposób na zrobienie bałaganu. Jak na przykład klasa god / kitchensink (robi wszystko).

Co ciekawe, dany sposób rozwiązania problemu może być zarówno wzorem, jak i anty-wzorem. Singleton jest tego najlepszym przykładem. Pojawi się w obu zestawach literatury.

Anty-wzorzec jest komplementarna do wzorca projektowego . Anty-wzorzec to szablonowe rozwiązanie, którego nie należy używać w określonej sytuacji.

Podobnie jak w przypadku wzoru projektowego , anty-wzór jest również szablonem i powtarzalnym sposobem rozwiązania określonego problemu, ale w nieoptymalny i nieefektywny sposób.

Dzisiaj badacze i praktycy inżynierii oprogramowania często używają terminów „anty-wzór” i „zapach” zamiennie. Jednak koncepcyjnie nie są takie same. Wpis Wikipedii dotyczący anty-wzoru stwierdza, że ​​anty-wzór różni się od złej praktyki lub złego pomysłu co najmniej dwoma czynnikami. Anty-wzór jest

„Powszechnie stosowany proces, struktura lub schemat działania, który początkowo wydaje się odpowiednią i skuteczną odpowiedzią na problem, zazwyczaj ma więcej złych konsekwencji niż korzystne wyniki”.

Wyraźnie wskazuje, że anty-wzór jest wybierany w przekonaniu, że jest to dobre rozwiązanie (jako wzór) dla przedstawionego problemu; przynosi jednak więcej zobowiązań niż korzyści. Z drugiej strony zapach jest po prostu złą praktyką, która negatywnie wpływa na jakość systemu oprogramowania. Na przykład Singleton jest anty-wzorcem, a klasa Boga (lub niewystarczająca modularyzacja) to zapach projektowy.

Anty-wzorce są powszechnym sposobem, w jaki ludzie zwykle programują w niewłaściwy sposób, a przynajmniej nie tak dobry sposób.

Każdy wzorzec projektowy, który wyrządza więcej szkody niż dobru środowisku programistycznemu, będzie uważany za anty-wzorzec.

Niektóre anty-wzory są oczywiste, ale niektóre nie. Na przykład Singleton, chociaż wielu uważa, że ​​to dobry stary wzór, ale są inni, którzy tego nie robią.

Możesz sprawdzić pytanie Co jest takiego złego w singletonach? aby lepiej zrozumieć różne opinie na ten temat.

Podobnie jak w Algorytmie, możesz osiągnąć rozwiązanie za pomocą Brute force, ale jeśli sytuacja stanie się skomplikowana, musisz zapłacić dużo.