Nazywanie klas - jak uniknąć nazywania wszystkiego "menedżerem"? [zamknięte]

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

Top 20 są:

• atrybut
• typ
• helper
• kolekcja
• konwerter
• handler
• info
• dostawca
• wyjątek
• serwis
• element
• manager
• węzeł
• opcja
• fabryka
• kontekst
• pozycja
• projektant
• baza
• edytor

Jestem za dobrymi imionami i często piszę o tym, jak ważne jest dbanie o to, aby dobierać nazwy dla rzeczy. Z tego samego powodu nie zwracam uwagi na metafory przy nazywaniu rzeczy. W oryginalnym pytaniu "fabryka " i" synchronizer " 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ą; nazywasz ją nianią, ponieważ opiekuje się inną rzeczy bardzo podobnie jak prawdziwa niania opiekuje się dziećmi lub dziećmi. To jest OK w mowie nieformalnej, ale nie w porządku (moim zdaniem) dla nazywania klas w kodzie, które będą musiały być utrzymywane przez kto wie, kto wie, kiedy.

Dlaczego? Ponieważ metafory są zależne od kultury i często zależne od jednostki. Dla Ciebie, nazywanie klasy "niania" może być bardzo jasne, ale może nie jest to tak jasne dla kogoś innego. Nie powinniśmy na tym polegać, chyba że piszesz kod, który jest tylko dla osobistych użyj.

W każdym przypadku konwencja może tworzyć lub łamać metaforę. Samo użycie "factory" opiera się na metaforze, ale takiej, która istnieje już od dłuższego czasu i jest obecnie dość dobrze znana w świecie programowania, więc powiedziałbym, że jest Bezpieczna w użyciu. Jednak "niania" i "pasterz" są niedopuszczalne.

Moglibyśmy się obejść bez żadnych xxxFactory, xxxManager lub xxxRepository klasy jeśli poprawnie modelujemy świat rzeczywisty:

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

;-)

To brzmi jak śliska pochyłość do czegoś, co zostanie umieszczone na thedailywtf.com, "Managerofpeoplewwhavemortgages" itp.

Przypuszczam, że to prawda, że jedna monolityczna Klasa Menedżera nie jest dobrym projektem, ale używanie 'Managera' nie jest złe. Zamiast UserManager możemy podzielić go na UserAccountManager, UserProfileManager, UserSecurityManager, itd.

'Menedżer' to dobre słowo, ponieważ wyraźnie pokazuje, że klasa nie reprezentuje prawdziwej 'rzeczy'. "AccountsClerk" - how am Mam powiedzieć, czy to klasa, która zarządza danymi użytkowników, czy reprezentuje kogoś, kto jest księgowym do ich pracy?

Ponieważ interesują Cię artykuły z tej dziedziny, być może zainteresuje cię artykuł Steve 'a Yegge' a "egzekucja w Królestwie rzeczowników":

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

Kiedy myślę o użyciu Manager LUB Helper w nazwie klasy, uważam to za zapach kodu, który oznacza, że nie znalazłem jeszcze właściwej abstrakcji i / lub naruszam zasadę pojedynczej odpowiedzialności , więc refaktoryzacja i wkładanie większego wysiłku w projektowanie często znacznie ułatwia nazywanie.

Ale nawet dobrze zaprojektowane klasy nie (zawsze) się nazywają, a twoje wybory częściowo zależą od tego, czy tworzysz klasy modelu biznesowego, czy infrastrukturę techniczną klasy.

Bycie au fait z wzorcami zdefiniowanymi przez (powiedzmy) GOF book i nazywanie obiektów po nich daje mi długą drogę w nazywaniu klas, organizowaniu ich i komunikowaniu intencji. Większość ludzi zrozumie tę nomenklaturę (a przynajmniej większą jej część).

Jeśli nie mogę wymyślić bardziej konkretnej nazwy dla mojej klasy niż XyzManager, to byłby dla mnie punkt, aby rozważyć, czy jest to naprawdę funkcjonalność, która należy do jednej klasy, tzn. architektoniczny "zapach kodu".

Myślę, że najważniejszą rzeczą, o której należy pamiętać, jest to, czy nazwa jest wystarczająco opisowa? Czy patrząc na nazwę można stwierdzić, co klasa ma robić? Używanie słów takich jak "Manager", "Service" lub "Handler" w nazwach klas może być uważane za zbyt ogólne, ale ponieważ wielu programistów używa ich, pomaga to również zrozumieć, do czego służy Klasa.

Specyficzne dla C#, znalazłem "Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable.NET Libraries", aby mieć wiele dobrych informacji na temat logiki nazewnictwa.

Jeśli chodzi o znalezienie tych bardziej konkretnych słów, często używam tezaurusa i przeskakuję przez powiązane słowa, aby spróbować znaleźć dobry. Staram się jednak nie spędzać z nim zbyt wiele czasu, w miarę postępów w rozwoju wymyślam lepsze nazwy, lub czasami zdaję sobie sprawę, że SuchAndSuchManager naprawdę powinno być podzielony na wiele klas, a następnie nazwa tej przestarzałej klasy staje się nie-problemem.

Uważam, że kluczową rzeczą jest zachowanie spójności w sferze widoczności kodu, tzn. tak długo, jak każdy, kto musi spojrzeć na kod / pracować nad nim, rozumie twoją konwencję nazewnictwa, powinno to być w porządku, nawet jeśli zdecydujesz się nazywać je "CompanyThingamabob" i "UserDoohickey". Pierwszym przystankiem, jeśli pracujesz dla firmy, jest sprawdzenie, czy istnieje konwencja firmowa dotycząca nazewnictwa. Jeśli nie ma lub nie pracujesz dla firmy, Stwórz własną, używając terminów, które mają sens do ciebie, przekazać go wokół kilku zaufanych kolegów / przyjaciół, którzy przynajmniej kod przypadkowo, i włączyć wszelkie opinie, które mają sens.

Stosowanie cudzej konwencji, nawet jeśli jest powszechnie akceptowane, jeśli nie wyskoczy ze strony na Ciebie, jest trochę błędem w mojej książce. Przede wszystkim muszę zrozumieć mój kod bez odniesienia do innej dokumentacji, ale jednocześnie musi być na tyle ogólny, aby nie był niezrozumiały dla kogoś innego w tej samej dziedzinie w tym samym przemysł.

Rozważyłbym wzory, których używasz w swoim systemie, konwencje nazewnictwa / katalogowania / grupowania klas są definiowane przez użyty wzorzec. Osobiście trzymam się tych konwencji nazewnictwa, ponieważ są one najbardziej prawdopodobnym sposobem, aby inna osoba mogła odebrać mój kod i uruchomić go.

Na przykład UserRecordsClerk może być lepiej wyjaśnione jako rozszerzenie ogólnego interfejsu RecordsClerk, który zarówno userrecordsclerk, jak i CompanyRecordsClerk implementują, a następnie specjalizujemy się na, co oznacza, że można spojrzeć na metody w interfejsie, aby zobaczyć, do czego zazwyczaj służą podklasy its.

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

Myślę, że dopóki twój wzorzec jest dobrze dobrany i używany tak dalece, jak jest to właściwe, to dość nieinwazyjne proste nazwy klas powinny wystarczyć!