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

1188

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:

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.

42
źródło
11
Należy do wiki społeczności, ponieważ nie ma jednej „najlepszej” odpowiedzi. To jest dyskusja.
DOK,
13
To sprzeczne z intuicją. Czy nie powinni nazywać go forum? Sądzę, że wiki byłaby zbiorem faktów, a nie opinii.
AaronLS,
78
Dziękujemy za aktualizację - ale ta ostatnia wskazówka to okropna rada! Jeśli nie potrafisz wymyślić dobrego imienia w 10 minut, prawdopodobnie coś jest nie tak z twoją klasą. (Ze standardowymi zastrzeżeniami: 1) perfect jest wrogiem dobra, 2) Wysyłka jest cechą - pamiętaj tylko, że zaciągasz dług techniczny.)
Jeff Sternal
11
Jeśli nie możesz wymyślić dobrego imienia w 10 minut, poproś o pomoc kolegę. Nie poddawaj się.
9
Jeśli nie możesz wymyślić dobrego imienia w ciągu 10 minut, spróbuj wyjaśnić to swoim kolegom; oni mogą myśleć o dobrej nazwy (user338195), ale stara się wyjaśnić to prawdopodobnie będzie pomóc odkryć, co się dzieje z nim ( Jeff ).
WillC

Odpowiedzi:

204

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
Chris S.
źródło
4
Bardzo mi się podobają. Nie wpadają w pułapkę złych lub nieznanych metafor, ponieważ są już używane przez .NET Framework. Interesujące może być także spojrzenie na inne biblioteki (Java), aby uzyskać więcej informacji o tym, co jest powszechnie używane.
froh42
Chciałbym zasugerować Conductor, jak dyrygent orkiestry muzycznej. Jest to z pewnością ważna rola, w zależności od charakteru współpracy, którą musisz „prowadzić” (inne obiekty to bardzo wyspecjalizowani aktorzy, którzy powinni odpowiedzieć na scentralizowane polecenie i nie martwić się zbytnio o każdego innego współpracownika).
heltonbiker,
1
Nie sądzę, aby rozwiązaniem dla -er klas było wymyślenie innej nazwy. Jak czytałem w wielu innych postach i staram się poznać odpowiedź, musisz zmienić architekturę, a nie tylko nazwę.
Michael Ozeryansky
115

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
Markus Meyer
źródło
147
W jednej konkretnej firmie już dawno temu znałem inżyniera, który miał dość absurdalnych i rosnących mnóstwa reguł sufiksów, które nękały firmę, z którym wyzywająco zakończył każdą klasę Thingy.
8
Ta lista nazw sama w sobie nie jest tak przydatna bez kontekstu, w którym należy zastosować przyrostek.
Fred
65

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.

CesarGon
źródło
10
Ten argument naprawdę załamuje się, ponieważ oczywiście sama Fabryka jest metaforą. Często metafory naprawdę wyjaśniają, w czym obiekt może być dobry, podczas gdy niejasne lub ogólne automatycznie zapewniają, że jedynym sposobem, aby dowiedzieć się, co robi kod, jest jego pełne przeczytanie! Najgorszy scenariusz.
Kzqai,
1
+1 za unikanie „uroczych” imion. Myślę, że wspaniale jest być tak bezpośrednim, jak tylko potrafisz. (Oczywiście nie zawsze łatwo jest być bezpośrednim, zwięzłym, precyzyjnym i jednoznacznym jednocześnie…)
andrewf
1
Pomysłowy wybór czasownika + „er” zwykle będzie bardziej zrozumiały dla konkretnych klas niż kolorowa barwna analogia. Z drugiej strony nowe abstrakcje - rzeczy, które są nową koncepcją, nową „rzeczą”, a nie tylko nową „rzeczą” - często działają dobrze jako metafory („fasola” Javy, „soczewki” Haskella, GUI „okna”, „obietnice” wielu języków). Jednak większość baz kodowych nie będzie miała takich prawdziwych wynalazków.
Malnormalulo
51

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");

;-)

rev herzmeister
źródło
11
Jak dostaniesz się do równoległych wszechświatów i alternatywnych wymiarów?
Tster
23
To proste: Omniverse.Instance.Dimensions [„Ours”]. Universes [„Ours”]. Galaktyki ...… ok, dobrze, przyznaję, że wymagałoby to ponownej kompilacji. ;-)
herzmeister
73
Aktualizacja: został dodany w .NET 4.0 Universe.Instance.ToParallel()
:;
2
Łamie jednak prawo demetera!
Jonas G. Drange
13
To są Przedmioty i Członkowie, a nie nazwy klas
Harry Berry
39

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?

Mr. Boy
źródło
8
Co z UserAccounter, UserProfiler i UserSecurer? Jeśli pozbędziesz się Menedżera, musisz wymyślić konkretną definicję, co moim zdaniem jest dobrą rzeczą.
Didier A.
10
Co z UserAccount, UserProfile, UserSecurity oO?
klimat
3
Nazwałbym to „MortageOwnersManager”
volter9
Czasami domena ma określone nazwy. Jak „MortageHolder”, może być lepszy niż „MortageOwner”
borjab,
24

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.

Jeff Sternal
źródło
1
Bardzo podoba mi się pomysł używania Policysufiksu dla klas zawierających logikę biznesową
jtate
+1 za wzmiankę o zapachu kodu powiązanym z nazwami takimi jak „Menedżer” i „Pomocnik”. Uważam, że jeśli nie mam jasnych nazw rzeczy, zazwyczaj wynika to przynajmniej częściowo z niejasności w moim rozumieniu domeny, zarówno biznesowej, jak i technicznej. Niemal równoważnie może to oznaczać, że reaktywnie rozkładam klasy, ponieważ „stały się za duże” - co dla mnie jest również oznaką nieodpowiedniego modelowania. To powinna być najczęściej głosowana odpowiedź.
nclark
10

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ęść).

Brian Agnew
źródło
Fowler jest dla mnie dobrym punktem odniesienia, ale GOF jest świetną rekomendacją.
Lazarus
Wybacz mi moją ignorancję. Do której książki Fowlera się odwołujesz?
Brian Agnew,
19
Hmm, czasami to działa (na przykład jak Fabryka lub Strategia), ale innym razem czuję, że to komunikuje sposób implementacji (użyłem wzorca!) Bardziej niż zamiar i zadanie klasy. Na przykład najważniejszą rzeczą Singletona jest to, co reprezentuje - a nie to, że jest Singletonem. Tak ścisłe nazewnictwo po zastosowanych wzorach przypomina ścisłe nazewnictwo po zastosowanych typach. Na przykład notacja węgierska jako źle zastosowana przez grupę systemów Windows (opisująca typ danych C zamiast „typu intencyjnego”)
froh42
1
W przypadku klas infrastruktury technicznej zwykle pożądane jest, aby implementacja była przejrzysta - a większość kanonicznych nazw wzorów projektowych komunikuje zarówno implementację, jak i zamiar. Klasy modeli domen to jednak inna sprawa.
Jeff Sternal
10

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”.

Jasper van den Bosch
źródło
8

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.

Droozle
źródło
Bardzo podoba mi się także to podejście, ponieważ łagodzi ideę zarządzania obiektami z góry na dół. Grupa użytkowników może raczej sugerować, że praca jest wykonywana między użytkownikami zamiast z poziomu UserManager w dół. Ponadto posiadanie przez użytkownika odniesienia do użytkowników nie wydaje się tak dziwne, jak posiadanie UserManagera. Jest bardziej otwarty na względne myślenie, niż na czysto OOP.
Seph Reed
Problem z tym podejściem polega na tym, że wyszukiwanie kodu jest naprawdę trudne Users, szczególnie jeśli omijasz obiekt menedżera. this.users = new Users()Ale niezmiennie gdzieś w twoim kodzie usersbędzie się odnosić do tablicy Users.
Bałwan
Jak mówisz, Użytkownicy rzeczywiście oznaczają „zbiór użytkowników” - zbiór podmiotów, który jest stanowy. Ale SRP oznaczałoby, że nie chciałbyś łączyć zarządzania użytkownikami (funkcjonalność i logika biznesowa) z danymi użytkownika (stan). Nie twierdząc, że się mylisz, tylko ten UserManager jest odpowiedni, jeśli klasa jest odpowiedzialna za zarządzanie użytkownikami, a nie tylko przechowywanie ich stanu i podstawowej CRUD.
Richard Moore
5

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 .

AaronLS
źródło
3

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.

Łazarz
źródło
1
Mimo to konsekwentna, choć nieco nieintuicyjna konwencja jest lepsza niż rozpoczęcie własnej konwencji. Ludzie pracujący nad projektem bardzo szybko nauczą się spójnych konwencji i wkrótce zapominają, że funkcjonalność nie jest taka, jakiej można się spodziewać na pierwszy rzut oka.
Mr. Boy,
@John, właśnie to powiedziałem. Grupa musi zaakceptować konwencję, a jeśli pracujesz w firmie, sprawdź, czy istnieje konwencja firmy. Dla firmy myślę o dowolnej grupie, czy to o zespole projektowym typu open source, czy o luźnej kolekcji programistów. Gdyby wszyscy wzięli to, co było dostępne, które prawie spełniały ich wymagania, myślę, że bardzo nam brakowało innowacji.
Łazarz
2

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!

Karolina
źródło
Skomentowałem to w odpowiedzi Briana Agnewa. Nie wydaje mi się, aby nazwy wzorców tworzyły dobre nazwy klas tylko w niektórych przypadkach (Fabryka, Strategia), ale nie w innych (Singleton). Chcę, aby nazwy odzwierciedlały pracę klasy, a nie sposób, w jaki ją wdrożyłem.
froh42,