Czy istnieje antypattern opisujący tę metodę kodowania? [Zamknięte]

Mam bazę kodów, w której programista zwykle owija rzeczy w obszarach, które nie mają sensu. Na przykład, biorąc pod uwagę dziennik błędów, możemy zalogować się za pośrednictwem

ErrorLog.Log(ex, "friendly message");

Dodał różne inne środki, aby wykonać dokładnie to samo zadanie. NA PRZYKŁAD

SomeClass.Log(ex, "friendly message");

Który po prostu się odwraca i wywołuje pierwszą metodę. Zwiększa to poziom złożoności bez dodatkowych korzyści. Czy istnieje jakiś anty-wzór, aby to opisać?

Warto nazwać jakiś nawyk złego kodowania Antipatternem, jeśli jest dość rozpowszechniony.

Resztę nazywamy po prostu „kodem śmieci” ...

Gdybym zaproponował nazwę tego szczególnego złego nawyku, byłby to „Zaburzenie obsesyjno-abstrakcyjne” :-)

Nie, to nie jest anty-wzór, ale chciałbym poruszyć następujące kwestie.

Naruszenie zasady pojedynczej odpowiedzialności

SRP mówi, że klasa powinna mieć jeden powód do zmiany. Dodanie metody rejestratora oznacza, że ​​klasa musi się również zmienić, jeśli logika logowania powinna zostać zmieniona.

Naruszenie is-azwiązku

Klasy podstawowe nie są przybornikami, w których można dodać kilka metod wygody.

W ten sposób skutecznie łączy wszystkie odziedziczone klasy z implementacjami, które ma klasa podstawowa.

Porównaj to z kompozycją.

Nie oznacza to, że jest to dopuszczalne, ale może to być po prostu niedokończone refaktoryzacja. Być może SomeClass.log () miał swoją logikę i został zaimplementowany jako pierwszy. A później zdali sobie sprawę, że powinni używać ErrorLog.Log (). Zamiast więc zmieniać 100 miejsc, w których wywoływana jest SomeClass.Log (), po prostu delegowali je do ErrorLog.Log (). Osobiście zmieniłbym wszystkie odwołania do ErrorLog.Log () lub przynajmniej skomentował SomeClass.log (), aby powiedzieć, dlaczego deleguje sposób, w jaki to robi.

Tylko coś do rozważenia.

Termin „Kod Lasagna” przychodzi mi na myśl, choć najwyraźniej oznacza to różne rzeczy dla różnych ludzi . Moja interpretacja zawsze była „warstwowa ze względu na bycie warstwową”.

Nie jestem pewien, czy opisałbym to jako naruszenie zasady pojedynczej odpowiedzialności, ponieważ jeśli nastąpi zmiana w sygnaturze metody ErrorLog (metoda wywoływana przez SomeClass), każdy kod klienta wywołujący tę metodę zawiedzie.

Istnieje oczywiście sposób wykorzystania dziedziczenia (lub tworzenia klas wymagających logowania za pomocą interfejsu rejestrowania).

Lub możemy to potraktować jako „moment, którego można się nauczyć” :)

Twój programista może być w połowie drogi do dobrego pomysłu. Załóżmy, że chcesz mieć wymóg, aby wszystkie obiekty biznesowe były zdolne do inteligentnego rejestrowania. Możesz zdefiniować:

   public interface IBusinessObjectLogger
   {
       void Log(Exception ex, string logMessage)
   }

Teraz wewnątrz swoich obiektów możesz użyć obiektu ErrorLog do faktycznego rejestrowania, podczas gdy kod SomeClass dodaje określoną wartość obiektu do komunikatu dziennika. Następnie można rozszerzyć interfejsy API rejestrowania w celu wdrożenia funkcji rejestrowania opartej na plikach, bazach danych lub komunikatach bez dotykania obiektów biznesowych.

Nie jestem pewien, czy to automatycznie jest złe.

Jeśli dzwonisz do SomeClass, z pewnością jest to zło, ale jeśli Log jest używany tylko Z WEJŚCIA SomeClass, to odcina połączenie i nazwałbym to akceptowalnym.

W rzeczywistości jest to dość powszechne w niektórych stylach kodowania, a podstawy linii myślenia same w sobie nie są anty-wzorcem.

Prawdopodobnie wynika to z faktu, że ktoś koduje z konieczności bez wiedzy o szerszej bazie kodu: „OK, ten kod musi zarejestrować błąd, ale ta funkcja nie jest głównym celem kodu. Dlatego potrzebuję metody / klasy, która to zrobi dla mnie". To dobry sposób myślenia; ale nie wiedząc, że istnieje ErrorLog, stworzyli SomeClass. W pewnym momencie odnaleźli ErrorLog i zamiast zastąpić wszystkie zastosowania metody, którą zastosowali, wywołali metodę ErrorLog. To właśnie staje się problemem.

Przypadkowa złożoność to złożoność pojawiająca się w programach komputerowych lub w procesie ich opracowywania, która nie jest niezbędna do rozwiązania problemu. Chociaż zasadnicza złożoność jest nieodłączna i nieunikniona, przypadkowa złożoność jest spowodowana podejściem wybranym do rozwiązania problemu.

http://en.wikipedia.org/wiki/Accidental_complexity

Może to być nadużycie / niezrozumienie wzoru elewacji . Widziałem podobne rzeczy w bazie kodu, z którą pracowałem. Deweloperzy przeszli fazę, gdy oszaleli na punkcie wzorów projektowych, nie rozumiejąc nadrzędnych zasad projektowania OO.

Niewłaściwe użycie wzoru elewacji powoduje rozmycie poziomów abstrakcji na warstwach aplikacji.

To, co robi ten programista, polega na owijaniu kodu, aby nie miał bezpośredniej zależności od modułu rejestrującego. Bez bardziej szczegółowych informacji nie można podać bardziej konkretnego wzorca. (To, że te opakowania nie są przydatne, to twoja opinia, z którą nie można się zgodzić ani nie zgodzić bez większej ilości informacji).

Wzory, do których może to dotyczyć, to Proxy , Delegat , Dekorator , Kompozyt lub inne, które mają związek z zawijaniem, ukrywaniem lub rozprowadzaniem połączeń. Może to być jedna z takich rzeczy w niepełnym stanie rozwoju.

Mogłem sobie wyobrazić, że to różnica kulturowa. Być może istnieje dobry powód posiadania zduplikowanej funkcjonalności w tej konkretnej bazie kodu. Mogłem sobie wyobrazić łatwość pisania jako taki powód. Programiści Python nadal twierdzą, że jest zły, ponieważ „ Powinien być jeden - a najlepiej tylko jeden - oczywisty sposób na zrobienie tego. ”, Ale niektórzy Perli mogą być przyzwyczajeni do faktu, że „ jest więcej niż jeden sposób na zrobienie tego ".