Niezręczne, otwarte pytanie, ale to problem, z którym zawsze się spotykam:
Oprogramowanie, które jest łatwe w utrzymaniu i obsłudze, jest dobrze zaprojektowane. Próba uczynienia projektu intuicyjnym oznacza nazywanie komponentów w taki sposób, aby następny programista mógł móc wywnioskować ich działanie. Dlatego nie nazywamy naszych klas „Type1”, „Type2” itp.
Podczas modelowania koncepcji rzeczywistej (np. Klienta) jest to na ogół tak proste, jak nazywanie swojego typu po modelowaniu koncepcji rzeczywistej. Ale kiedy budujesz abstrakcyjne rzeczy, które są bardziej zorientowane na system, bardzo łatwo zabraknie imion, które są zarówno łatwe do odczytania, jak i łatwe do strawienia.
Gorzej (dla mnie), gdy próbuję nazwać rodziny typów, z typem bazowym lub interfejsem, który opisuje, co muszą zrobić komponenty, ale nie sposób ich działania. To naturalnie prowadzi do każdego typu pochodzącego próbuje opisać smak realizacji (np IDataConnection
oraz SqlConnection
w .NET Framework), lecz jak można wyrazić coś skomplikowane jak „działa przez odbicie i szuka konkretnego zestawu atrybutów”?
Potem, kiedy już w końcu wybrał nazwę typu uważasz opisuje to, co próbuje zrobić, twój kolega pyta „WTF czy to DomainSecurityMetadataProvider
faktycznie zrobić? ”
Czy są jakieś dobre techniki wyboru dobrej nazwy dla komponentu lub jak zbudować rodzinę komponentów bez uzyskiwania mętnych nazw?
Czy są jakieś proste testy, które mogę zastosować do nazwy, aby lepiej wyczuć, czy nazwa jest „dobra” i czy powinna być bardziej intuicyjna dla innych?
Odpowiedzi:
Jeśli chodzi o nazewnictwo, sprawdzono dla mnie sześć technik :
PS. W przypadku, gdy Twój interfejs API będzie publiczny, powyższe ma zastosowanie wcześniej - ponieważ wiesz,
źródło
Mój test podstawowy polega na tym, czy możesz opisać funkcję zmiennej, używając tylko słów ze zmiennej:
Istnieją jednak niuanse, które różnią się w zależności od osoby:
Więc moim rozszerzonym testem jest zapisanie zmiennej na tablicy / wiki / chat i niech ludzie zgadną, co to znaczy.
źródło
Nie całkiem.
Jedną wskazówką jest jednak unikanie „głosu pasywnego”.
„DomainSecurityMetadataProvider” jest pasywny. Nie ma czasownika, wszystkie rzeczowniki i rzeczowniki są używane jako przymiotniki.
„ProvideMetadataForDomainSecurity” jest bardziej aktywne. Jest czasownik.
Programowanie obiektowe to wszystko (naprawdę) czasownik. Rzeczownik == obiekt. Czasownik == metoda. Tak więc nazwa klasy jest na ogół bardzo „rzeczownikowa”. Przełamanie tego nawyku i rozpoczęcie wstawiania czasowników jest trudne.
Tak. Zdefiniowałeś doskonały test w swoim pytaniu. Zapytaj innych ludzi.
W dawnych czasach nazywaliśmy to „poradnikiem projektowym”. To była wielka, spocona transakcja w metodyce wodospadu. W dzisiejszych czasach, dzięki metodom zwinnym, powinna być zwykła współpraca między autorem a użytkownikami klasy. To nie zajmuje (i nie powinno) długo. Omówienie projektu (i nazw) przed napisaniem testów (i kodu) zmniejszy czynnik zdziwienia i może zapobiec WTF.
źródło
ProvideMetadataForDomainSecurity
to kiepska nazwa. Nazwy metod są zazwyczaj o wiele łatwiejsze do nazwania dokładnie, ponieważ mogę swobodnie używać czasowników. Istotą problemu jest ograniczenie języka.Korzystanie z tezaurusa
Bardzo często będę odnosił się do tezaurusa, kiedy robię nowy rozwój, aby znaleźć odpowiednie słowa do opisania moich klas i metod.
Klasy, które przede wszystkim zawierają logikę operacji
Zazwyczaj nazywam klasy, które przede wszystkim zapewniają metody działania w strukturze czasownikowej, np. „EntityProvider”, „EntityLocator” itp.
Te klasy na ogół nie zawierają dużo stanu.
Klasy zawierające stan
Ekrany interfejsu użytkownika i jednostki danych są na ogół stanowe, więc po prostu nazywam te klasy wzorcem rzeczownikowym lub przymiotnikowo-rzeczownikowym.
Przykłady: osoba, pracownik, obecny pracownik, były pracownik
Klasy użyteczności
Klasy, które zawierają tylko metody statyczne, są ogólnie uważane za klasy „użytkowe”, więc konsekwentnie nazywam je sufiksem „Użyteczność”.
Przykłady: NetworkUtilities, FileUtilities
Testy
Nie mam dobrych testów pozwalających stwierdzić, czy coś jest źle nazwane, ale sugerowałbym, aby spróbować użyć pojedynczego rzeczownika i / lub pojedynczego czasownika w nazwie, a następnie zastanowić się, czy rzeczownik / czasownik dokładnie opisuje to, co „ zmiana nazwy.
Jeśli uważasz, że w klasie / metodzie jest coś więcej, co nie jest przechwytywane przez nazwę, wówczas może być konieczne ponowne przetworzenie tej klasy / metody.
Alan Green i Jeff Attwood pisali o złu nazywania klas za pomocą sufiksu „Manager”. Twierdzą, że termin „menedżer” jest nadużywany i jest zbyt niejasny, aby przekazać coś sensownego. Muszę się zgodzić.
Artykuł Jeffa zawiera także listę sugerowanych wskazówek z Kodeksu ukończonego przez Steve'a McConnella.
zmienne
Ostatnio eksperymentowałem z dłuższymi opisowymi nazwami zmiennych / parametrów, które zawierają przyimki, takie jak „Of”, „By”, „For” itp. Niektóre przykłady pokazano poniżej:
Uważam, że działa to dobrze z funkcją inteligencji Visual Studio, która ułatwia wpisywanie tych długich nazw. Zauważyłem również, że mniej powielania prefiksów nazw zmiennych (np. PersonID, personFirstName, personLastName vs. idOfPerson, firstNameOfPerson, lastNameOfPerson), zapewniając lepsze „hash”, dzięki czemu intellisense jest jeszcze bardziej użyteczny.
źródło
List
, tablicaIEnumerable
lubConcurrentQueue
. To kilka identyfikatorów, które muszę wymienić, a szczegóły dotyczące sposobu ich przechowywania są niepotrzebnym bagażem psychicznym. Chociaż ogólnie zgadzam się, że jeśli dłuższa nazwa jest znacznie bardziej opisowa, należy ją faworyzować w stosunku do krótszej, mniej wyraźnej nazwy.Jakiej nazwy oczekujesz dla klasy złożonej i specyficznej dla domeny? Jest to tak dobre, jak to będzie możliwe, bez nadawania nazwy klasie zdania (co sprawi, że wszyscy będą myśleć, że zbyt wiele odpowiedzialności spoczywa na jednej klasie)
Rozważę usunięcie dostawcy z nazwy. Jeśli konkretnie wspomina o metadanych, wszyscy już wiedzą, że używasz refleksji. Możesz sprawić, by jedno słowo było bardziej zwięzłe (lub ewentualnie zmienić na inne słowo - jest bardziej konsumentem niż dostawcą z tego, co napisałeś)
źródło
ISecurityMetadataProvider
interfejs, który istnieje punkt iniekcyjny w infrastrukturze bezpieczeństwa, w celu dostarczania informacji do podsystemu. Nazewnictwo jest trudne.DomainSecurityMetadataProvider
dostawcęDomainSecurityMetadata
obiektu, w którymDomainSecurityMetadata
same metadane. Jasna i zrozumiała nazwa. Nie muszę nawet wiedzieć, coDomainSecurityMetadata
to jest! To tylko jakiś obiekt, który zapewnia ten dostawca. Samo usunięcieProvider
sufiksu nie poprawia czytelności, ale wręcz przeciwnie - zmniejsza go. Bez tego przyrostka pomyślałbym, że to tylko niektóre metadane (obiekt kontenera dla niektórych metadanych), ale nie obiekt, z którego można uzyskać metadane (dostawca).Użyj metafor do opisania części systemu. Nie tylko pozwoli ci odkryć nowe analogie, ale także ułatwi nazewnictwo.
(Wiem, że to nie jest mocny przykład, ale mimo to) Na przykład możesz wywołać zmienną lub typ as
mailbox
, który służy jako kolejka dla odebranych wiadomości dla klasy.źródło
Jedną rzeczą, na której jestem bardzo stanowczy, jest to, że NIGDY nie powinno się dopuszczać do niepoprawności. Najlepszy przykład, podczas niektórych przefakturowań wiele się zmieniło, a kilka zmiennych zaczęło odnosić się do czegoś innego niż sugerowały ich nazwy.
Wkrótce jeden programista spędził wiele lat i korzystał z bardzo drogich wywołań bazy danych, próbując zdobyć pewne dane, które zostały już wyodrębnione i zapisane. Zmieniłem nazwę wszystkiego i nagle mogliśmy usunąć tonę skomplikowanej i błędnej logiki.
źródło
Mam nadzieję, że przypadki, w których trzeba tak mocno myśleć o nazwiskach, są rzadkie. Gdy pojawią się takie przypadki, po prostu napisz akapit wyjaśniający, co robi klasa. W przeciwieństwie do komentarzy w funkcji lub komentarza na poziomie funkcji, główny cel klasy rzadko się zmienia, więc ryzyko przedawnienia komentarzy jest stosunkowo niewielkie. Masz więc luksus pisania kilku akapitów lub nawet rysowania ASCII, aby wyjaśnić, co robi klasa.
źródło