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?
design-patterns
terminology
anti-patterns
ooad
g. rewolucja
źródło
źródło
Odpowiedzi:
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:
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:
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.
źródło
try: <do something>; except: pass
Może być antypatternem kardynała grzechu w Pythonie. Zobacz: realpython.com/blog/python/…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 .
źródło
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.
źródło
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.
źródło
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.
źródło
Popularny sposób na zrobienie bałaganu. Jak na przykład klasa god / kitchensink (robi wszystko).
źródło
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.
źródło
Anty-wzorzec jest komplementarna do wzorca projektowego . Anty-wzorzec to szablonowe rozwiązanie, którego nie należy używać w określonej sytuacji.
źródło
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.
źródło
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
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.
źródło
Anty-wzorce są powszechnym sposobem, w jaki ludzie zwykle programują w niewłaściwy sposób, a przynajmniej nie tak dobry sposób.
źródło
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.
źródło
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.
źródło