Czy powinniśmy definiować typy dla wszystkiego?

Ostatnio miałem problem z czytelnością mojego kodu.
Miałem funkcję, która wykonała operację i zwróciła ciąg reprezentujący identyfikator tej operacji do przyszłego odwołania (trochę jak OpenFile w Windows zwracający uchwyt). Użytkownik użyje tego identyfikatora później, aby rozpocząć operację i monitorować jej zakończenie.

Identyfikator musiał być ciągiem losowym ze względu na obawy związane z interoperacyjnością. Stworzyło to metodę, która miała bardzo niejasny podpis:

public string CreateNewThing()

To sprawia, że ​​zamiar typu zwracanego jest niejasny. Pomyślałem, że mogę zawinąć ten ciąg w inny typ, który uczyni jego znaczenie bardziej zrozumiałym:

public OperationIdentifier CreateNewThing()

Typ będzie zawierał tylko ciąg znaków i będzie używany za każdym razem, gdy zostanie użyty.

Oczywistym jest, że zaletą tego sposobu działania jest większe bezpieczeństwo typu i wyraźniejsze zamiary, ale tworzy także znacznie więcej kodu i kodu, który nie jest bardzo idiomatyczny. Z jednej strony podoba mi się dodatkowe bezpieczeństwo, ale także tworzy dużo bałaganu.

Czy uważasz, że ze względów bezpieczeństwa dobrą praktyką jest owijanie prostych typów w klasę?

Prymitywy, takie jak stringlub int, nie mają znaczenia w domenie biznesowej. Bezpośrednią konsekwencją tego jest to, że możesz błędnie użyć adresu URL, gdy oczekiwany jest identyfikator produktu, lub użyć ilości, gdy spodziewasz się ceny .

Z tego powodu wyzwanie Kalistenika obiektów obejmuje zawijanie prymitywów jako jedną z jego zasad:

Reguła 3: Zawiń wszystkie prymitywy i łańcuchy

W języku Java int jest prymitywnym, a nie prawdziwym obiektem, więc podlega innym regułom niż obiekty. Jest używany ze składnią, która nie jest zorientowana obiektowo. Co ważniejsze, sama int jest tylko skalarem, więc nie ma znaczenia. Gdy metoda przyjmuje int jako parametr, nazwa metody musi wykonać całą pracę polegającą na wyrażeniu intencji. Jeśli ta sama metoda zajmuje godzinę jako parametr, o wiele łatwiej jest zobaczyć, co się dzieje.

Ten sam dokument wyjaśnia, że ​​istnieje dodatkowa korzyść:

Małe przedmioty, takie jak Godzina lub Pieniądze, również dają nam oczywiste miejsce do postawienia zachowania, które w innym przypadku byłoby zaśmiecone wokół innych klas .

Rzeczywiście, gdy stosowane są prymitywy, zazwyczaj niezwykle trudne jest śledzenie dokładnej lokalizacji kodu związanego z tymi typami, co często prowadzi do poważnego powielania kodu . Jeśli jest Price: Moneyklasa, naturalne jest sprawdzenie zasięgu w środku. Jeżeli zamiast tego do przechowywania cen produktów stosuje się int(gorzej, a double), kto powinien potwierdzić zakres? Produkt? Rabat? Wózek?

Wreszcie trzecią korzyścią niewymienioną w dokumencie jest możliwość stosunkowo łatwej zmiany rodzaju bazowego. Jeśli dzisiaj mój ProductIdma shorttyp podstawowy, a później muszę go użyć int, istnieje szansa, że ​​kod do zmiany nie obejmie całej bazy kodu.

Wadą - i ten sam argument stosuje się do każdej reguły ćwiczenia Calisthenics Object - jest to, że jeśli szybko staje się zbyt przytłaczający, aby stworzyć klasę dla wszystkiego . Jeśli Productzawiera, ProductPricektóre dziedziczy, z PositivePricektórego dziedziczy, z Pricektórego dziedziczy Money, to nie jest to czysta architektura, ale raczej kompletny bałagan, w którym aby znaleźć jedną rzecz, opiekun powinien otwierać kilkadziesiąt plików za każdym razem.

Inną kwestią do rozważenia jest koszt (pod względem linii kodu) tworzenia dodatkowych klas. Jeśli opakowania są niezmienne (jak zwykle powinny), oznacza to, że jeśli weźmiemy C #, musisz mieć w opakowaniu co najmniej:

• Właściciel nieruchomości,
• Jego zaplecze,
• Konstruktor, który przypisuje wartość do pola bazowego,
• Zwyczaj ToString(),
• Komentarze do dokumentacji XML (która tworzy wiele wierszy),
• A Equalsi GetHashCodezastępuje (również dużo LOC).

i ewentualnie, w stosownych przypadkach:

• DebuggerDisplay atrybut,
• Override ==i !=operatorów,
• W końcu przeciążenie niejawnego operatora konwersji do płynnej konwersji do iz typu enkapsulowanego,
• Kontrakty kodowe (w tym niezmiennik, który jest dość długą metodą z trzema atrybutami),
• Kilka konwerterów, które będą używane podczas serializacji XML, serializacji JSON lub przechowywania / ładowania wartości do / z bazy danych.

Sto LOC na proste opakowanie sprawia, że ​​jest on zbyt wygórowany, dlatego też możesz być całkowicie pewien długoterminowej rentowności takiego opakowania. Pojęcie zakresu wyjaśnione przez Thomasa Junk jest tutaj szczególnie istotne. Pisanie setek LOC-ów, które będą reprezentować ProductIdużywane w całej bazie kodu, wygląda całkiem użytecznie. Napisanie klasy tego rozmiaru dla fragmentu kodu, który tworzy trzy wiersze w ramach jednej metody, jest znacznie bardziej wątpliwe.

Wniosek:

• Zawijaj operacje podstawowe w klasach, które mają znaczenie w domenie biznesowej aplikacji, gdy (1) pomaga zmniejszyć liczbę błędów, (2) zmniejsza ryzyko duplikacji kodu lub (3) pomaga później zmienić typ bazowy.

• Nie zawijaj automatycznie wszystkich prymitywów, które znajdziesz w kodzie: w wielu przypadkach użycie stringlub intjest całkowicie w porządku.

W praktyce public string CreateNewThing()zwracanie instancji ThingIdklasy zamiast stringmoże pomóc, ale możesz również:

• Zwraca instancję Id<string>klasy, czyli obiekt typu ogólnego wskazujący, że typem bazowym jest łańcuch. Zaletą czytelności jest brak konieczności utrzymywania wielu typów.

• Zwraca instancję Thingklasy. Jeśli użytkownik potrzebuje tylko identyfikatora, można to łatwo zrobić za pomocą:

  var thing = this.CreateNewThing();
  var id = thing.Id;
  

Użyłbym zakresu jako ogólnej zasady: im węższy zakres generowania i konsumowania values, tym mniejsze prawdopodobieństwo, że będziesz musiał stworzyć obiekt reprezentujący tę wartość.

Powiedz, że masz następujący pseudokod

id = generateProcessId();
doFancyOtherstuff();
job.do(id);

wtedy zakres jest bardzo ograniczony i nie widziałbym sensu w tworzeniu tego typu. Ale powiedzmy, że generujesz tę wartość w jednej warstwie i przekazujesz ją do kolejnej warstwy (lub nawet innego obiektu), wtedy stworzenie takiego typu byłoby idealnie uzasadnione.

Systemy typu statycznego mają na celu zapobieganie nieprawidłowemu wykorzystaniu danych.

Istnieją oczywiste przykłady typów, które to robią:

• nie możesz uzyskać miesiąca z UUID
• nie można pomnożyć dwóch ciągów.

Istnieją bardziej subtelne przykłady

• za coś nie można zapłacić za długość biurka
• nie możesz złożyć żądania HTTP, używając czyjejś nazwy jako adresu URL.

Możemy mieć ochotę użyć doublezarówno ceny, jak i długości, lub użyć stringzarówno nazwy, jak i adresu URL. Ale zrobienie tego psuje nasz niesamowity system typów i pozwala tym nadużyciom przejść testy statyczne języka.

Pomylenie funta sekund z Newtonem sekundami może mieć złe wyniki w czasie wykonywania .

Jest to szczególnie problem z łańcuchami. Często stają się one „uniwersalnym typem danych”.

Jesteśmy przyzwyczajeni do interfejsów tekstowych głównie z komputerami, a my często rozszerzyć te ludzkie interfejsy (UIS) do interfejsów programistycznych (API). Myślimy o 34,25 jako o znakach 34,25 . Myślimy o randce jak o postaciach 05-03-2015 . UUID uważamy za znaki 75e945ee-f1e9-11e4-b9b2-1697f925ec7b .

Ale ten model mentalny szkodzi abstrakcji API.

Słowa lub język, gdy są pisane lub wypowiadane, nie odgrywają żadnej roli w moim mechanizmie myślenia.

Albert Einstein

Podobnie reprezentacje tekstowe nie powinny odgrywać żadnej roli w projektowaniu typów i interfejsów API. Uważaj na string! (i inne nazbyt ogólne „prymitywne” typy)

Typy komunikują „jakie operacje mają sens”.

Na przykład kiedyś pracowałem na kliencie z interfejsem API REST HTTP. REST, poprawnie wykonane, używaj encji hipermedialnych, które mają hiperłącza wskazujące na powiązane encje. W tym kliencie wpisano nie tylko podmioty (np. Użytkownik, Konto, Subskrypcja), ale również linki do tych podmiotów (UserLink, AccountLink, SubscriptionLink). Linki były niewiele więcej niż opakowaniami Uri, ale osobne typy uniemożliwiały próbę użycia AccountLink do pobrania użytkownika. Gdyby wszystko było jasne Uri- lub nawet gorzej string- błędy te można było znaleźć tylko w czasie wykonywania.

Podobnie w twojej sytuacji masz dane, które są wykorzystywane tylko w jednym celu: do identyfikacji Operation. Nie należy go używać do niczego innego i nie powinniśmy próbować identyfikować Operations z losowymi ciągami, które stworzyliśmy. Utworzenie osobnej klasy zwiększa czytelność i bezpieczeństwo kodu.

Oczywiście wszystkie dobre rzeczy można wykorzystać w nadmiarze. Rozważać

1. ile przejrzystości dodaje do twojego kodu

2. jak często jest używany

Jeśli „typ” danych (w sensie abstrakcyjnym) jest często używany, do różnych celów i między interfejsami kodu, jest bardzo dobrym kandydatem do bycia odrębną klasą, kosztem gadatliwości.

Czy uważasz, że ze względów bezpieczeństwa dobrą praktyką jest owijanie prostych typów w klasę?

Czasami.

Jest to jeden z tych przypadków, w których trzeba rozważyć problemy, które mogą wyniknąć z użycia stringzamiast bardziej konkretnego OperationIdentifier. Jakie są ich nasilenie? Jakie jest ich prawdopodobieństwo?

Następnie musisz wziąć pod uwagę koszt korzystania z innego rodzaju. Jak bolesne jest stosowanie? Ile to pracy?

W niektórych przypadkach zaoszczędzisz czas i wysiłek, mając fajny konkretny typ do pracy. W innych nie będzie to warte kłopotu.

Ogólnie rzecz biorąc, uważam, że tego rodzaju rzeczy należy robić więcej niż dzisiaj. Jeśli masz podmiot, który coś znaczy w Twojej domenie, dobrze jest mieć go jako swój własny typ, ponieważ istnieje większe prawdopodobieństwo, że podmiot ten zmieni się / rozwinie wraz z firmą.

Ogólnie zgadzam się, że wiele razy powinieneś utworzyć typ dla prymitywów i łańcuchów, ale ponieważ powyższe odpowiedzi zalecają utworzenie typu w większości przypadków, wymienię kilka powodów, dla których / kiedy nie:

• Występ. Muszę tu odnosić się do prawdziwych języków. W języku C #, jeśli identyfikator klienta jest krótki i zawijasz go w klasę - właśnie utworzyłeś dużo narzutu: pamięci, ponieważ ma on teraz 8 bajtów w systemie 64-bitowym i szybkość, ponieważ teraz jest przydzielany na stosie.
• Kiedy przyjmujesz założenia dotyczące typu. Jeśli identyfikator klienta jest krótki i masz pewną logikę, która go w jakiś sposób spakuje - zwykle już przyjmujesz założenia dotyczące tego typu. We wszystkich tych miejscach musisz teraz przełamać abstrakcję. Jeśli jest to jedno miejsce, to nie jest wielka sprawa, jeśli jest wszędzie, możesz znaleźć to w połowie czasu, gdy używasz prymitywu.
• Ponieważ nie każdy język ma typef. W przypadku języków, które tego nie robią i kodu, który jest już napisany, wprowadzenie takiej zmiany może być dużym zadaniem, które może nawet wprowadzić błędy (ale każdy ma zestaw testów z dobrym zasięgiem, prawda?).
• W niektórych przypadkach zmniejsza czytelność. Jak to wydrukować? Jak to sprawdzić? Czy powinienem sprawdzać wartość null? Czy wszystkie pytania wymagają pogłębienia definicji typu.

Nie, nie powinieneś definiować typów (klas) dla „wszystkiego”.

Ale, jak podają inne odpowiedzi, często jest to przydatne. Powinieneś rozwijać - świadomie, jeśli to możliwe - uczucie zbytniego tarcia z powodu braku odpowiedniego typu lub klasy podczas pisania, testowania i utrzymywania swojego kodu. Dla mnie początek zbyt dużego tarcia występuje, gdy chcę skonsolidować wiele prymitywnych wartości jako pojedynczą wartość lub gdy muszę zweryfikować wartości (tj. Określić, która ze wszystkich możliwych wartości typu pierwotnego odpowiada prawidłowym wartościom „typ domyślny”).

Przekonałem się, że takie kwestie, które postawiłeś w swoim pytaniu, są odpowiedzialne za zbyt dużo projektowania w moim kodzie. Mam nawyk celowego unikania pisania więcej kodu niż to konieczne. Mamy nadzieję, że piszesz dobre (zautomatyzowane) testy dla swojego kodu - jeśli tak, to możesz z łatwością refaktoryzować kod i dodawać typy lub klasy, jeśli zapewnia to korzyści netto dla ciągłego rozwoju i utrzymania kodu .

Zarówno odpowiedź Telastyna, jak i odpowiedź Thomasa Junk'a bardzo dobrze podkreślają kontekst i użycie odpowiedniego kodu. Jeśli używasz wartości w jednym bloku kodu (np. Metoda, pętla, usingblok), możesz po prostu użyć prostego typu. Można nawet używać prymitywnego typu, jeśli używasz zestawu wartości wielokrotnie i w wielu innych miejscach. Ale im częściej i szerzej używasz zestawu wartości, a im rzadziej ten zestaw wartości odpowiada wartościom reprezentowanym przez typ pierwotny, tym bardziej powinieneś rozważyć kapsułkowanie wartości w klasie lub typie.

Na powierzchni wygląda na to, że wszystko, co musisz zrobić, to zidentyfikować operację.

Dodatkowo mówisz, co ma zrobić operacja:

aby rozpocząć operację [i] w celu monitorowania jej zakończenia

Mówisz to w taki sposób, jakby to było „tak, jak używana jest identyfikacja”, ale powiedziałbym, że są to właściwości opisujące operację. To brzmi jak definicja typu, istnieje nawet wzorzec zwany „wzorcem poleceń”, który bardzo dobrze pasuje. .

To mówi

wzorzec polecenia [...] służy do enkapsulacji wszystkich informacji potrzebnych do wykonania akcji lub wyzwolenia zdarzenia w późniejszym czasie .

Myślę, że jest to bardzo podobne w porównaniu z tym, co chcesz zrobić ze swoimi operacjami. (Porównaj wyrażenia, które pogrubiłem w obu cudzysłowach) Zamiast zwracać ciąg, zwróć identyfikator Operationw sensie abstrakcyjnym, na przykład wskaźnik do obiektu tej klasy.

Odnośnie komentarza

Byłoby wtf-y, aby nazwać tę klasę poleceniem, a następnie nie mieć w niej logiki.

Nie, nie zrobiłby tego. Pamiętaj, że wzory są bardzo abstrakcyjne , tak abstrakcyjne, że są w pewnym sensie meta. Oznacza to, że często abstrahują one od samego programowania, a nie jakiejś prawdziwej koncepcji świata. Wzorzec poleceń jest abstrakcją wywołania funkcji. (lub metoda) Jakby ktoś wcisnął przycisk pauzy zaraz po przekazaniu wartości parametrów i tuż przed wykonaniem, aby wznowić później.

Poniżej rozważa się oop, ale motywacja za nim powinna być prawdziwa dla każdego paradygmatu. Chciałbym podać kilka powodów, dla których umieszczenie logiki w poleceniu można uznać za coś złego.

1. Gdybyś miał całą tę logikę w poleceniu, byłby nadęty i bałagan. Pomyślałbyś „no cóż, cała ta funkcjonalność powinna być w osobnych klasach”. Byś byłaby logikę z polecenia.
2. Jeśli masz całą tę logikę w poleceniu, trudno byłoby przetestować i przeszkodzić w testowaniu. „Cholera jasna, dlaczego muszę używać tego nonsensu polecenia? Chcę tylko przetestować, jeśli ta funkcja wyrzuci 1, czy nie, nie chcę jej później wywoływać, chcę ją teraz przetestować!”
3. Jeśli masz całą tę logikę w poleceniu, nie ma sensu przesyłać raportów po zakończeniu. Jeśli myślisz o funkcji, która ma być domyślnie wykonywana synchronicznie, nie ma sensu być powiadamianym o zakończeniu wykonywania. Być może zaczynasz inny wątek, ponieważ twoja operacja polega na renderowaniu awatara do formatu kinowego (może potrzebować dodatkowego wątku na Raspberry pi), może musisz pobrać jakieś dane z serwera ... cokolwiek to jest, jeśli istnieje powód raportowanie po zakończeniu może być spowodowane pewną asynchronicznością (czy to słowo?). Myślę, że uruchomienie wątku lub skontaktowanie się z serwerem to logika, która nie powinna znajdować się w twoim poleceniu. Jest to nieco meta argument i może być kontrowersyjny. Jeśli uważasz, że to nie ma sensu, powiedz mi w komentarzach.

Podsumowując: wzorzec poleceń pozwala na zawinięcie funkcji w obiekt, który zostanie wykonany później. Ze względu na modułowość (funkcjonalność istnieje bez względu na to, czy jest wykonywana za pomocą komendy, czy nie), testowalność (funkcjonalność powinna być testowalna bez komendy) i wszystkie inne brzęczące słowa, które zasadniczo wyrażają potrzebę napisania dobrego kodu, nie wprowadzilibyśmy logiki do polecenia

Ponieważ wzory są abstrakcyjne, może być trudno wymyślić dobre metafory świata rzeczywistego. Oto próba:

„Hej, babciu, czy mógłbyś nacisnąć przycisk nagrywania na telewizorze o godzinie 12, żeby nie przegapić simpsonów na kanale 1?”

Moja babcia nie wie, co się dzieje technicznie, kiedy naciska ten przycisk nagrywania. Logika jest gdzie indziej (w telewizji). I to dobrze. Funkcjonalność jest enkapsulowana, a informacje ukryte przed poleceniem, to użytkownik API, niekoniecznie część logiki ... och jeez znów bełkoczę brzęczące słowa, lepiej dokończę teraz edycję.

Pomysł zawijania prymitywnych typów,

• Aby ustalić język specyficzny dla domeny
• Ogranicz błędy popełniane przez użytkowników, przekazując nieprawidłowe wartości

Oczywiście byłoby to bardzo trudne i niepraktyczne, aby robić to wszędzie, ale ważne jest, aby zawijać typy tam, gdzie jest to wymagane,

Na przykład, jeśli masz klasę Order,

Order
{
   long OrderId { get; set; }
   string InvoiceNumber { get; set; }
   string Description { get; set; }
   double Amount { get; set; }
   string CurrencyCode { get; set; }
}

Ważnymi właściwościami do wyszukiwania Zamówienia są głównie OrderId i InvoiceNumber. Kwota i kod waluty są ze sobą ściśle powiązane, a jeśli ktoś zmieni kod waluty bez zmiany kwoty, zamówienie nie będzie już uważane za ważne.

Tak więc tylko zawijanie OrderId, InvoiceNumber i wprowadzenie kompozytu dla waluty ma sens w tym scenariuszu i prawdopodobnie zawijanie opisu nie ma sensu. Tak preferowany wynik może wyglądać,

    Order
    {
       OrderIdType OrderId { get; set; }
       InvoiceNumberType InvoiceNumber { get; set; }
       string Description { get; set; }
       Currency Amount { get; set; }
    }

Nie ma więc powodu, żeby wszystko owijać, ale rzeczy, które naprawdę mają znaczenie.

Niepopularna opinia:

Zwykle nie powinieneś definiować nowego typu!

Definiowanie nowego typu do zawijania klasy podstawowej lub podstawowej jest czasem nazywane definiowaniem pseudo-typu. IBM opisuje to jako złych praktyk tutaj (koncentrują się w szczególności na nadużycia ze strony generyków w tym przypadku).

Pseudo typy sprawiają, że wspólna funkcja biblioteki jest bezużyteczna.

Funkcje matematyczne Java mogą współpracować ze wszystkimi liczbami pierwotnymi. Ale jeśli zdefiniujesz nową klasę Procent (zawijanie podwójnej liczby, która może mieścić się w przedziale 0 ~ 1), wszystkie te funkcje są bezużyteczne i muszą zostać otoczone przez klasy, które (jeszcze gorzej) muszą wiedzieć o wewnętrznej reprezentacji klasy Procent .

Pseudo typy stają się wirusowe

Podczas tworzenia wielu bibliotek często zdarza się, że te pseudotypy stają się wirusowe. Jeśli użyjesz wyżej wspomnianej klasy procentowej w jednej bibliotece, albo będziesz musiał ją przekonwertować na granicy biblioteki (tracąc wszelkie bezpieczeństwo / znaczenie / logikę / inny powód, dla którego miałeś utworzyć ten typ), albo będziesz musiał stworzyć te klasy dostępne również w innej bibliotece. Zarażanie nowej biblioteki typami, w których wystarczyłoby zwykłe podwójne.

Zabierz wiadomość

Tak długo, jak typ, który zawijasz, nie wymaga dużej logiki biznesowej, odradzałbym pakowanie go w pseudo-klasę. Powinieneś zawinąć klasę tylko wtedy, gdy istnieją poważne ograniczenia biznesowe. W innych przypadkach prawidłowe nazewnictwo zmiennych powinno mieć duży wpływ na przekazywanie znaczenia.

Przykład:

A uintmoże idealnie reprezentować identyfikator użytkownika, możemy nadal używać wbudowanych operatorów Java dla uints (takich jak ==) i nie potrzebujemy logiki biznesowej do ochrony „wewnętrznego stanu” identyfikatora użytkownika.

Podobnie jak w przypadku wszystkich wskazówek, umiejętność stosowania zasad jest umiejętnością. Jeśli tworzysz własne typy w języku opartym na typach, sprawdzasz typ. Ogólnie rzecz biorąc, będzie to dobry plan.

Konwencja Naming jest kluczem do czytelności. Oba połączone mogą jasno wyrażać intencje.
Ale /// jest nadal przydatne.

Tak, powiedziałbym, że stwórz wiele własnych typów, gdy ich życie wykracza poza granice klas. Weź również pod uwagę użycie obu Structi Classnie zawsze klasy.