Klasy nazewnictwa - Jak uniknąć nazywania wszystkiego „Menedżerem <WhatEver>”? [Zamknięte]

Dawno temu przeczytałem artykuł (uważam, że wpis na blogu), który umieścił mnie na „właściwej” ścieżce nazywania obiektów: bądź bardzo skrupulatny w nazywaniu rzeczy w swoim programie.

Na przykład, jeśli mój wniosek był (jako typowy aplikacji biznesowych) obsługa użytkowników, firm i adresy będę mieć User, A Companyi Addressklasy domeny - i prawdopodobnie gdzieś UserManager, A CompanyManageri AddressManagerbędzie pop-up, który obsługuje te rzeczy.

Więc można powiedzieć, co te UserManager, CompanyManageri AddressManagerzrobić? Nie, ponieważ Manager to bardzo ogólny termin, który pasuje do wszystkiego, co możesz zrobić z obiektami domeny.

Artykuł, który przeczytałem, zalecał używanie bardzo specyficznych nazw. Gdyby była to aplikacja C ++, a UserManagerzadaniem jej było przydzielanie i uwalnianie użytkowników ze sterty, nie zarządzałby nimi, ale chroniłby ich narodziny i śmierć. Hmm, może moglibyśmy to nazwać UserShepherd.

A może UserManagerzadaniem jest sprawdzenie danych każdego obiektu użytkownika i podpisanie danych kryptograficznie. Wtedy mielibyśmy UserRecordsClerk.

Teraz, gdy ten pomysł utkwił mi w pamięci, staram się go zastosować. I ten prosty pomysł jest niezwykle trudny.

Potrafię opisać, co robią klasy i (o ile nie wpadam w szybkie i brudne kodowanie) klasy, które piszę, robią dokładnie jedną rzecz. To, za czym tęsknię od tego opisu do nazw, to rodzaj katalogu nazw, słownictwo, które odwzorowuje pojęcia na nazwy.

Ostatecznie chciałbym mieć coś w rodzaju katalogu wzorców (często wzorce projektowe łatwo podają nazwy obiektów, np. Fabryka )

• Fabryka - tworzy inne obiekty (nazewnictwo wzięte z wzorca projektowego)
• Pasterz - Pasterz zajmuje się życiem przedmiotów, ich tworzeniem i zamykaniem
• Synchronizer - Kopiuje dane między dwoma lub więcej obiektami (lub hierarchiami obiektów)

• Niania - Pomaga obiektom osiągnąć stan „użyteczny” po utworzeniu - na przykład poprzez połączenie z innymi obiektami

• itd itd.

Jak sobie z tym poradzisz? Czy masz ustalone słownictwo, wymyślasz nowe nazwy w locie, czy uważasz, że nazywanie rzeczy nie jest tak ważne czy złe?

PS: Interesują mnie również linki do artykułów i blogów omawiających ten problem. Na początek oto oryginalny artykuł, który zmusił mnie do myślenia: Nadawanie nazw klasom Java bez „Managera”

Aktualizacja: Podsumowanie odpowiedzi

Oto krótkie podsumowanie tego, czego nauczyłem się z tego pytania.

• Staraj się nie tworzyć nowych metafor (Niania)
• Zobacz, co robią inne frameworki

Dalsze artykuły / książki na ten temat:

• Jakie imiona regularnie zaliczasz / dołączasz do zajęć?
• Jakie jest najlepsze podejście do nazewnictwa klas?
• Książka: Wzory projektowe: elementy oprogramowania obiektowego wielokrotnego użytku (twarda okładka)
• Książka: Patterns of Enterprise Application Architecture (twarda okładka)
• Książka: Wzory realizacji (książka w miękkiej oprawie)

I aktualna lista prefiksów / sufiksów nazw, które zebrałem (subiektywnie!) Z odpowiedzi:

• Koordynator
• Budowniczy
• Pisarz
• Czytelnik
• Treser
• Pojemnik
• Protokół
• Cel
• Przetwornik
• Kontroler
• Widok
• Fabryka
• Jednostka
• Wiadro

I dobra wskazówka dla drogi:

Nie paraliż nazewnictwa. Tak, nazwiska są bardzo ważne, ale nie są wystarczająco ważne, aby tracić mnóstwo czasu. Jeśli nie potrafisz wymyślić dobrego imienia w 10 minut, idź dalej.

Zadałem podobne pytanie , ale tam, gdzie to możliwe, próbuję skopiować nazwy już w środowisku .NET i szukam pomysłów w środowiskach Java i Android .

Wydaje się Helper, Manageri Utilsą nieuniknionymi rzeczownikami, które dołączasz do koordynujących klas, które nie zawierają stanu i są na ogół proceduralne i statyczne. Alternatywą jest Coordinator.

Można dostać szczególnie fioletowy prosey z nazwiskami i przejść do rzeczy, jak Minder, Overseer, Supervisor, Administrator, i Master, ale jak powiedziałem, że wolę utrzymanie go jak nazwy ramowych masz w zwyczaju.

Niektóre inne typowe przyrostki (jeśli jest to poprawny termin), które można znaleźć również w środowisku .NET to:

• Builder
• Writer
• Reader
• Handler
• Container

Możesz zajrzeć na source-code-wordle.de , przeanalizowałem tam najczęściej używane sufiksy nazw klas frameworku .NET i niektórych innych bibliotek.

Top 20 to:

• atrybut
• rodzaj
• pomocnik
• kolekcja
• przetwornik
• treser
• informacje
• dostawca
• wyjątek
• usługa
• element
• menedżer
• węzeł
• opcja
• fabryka
• kontekst
• pozycja
• projektant
• baza
• redaktor

Jestem zwolennikiem dobrych nazwisk i często piszę o tym, jak ważne jest, aby zachować ostrożność przy wyborze nazw rzeczy. Z tego samego powodu jestem ostrożny z metaforami nazywania rzeczy. W pierwotnym pytaniu „fabryka” i „synchronizator” wyglądają jak dobre nazwy tego, co wydają się oznaczać. Jednak „pasterz” i „niania” nie są, ponieważ opierają się na metaforach . Klasa w twoim kodzie nie może być dosłownie nianią; nazywacie to nianią, ponieważ opiekuje się kilkoma innymi rzeczami, tak jak prawdziwa niania opiekuje się dziećmi lub dziećmi. W mowie nieformalnej jest to w porządku, ale nie (moim zdaniem) w przypadku nazewnictwa klas w kodzie, które będą musiały być utrzymywane przez tego, kto wie, kto, kiedy.

Dlaczego? Ponieważ metafory zależą od kultury, a często także od jednostki. Dla ciebie nazywanie klasy „niania” może być bardzo jasne, ale może nie jest tak jasne dla kogoś innego. Nie powinniśmy na tym polegać, chyba że piszesz kod przeznaczony wyłącznie do użytku osobistego.

W każdym razie konwencja może stworzyć lub złamać metaforę. Samo użycie „fabryki” opiera się na metaforze, która istnieje już od dłuższego czasu i jest obecnie dość dobrze znana w świecie programowania, więc powiedziałbym, że można z niej bezpiecznie korzystać. Jednak „niania” i „pasterz” są niedopuszczalne.

Mogliśmy zrobić bez xxxFactory, xxxManagerlub xxxRepositoryklas, jeśli modelowane świat rzeczywisty poprawnie:

Universe.Instance.Galaxies["Milky Way"].SolarSystems["Sol"]
        .Planets["Earth"].Inhabitants.OfType<Human>().WorkingFor["Initech, USA"]
        .OfType<User>().CreateNew("John Doe");

;-)

To brzmi jak śliskie nachylenie do czegoś, co zostanie opublikowane na stronie thedailywtf.com, „ManagerOfPeopleWhoHaveMortgages” itp.

Przypuszczam, że słuszne jest to, że jedna monolityczna klasa Manager nie jest dobrym projektem, ale użycie „Manager” nie jest złe. Zamiast UserManager możemy podzielić go na UserAccountManager, UserProfileManager, UserSecurityManager itp.

„Menedżer” to dobre słowo, ponieważ wyraźnie pokazuje, że klasa nie reprezentuje „rzeczy” w świecie rzeczywistym. „AccountsClerk” - jak mam powiedzieć, czy to klasa, która zarządza danymi użytkownika, czy reprezentuje kogoś, kto jest księgowym w swojej pracy?

Ponieważ interesują Cię artykuły w tej dziedzinie, możesz zainteresować się artykułem opiniującym Steve'a Yegge'a „Egzekucja w królestwie rzeczowników”:

http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html

Kiedy zastanawiam się nad użyciem Managerlub Helperw nazwie klasy, myślę, że to zapach kodu, co oznacza, że ​​nie znalazłem jeszcze odpowiedniej abstrakcji i / lub naruszam zasadę pojedynczej odpowiedzialności , więc refaktoryzuję i wkładam więcej wysiłku w projektowanie często znacznie ułatwia nazewnictwo.

Ale nawet dobrze zaprojektowane klasy nie nazywają się (zawsze), a twój wybór częściowo zależy od tego, czy tworzysz klasy modelu biznesowego, czy klasy infrastruktury technicznej.

Klasy modeli biznesowych mogą być trudne, ponieważ są różne dla każdej domeny. Są pewne terminy, których często używam, na przykład Policydla klas strategii w domenie (np. LateRentalPolicy), Ale zwykle wynikają z próby stworzenia „ wszechobecnego języka ”, który można udostępniać użytkownikom biznesowym, projektowania i nazewnictwa klas, aby modelowali prawdziwe -światowe pomysły, przedmioty, działania i wydarzenia.

Klasy infrastruktury technicznej są nieco łatwiejsze, ponieważ opisują domeny, które znamy naprawdę dobrze. Wolę zawierać nazwy wzorzec projektowy do nazw klas, jak InsertUserCommand, CustomerRepository,i SapAdapter.rozumiem zaniepokojenie komunikowania realizację zamiast intencją, ale wzorce projektowe poślubić te dwa aspekty klasy design - przynajmniej wtedy, gdy masz do czynienia z infrastrukturą, gdzie chcesz projekt implementacji powinien być przejrzysty, nawet gdy ukrywasz szczegóły.

Będąc au fait ze wzorami zdefiniowanymi przez (powiedzmy) książkę GOF , a następnie nazywanie obiektów po nich, dostaję długą drogę do nazywania klas, organizowania ich i komunikowania zamiarów. Większość ludzi zrozumie tę nomenklaturę (lub przynajmniej jej większą część).

Jeśli nie potrafię wymyślić bardziej konkretnej nazwy dla mojej klasy niż XyzManager, powinienem ponownie rozważyć, czy to naprawdę funkcjonalność, która należy do jednej klasy, tj. Architektoniczny „zapach kodu”.

Myślę, że najważniejsze jest, aby pamiętać: czy nazwa jest wystarczająco opisowa? Czy potrafisz powiedzieć, patrząc na nazwę, co ma zrobić Klasa? Używanie słów takich jak „Manager”, „Service” lub „Handler” w nazwach klas można uznać za zbyt ogólne, ale ponieważ używa ich wielu programistów, pomaga to zrozumieć, do czego służy klasa.

Ja sam często używam wzoru fasady (przynajmniej myślę, że tak to się nazywa). Mogę mieć Userklasę opisującą tylko jednego użytkownika i Usersklasę, która śledzi moją „kolekcję użytkowników”. Nie nazywam klasy, UserManagerbo nie lubię menedżerów w prawdziwym życiu i nie chcę o nich przypominać :) Po prostu użycie liczby mnogiej pomaga mi zrozumieć, co robi klasa.

Specyficzne dla C #, znalazłem „Wytyczne projektowania ram: konwencje, idiomy i wzory dla bibliotek .NET wielokrotnego użytku”, które mają wiele dobrych informacji na temat logiki nazewnictwa.

Jeśli chodzi o znalezienie bardziej szczegółowych słów, często używam tezaurusa i przeskakuję pokrewne słowa, aby znaleźć dobre. Staram się jednak nie spędzać z tym zbyt wiele czasu, ponieważ w miarę rozwoju pracuję nad lepszymi nazwami, a czasem zdaję sobie sprawę, że SuchAndSuchManagernaprawdę należy je podzielić na wiele klas, a wtedy nazwa przestarzałej klasy staje się nieistotna .

Uważam, że kluczową kwestią jest spójność w zakresie widoczności kodu, tj. Dopóki wszyscy, którzy muszą przeglądać / pracować nad twoim kodem, rozumieją twoją konwencję nazewnictwa, to powinno być w porządku, nawet jeśli zdecydujesz się je wywołać „CompanyThingamabob” i „UserDoohickey”. Pierwszym przystankiem, jeśli pracujesz dla firmy, jest sprawdzenie, czy istnieje konwencja firmy dotycząca nazewnictwa. Jeśli nie ma lub nie pracujesz dla firmy, stwórz własne przy użyciu odpowiednich dla Ciebie terminów, przekaż je kilku zaufanym współpracownikom / znajomym, którzy przynajmniej kodują od niechcenia, i dołącz wszelkie uzasadnione opinie.

Stosowanie konwencji innej osoby, nawet jeśli jest powszechnie akceptowane, jeśli nie wyskakuje z twojej strony, jest w mojej książce trochę błędem. Przede wszystkim muszę zrozumieć mój kod bez odniesienia do innej dokumentacji, ale jednocześnie musi on być wystarczająco ogólny, aby nie był niezrozumiały dla kogoś innego z tej samej dziedziny w tej samej branży.

Rozważę wzorce, których używasz dla swojego systemu, konwencje nazewnictwa / katalogowania / grupowania klas tendencji powinny być zdefiniowane przez zastosowany wzorzec. Osobiście trzymam się tych konwencji nazewnictwa, ponieważ są one najbardziej prawdopodobnym sposobem, aby inna osoba mogła pobrać mój kod i go uruchomić.

Na przykład UserRecordsClerk można lepiej wyjaśnić jako rozszerzenie ogólnego interfejsu RecordsClerk, który zarówno UserRecordsClerk, jak i CompanyRecordsClerk wdrażają, a następnie specjalizują, co oznacza, że ​​można spojrzeć na metody interfejsu, aby zobaczyć, do czego służą podklasy.

Zobacz książkę, taką jak Wzory projektowe, aby uzyskać informacje, jest to doskonała książka i może pomóc ci wyjaśnić, gdzie chcesz być z kodem - jeśli jeszcze go nie używasz! ; o)

Liczę na to, że dopóki twój wzór jest dobrze wybrany i używany, o ile jest to właściwe, wystarczą dość mało pomysłowe, proste nazwy klas!