Zacytuję kilka fragmentów z Implementation Patterns autorstwa Kenta Becka:
Prosta nazwa nadklasy
„[…] Nazwy powinny być krótkie i mocne. Jednak, aby nadać im precyzję, czasami wydaje się, że wymaga kilku słów. Wyjściem z tego dylematu jest wybranie mocnej metafory do obliczenia. Mając na uwadze metaforę, nawet pojedyncze słowa niosą ze sobą bogatą sieć skojarzeń, powiązań i implikacji. Na przykład we frameworku rysunkowym HotDraw moim pierwszym imieniem dla obiektu na rysunku było
DrawingObject . Ward Cunningham pojawił się wraz z metaforą typograficzną: rysunek jest jak wydrukowana, rozłożona strona. Elementy graficzne na stronie to figury, więc klasa stała się Figure . W kontekście metafory Figure
jest jednocześnie krótsza, bogatsza i dokładniejsza niż DrawingObject ”.
Kwalifikowana nazwa podklasy
„Nazwy podklas mają dwa zadania. Muszą komunikować, jaka jest klasa i czym się różnią. […] W przeciwieństwie do nazw u korzeni hierarchii, nazwy podklas nie są używane prawie tak często w rozmowie, dzięki czemu mogą być wyraziste kosztem zwięzłości. [...]
Nadaj podklasom, które służą jako korzenie hierarchii, własne proste nazwy. Na przykład HotDraw ma klasę Handle, która przedstawia operacje edycji figury, gdy figura jest zaznaczona. Nazywa się po prostu Handle,
pomimo rozszerzenia rysunku . Istnieje cała rodzina uchwytów i najlepiej nadają się one do nazw takich jak
StretchyHandle i TransparencyHandle . Ponieważ Handle jest korzeniem własnej hierarchii, zasługuje na prostą nazwę nadklasy bardziej niż kwalifikowaną nazwę podklasy.
Kolejnym problemem w nazewnictwie podklas są wielopoziomowe hierarchie. […] Zamiast ślepo dołączać modyfikatory do bezpośredniej nadklasy, pomyśl o nazwie z perspektywy czytelnika. Jakiej klasy powinien wiedzieć, że są takie zajęcia? Użyj tej nadklasy jako podstawy dla nazwy podklasy. "
Berło
Dwa style nazywania interfejsów zależą od tego, jak myślisz o interfejsach. Interfejsy jak klasach bez implementacji powinny być nazwane tak, jakby były zajęcia ( Proste Nadklasa Nazwisko , kwalifikowana Podklasa Nazwa ). Jednym z problemów związanych z tym stylem nazewnictwa jest to, że dobre nazwy są używane, zanim przejdziesz do nazewnictwa klas. Interfejs o nazwie File wymaga klasy implementacji o nazwie
ActualFile , ConcreteFile lub (fuj!) FileImpl(sufiks i skrót). Ogólnie rzecz biorąc, ważne jest informowanie, czy mamy do czynienia z konkretnym, czy abstrakcyjnym obiektem, mniej ważne jest to, czy abstrakcyjny obiekt jest zaimplementowany jako interfejs, czy jako nadklasa. Odradzanie rozróżnienia między interfejsami i nadklasami jest dobrze> obsługiwane przez ten styl nazewnictwa, co pozwala na późniejszą zmianę zdania, jeśli okaże się to konieczne.
Czasami nazywanie konkretnych klas jest po prostu ważniejsze dla komunikacji niż ukrycie użycia interfejsów. W tym przypadku nazwy interfejsów należy poprzedzić literą „I”. Jeśli interfejs nosi nazwę IFile , klasę można po prostu nazwać File .
Aby uzyskać bardziej szczegółową dyskusję, kup książkę! To jest tego warte! :)