Klasy użytkowe są złe? [Zamknięte]

Widziałem ten wątek

Jeśli klasa „Utilities” jest zła, gdzie mam umieścić swój ogólny kod?

i pomyślał, dlaczego klasy użytkowe są złe?

Powiedzmy, że mam model domeny, który obejmuje dziesiątki klas. Muszę mieć możliwość obsługi instancji xml-ify. Czy utworzyć metodę toXml na rodzicu? Czy mogę utworzyć klasę pomocniczą MyDomainXmlUtility.toXml? Jest to przypadek, w którym potrzeba biznesowa obejmuje cały model domeny - czy naprawdę należy do metody instancji? A co, jeśli istnieje kilka metod pomocniczych dotyczących funkcjonalności XML aplikacji?

Klasy użytkowe nie są dokładnie złe, ale mogą naruszać zasady, które składają się na dobry projekt zorientowany obiektowo. W dobrym projekcie obiektowym większość klas powinna reprezentować jedną rzecz oraz wszystkie jej atrybuty i operacje. Jeśli operujesz na jakiejś rzeczy, ta metoda powinna prawdopodobnie należeć do tej rzeczy.

Czasami jednak można użyć klas narzędziowych do zgrupowania kilku metod razem - przykładem jest java.util.Collectionsklasa udostępniająca szereg narzędzi, których można użyć w dowolnej kolekcji Java. Nie są one specyficzne dla jednego konkretnego typu kolekcji, ale zamiast tego implementują algorytmy, które mogą być używane w dowolnej kolekcji.

Naprawdę, to, co musisz zrobić, to przemyśleć swój projekt i określić, gdzie najlepiej jest umieścić metody. Zwykle jest to operacje wewnątrz klasy. Jednak czasami jest to rzeczywiście klasa użytkowa. Jednak gdy używasz klasy narzędziowej, nie wrzucaj do niej tylko losowych metod, zamiast tego organizuj metody według przeznaczenia i funkcjonalności.

Myślę, że ogólny konsensus jest taki, że klasy użytkowe nie są złe same w sobie . Musisz tylko rozsądnie ich używać:

• Zaprojektuj statyczne metody narzędziowe tak, aby były ogólne i wielokrotnego użytku. Upewnij się, że są bezpaństwowcami; tj. brak zmiennych statycznych.

• Jeśli masz wiele metod narzędziowych, podziel je na klasy w sposób, który ułatwi programistom ich znalezienie.

• Nie używaj klas narzędzi, w przypadku których lepszym rozwiązaniem byłyby metody statyczne lub instancyjne w klasie domeny. Na przykład zastanów się, czy lepszym rozwiązaniem byłyby metody w abstrakcyjnej klasie bazowej lub instancji klasy pomocniczej.

• W przypadku języka Java 8 i nowszych „metody domyślne” w interfejsie mogą być lepszą opcją niż klasy narzędziowe. (Zobacz na przykład Interfejs z metodami domyślnymi a Klasa abstrakcyjna w języku Java 8 ).

Innym sposobem spojrzenia na to pytanie jest zauważenie, że w zacytowanym pytaniu „Jeśli klasy użyteczności są„ złe ”” jest argumentem słomnika. Tak jak ja pytam:

„Jeśli świnie potrafią latać, czy powinienem nosić parasolkę?”.

W powyższym pytaniu nie mówię właściwie, że świnie potrafią latać ... ani że zgadzam się z tezą, że potrafią latać.

Typowe stwierdzenia „xyz to zło” to narzędzia retoryczne, które mają skłonić cię do myślenia, przedstawiając skrajny punkt widzenia. Rzadko (jeśli w ogóle) są pomyślane jako stwierdzenia dosłownych faktów.

Klasy narzędziowe są problematyczne, ponieważ nie grupują obowiązków z danymi, które je obsługują.

Są jednak niezwykle przydatne i cały czas buduję je jako konstrukcje stałe lub jako odskocznię podczas dokładniejszego refaktora.

Z punktu widzenia czystego kodu klasy użytkowe naruszają pojedynczą odpowiedzialność i zasadę otwartego zamknięcia. Mają wiele powodów do zmiany i zgodnie z projektem nie można ich rozszerzać. Tak naprawdę powinny istnieć tylko podczas refaktoryzacji jako pośredni cruft.

Przypuszczam, że kiedy zaczyna się robić zło

1) Robi się zbyt duży (w tym przypadku po prostu pogrupuj je w znaczące kategorie).
2) Istnieją metody, które nie powinny być metodami statycznymi

Ale dopóki te warunki nie zostaną spełnione, myślę, że są bardzo przydatne.

Praktyczna zasada

Możesz spojrzeć na ten problem z dwóch perspektyw:

• Ogólne *Utilmetody są często sugestią złego projektu kodu lub leniwej konwencji nazewnictwa.
• Jest to uzasadnione rozwiązanie projektowe dla bezstanowych funkcji wielokrotnego użytku między domenami. Należy pamiętać, że dla prawie wszystkich typowych problemów istnieją rozwiązania.

Przykład 1. Prawidłowe wykorzystanie utilklas / modułów. Przykład biblioteki zewnętrznej

Załóżmy, że piszesz aplikację obsługującą pożyczki i karty kredytowe. Dane z tych modułów są udostępniane za pośrednictwem usług internetowych w jsonformacie. Teoretycznie można ręcznie konwertować obiekty na łańcuchy, które będą w jsonśrodku, ale to wymyśliłoby koło na nowo. Prawidłowym rozwiązaniem byłoby zawarcie w obu modułach zewnętrznej biblioteki służącej do konwersji obiektów java do żądanego formatu. (na przykładowym obrazie pokazałem gson )

Przykład 2. Prawidłowe wykorzystanie utilklas / modułów. Pisanie własnych utilbez wymówek do innych członków zespołu

Jako przypadek użycia przyjmijmy, że musimy wykonać jakieś obliczenia w dwóch modułach aplikacji, ale oba muszą wiedzieć, kiedy w Polsce są święta. Teoretycznie możesz wykonać te obliczenia wewnątrz modułów, ale lepiej byłoby wyodrębnić tę funkcjonalność do oddzielnego modułu.

Oto mały, ale ważny szczegół. Klasa / moduł, który napisałeś, nie nazywa się HolidayUtil, ale PolishHolidayCalculator. Funkcjonalnie jest to utilklasa, ale udało nam się uniknąć ogólnego słowa.

Klasy użytkowe są złe, ponieważ oznaczają, że byłeś zbyt leniwy, aby wymyślić lepszą nazwę dla klasy :)

Biorąc to pod uwagę, jestem leniwy. Czasami po prostu musisz wykonać swoją pracę, a twój umysł jest pusty… wtedy zaczynają wkradać się zajęcia z "narzędzi".

Patrząc teraz wstecz na to pytanie, powiedziałbym, że metody rozszerzające C # całkowicie niszczą potrzebę klas narzędziowych. Ale nie wszystkie języki mają tak genialny konstrukt.

Masz również JavaScript, w którym możesz po prostu dodać nową funkcję bezpośrednio do istniejącego obiektu.

Ale nie jestem pewien, czy naprawdę istnieje elegancki sposób rozwiązania tego problemu w starszym języku, takim jak C ++ ...

Dobry kod obiektowy jest trochę trudny do napisania i trudno go znaleźć, ponieważ pisanie dobrego obiektu obiektowego wymaga dużo więcej czasu / wiedzy niż pisanie przyzwoitego kodu funkcjonalnego.

A kiedy masz ograniczony budżet, twój szef nie zawsze jest zadowolony, widząc, że spędziłeś cały dzień na pisaniu kilku zajęć ...

Nie do końca zgadzam się, że klasy użytkowe są złe.

Chociaż klasa użytkowa może w pewien sposób naruszać zasady OO, nie zawsze są one złe.

Na przykład wyobraź sobie, że potrzebujesz funkcji, która wyczyści ciąg ze wszystkich podciągów pasujących do wartości x.

stl c ++ (na razie) nie obsługuje tego bezpośrednio.

Możesz utworzyć polimorficzne rozszerzenie std::string.

Problem w tym, czy naprawdę chcesz, aby KAŻDY łańcuch, którego używasz w swoim projekcie, był Twoją rozszerzoną klasą ciągów?

Są chwile, kiedy OO tak naprawdę nie ma sensu, a to jest jeden z nich. Chcemy, aby nasz program był kompatybilny z innymi programami, więc będziemy się trzymać std::stringi tworzyć klasę StringUtil_(lub coś).

Powiedziałbym, że najlepiej jest trzymać się jednego narzędzia na klasę. Powiedziałbym, że głupie jest mieć jedno narzędzie dla wszystkich klas lub wiele narzędzi dla jednej klasy.

Bardzo łatwo jest oznaczyć coś jako narzędzie tylko dlatego, że projektant nie mógł wymyślić odpowiedniego miejsca na umieszczenie kodu. Często jest kilka prawdziwych „narzędzi”.

Zasadniczo zazwyczaj przechowuję kod w pakiecie, w którym jest używany po raz pierwszy, a następnie przekształcam go w bardziej ogólne miejsce tylko wtedy, gdy stwierdzę, że później jest naprawdę potrzebny gdzie indziej. Jedynym wyjątkiem jest sytuacja, gdy mam już pakiet, który wykonuje podobną / powiązaną funkcjonalność, a kod najlepiej tam pasuje.

Klasy narzędzi zawierające statyczne metody bezstanowe mogą być przydatne. Testy jednostkowe są często bardzo łatwe.

Dzięki Java 8 możesz używać statycznych metod w interfejsach ... problem rozwiązany.

Większość klas Util jest zła, ponieważ:

1. Poszerzają zakres metod. Udostępniają publicznie kod, który w innym przypadku byłby prywatny. Jeśli metoda util jest potrzebna wielu wywołującym w oddzielnych klasach i jest stabilna (tj. Nie wymaga aktualizacji), moim zdaniem lepiej jest skopiować i wkleić prywatne metody pomocnicze do klasy wywołującej. Po ujawnieniu go jako API, utrudniasz zrozumienie, jaki jest publiczny punkt wejścia do komponentu jar (utrzymujesz strukturę drzewa zwaną hierarchią z jednym rodzicem na metodę. Jest to łatwiejsze do rozdzielenia mentalnego na komponenty, co jest trudniejsze, gdy masz metody wywoływane z wielu metod nadrzędnych).
2. Powodują martwy kod. Metody użytkowe z czasem stają się nieużywane, gdy Twoja aplikacja ewoluuje, a nieużywany kod zanieczyszcza bazę kodu. Gdyby pozostał prywatny, kompilator poinformowałby Cię, że metoda jest nieużywana i możesz ją po prostu usunąć (najlepszy kod nie zawiera żadnego kodu). Gdy sprawisz, że taka metoda stanie się nieprywatna, komputer nie będzie w stanie pomóc Ci usunąć nieużywanego kodu. Można go wywołać z innego pliku jar dla wszystkich znanych komputerów.

Istnieją pewne analogie do bibliotek statycznych i dynamicznych.

Kiedy nie mogę dodać metody do klasy (powiedzmy, Accountjest zablokowana przed zmianami przez Jr. Developers), po prostu dodaję kilka statycznych metod do mojej klasy Utilities, takich jak:

public static int method01_Account(Object o, String... args) {
    Account acc = (Account)o;
    ...
    return acc.getInt();
}  

Klasy użytkowe nie zawsze są złe. Ale powinny zawierać tylko metody, które są wspólne dla szerokiego zakresu funkcji. Jeśli istnieją metody, których można używać tylko w ograniczonej liczbie klas, rozważ utworzenie klasy abstrakcyjnej jako wspólnego rodzica i umieść w niej metody.