Я наведу кілька уривків із «Шаблонів реалізації» Кента Бека:
Просте ім'я суперкласу
"[...] Імена повинні бути короткими і проникливими. Однак для точності імен іноді, здається, потрібно кілька слів. Виходом з цієї дилеми є вибір сильної метафори для обчислення. З урахуванням метафори навіть окремі слова приносять із собою багату мережу асоціацій, зв’язків та наслідків. Наприклад, у рамках малювання HotDraw моє перше ім’я для об’єкта на малюнку було
DrawingObject . Уорд Каннінгем прийшов разом із метафорою типографіки: малюнок схожий на роздрукована, викладена сторінка. Графічні елементи на сторінці - це цифри, тому клас став малюнком . У контексті метафори малюнок
одночасно коротший, багатший і точніший, ніж DrawingObject . "
Назва кваліфікованого підкласу
"Імена підкласів мають дві роботи. Вони повинні повідомляти, яким вони є класом, і чим вони відрізняються. [...] На відміну від імен у коренях ієрархій, імена підкласів використовуються майже не так часто в розмові, тому вони можуть бути виразними ціною стислості. [...]
Дайте підкласам, що служать корінням ієрархій, власні прості імена. Наприклад, HotDraw має клас Handle, який представляє операції редагування малюнків, коли вибрано фігуру. Це називається, просто, Handle,
незважаючи на розширення малюнка . Існує ціле сімейство ручок, і вони найбільш доречно мають такі назви, як
StretchyHandle та TransparencyHandle . Оскільки Handle є коренем власної ієрархії, він заслуговує простого імені суперкласу більше, ніж імені кваліфікованого підкласу.
Ще однією складкою при іменуванні підкласів є багаторівневі ієрархії. [...] Замість того, щоб наосліп додавати модифікатори до безпосереднього суперкласу, подумайте про назву з точки зору читача. До якого класу він повинен знати, що це за клас? Використовуйте цей суперклас як основу для назви підкласу. "
Інтерфейс
Два стилі імен інтерфейсів залежать від того, як ви думаєте про інтерфейси. Інтерфейси як класи без реалізації повинні бути названі , як якщо б вони були класи ( Simple суперклас , Кваліфіковані Підклас Ім'я ). Однією з проблем цього стилю імен є те, що добрі імена витрачаються до того, як перейти до класів іменування. Інтерфейсу під назвою File потрібен клас реалізації, який називається щось на зразок
ActualFile , ConcreteFile або (yuck!) FileImpl(як суфікс, так і абревіатура). Взагалі, важлива інформація про те, чи маєш справу з конкретним або абстрактним об’єктом, чи реалізований абстрактний об’єкт як інтерфейс чи суперклас, менш важливий. Відкладання відмінностей між інтерфейсами та суперкласами добре> підтримується цим стилем іменування, дозволяючи вам змінити свою думку згодом, якщо це> стане необхідним.
Іноді найменування конкретних класів просто важливіше для спілкування, ніж приховування використання інтерфейсів. У цьому випадку префікс назв інтерфейсів слід вводити з “I”. Якщо інтерфейс називається IFile , клас можна просто назвати File .
Для більш детального обговорення придбайте книгу! Воно того варте! :)