Moim zdaniem nazwa jednostki nie powinna przekazywać informacji o jej strukturze typu, ale o jej semantyce. Dlatego nie ma sensu definiować swojej klasy jako „AbstractSomething”, jeśli abstrakcja nie jest częścią jej celu działania. To, że jest to podstawowa klasa abstrakcyjna, jest widoczne dla programisty i nie musi być odzwierciedlone w nazwie.
Jeśli jednak idealnie nadaje się do nazywania implementacji fabryki abstrakcyjnej nazwą AbstractFactory, ponieważ ma to związek z intencją klasy.
Ogólnie rzecz biorąc, preferuj konwencję nazewnictwa, która pomaga przekazać jak najwięcej informacji o celu twojej klasy.
Podobnie, trzymaj się z dala od SomethingImpl. Nie obchodzi nas, że jest to implementacja, a nie klasa podstawowa. Jeśli twoja hierarchia klas jest odpowiednio zaprojektowana do dziedziczenia, to ktoś może ją odziedziczyć. Z pewnością nie byłoby w nich żadnej wartości dodającej więcej sufiksów „Impl” lub innych artefaktów. Dodanie sufiksu „Interfejs” lub prefiksu „I” również nie ma żadnej wartości.
Rozważać:
IVehicle <-- IMotoredVehicle <-- AbstractCar <-- CarImpl
W przeciwieństwie do:
Vehicle <-- MotoredVehicle <-- Car <-- DefaultCar
<-- Ferrari
<-- Trabi
Zdecydowanie wolę ten drugi.
To w pewnym sensie podobny do rażącym nadużyciem z notacja węgierska ten ostatni dał mu swoją złą reputację , jak ludzie zaczęli błędnie interpretują go jako wymagające deweloperom poprzedzić ich zmienne ze wskaźnikiem typu zmiennej. Chociaż może to czasem mieć swoje zastosowania (głównie, jeśli jesteś leniwy, aby sprawdzić definicję typu), jest to w większości bezużyteczne. Oryginalnym pomysłem Simonyi z notacją węgierską było użycie go jako mnemonika, aby przypomnieć twórcy o możliwościach jednostki, a nie jej rodzaju.