- PHP
- Програмне забезпечення
- ООП
- архітектура додатків
Доброго дня. При розробці однієї системи зіткнувся з питанням іменування класів в складних випадках. Проблема полягає в тому, що в ієрархії класів окремий елемент не завжди має тільки одного «предка» (не тільки в сенсі наслідування ( «квітка успадковується від рослини»), але і в більш загальному «квітка має листочки»). Власне, питання полягає в наступному - за яким правилом іменувати дані елементи?
Кілька прикладів класів, з іменами яких виникає проблема (прошу вибачення за дурні приклади):
- Лілія, що успадковується від квітки (B, успадковані від A)
- Пелюсток, який може бути тільки у лілії (C, який використовується тільки в B)
- Лист, який може бути і у лілії, і у квітки взагалі (D, який використовується і в B, і в A)
- Тичинка, яка може бути і у лілії, і у маку, але необов'язково вона є у квітки взагалі (E, який використовується і F (який, в свою чергу, успадковується від A), і в B, але в A він не використовується )
І крайній випадок: є квартира, в якій є якась красива фігня. Лілію, в принципі, можна використовувати в якості красивою фігні. Як назвати адаптер «Лілія as Красива фігня», щоб він не загубився серед всіх класів (тому що теоретично він належить групі «квартира», але також залежить і від групи «квіти»)? Абстрактно - є G, яка використовує H; як назвати I, який ползволяет використовувати B як H?
Затримка виникла через строго ієрархічної файлової системи і звички називати класи a-la папки (тобто Fuston_Http_Response_Cookie_Marked). Ця звичка якраз і не дає відповіді на питання «як назвати інтерфейс, який дозволить Testing_Database_Cache_Cookies використовувати сторонній клас Fuston_Http_Response_Cookie як свій власний Testing_Database_Cache_Cookies_Cookie?».
Спадкування тут тільки саме що ні на є найпростіше, наприклад, Response відображає абстрактний відгук, StaticResponse - відгук, тіло якого задається у вигляді рядка, і DynamicResponse - відгук, тіло якого генерується під час відправки самого відгуку. Все інше не успадковується, а всього лише використовується (наприклад, клас Response використовує клас Cookie для об'єктного відображення печенек).
Цікавить саме іменування, тому що з використанням проблем немає. Можу дати конкретний приклад: є модуль тестування EduPortal_Addon_Testing з купою класів всередині, і є модуль рейтингу EduPortal_Application_Rating, теж, як не дивно, з купою класів всередині. Я хочу додати функцію використання в якості рейтингу даних з тестування. У мене в рейтингу є абстрактний одержувач даних EduPortal_Application_Rating_Getter_Abstract і одержувач даних безпосередньо від клієнта EduPortal_Application_Rating_Getter_Wui. Зазвичай роблять так: створюють одержувач для модуля тестування, в який згодовують об'єкт з пакета EduPortal_Addon_Testing (неважливо, самий головний EduPortal_Addon_Testing_Core, у якого буде API для отримання даних, або ж спеціальний окремий клас-API для цієї ж функції). Як назвати цей одержувач (мова PHP)? EduPortal_Application_Rating_Getter_EduPortal_Addon_Testing? EduPortal_Application_Rating_Getter_EduPortalAddonTesting? EduPortal_Application_Rating_Getter_Testing? Останній здається ідеальним, але що, якщо з'явиться MathSite_Testing? Від якого Testing залежить останній одержувач?
EduPortal_Application_Rating_Getter_Abstract - дивне ім'я. Навіщо дописувати Abstract в кінці, якщо у класу в сигнатурі вже абстрактність? Не знаю, як у вас в PHP прийнято, але я б назвав EduPortal_Application_Rating_BaseGetter.
А одержувач з Testing - він, хіба, не належить логічно до самого модулю Testing? Якщо так - то чому б його туди не помістити і не назвати: EduPortal_Addon_Testing_RatingGetter?
Дивне ім'я викликано автозавантаженням класів і бажанням розіпхати класи однієї «області» в одну директорію. У вашому випадку і в стандартах Zend абстрактний клас краще буде обізвати або _Getter, або _Getter_Abstract, тому що файл BaseGetter.php і папка Getter на швидкий погляд погано в'яжуться один з одним.
Ось ось:
1. Ім'я класу не буде влазити на сходинку - критично для роздрукованого вихідного коду, та й читаність вбиває
2. Цілком очікуваний питання «ШОЗАНАХ?», Бо ця довга рядок ні про що не говорить, де кінчається опис конкретного класу (геттер для рейтингу) і починаються параметри опису (звідки тирить дані)
3. Автозавантаження класів кульгає - звичайний принцип «підкреслення на слеш" не застосуєш в силу його абсурдності в даному випадку, а мудрувати з нею поки не хочеться
Ну в моєму варіанті якраз через пункт 2 в одному місці стоять два підкреслення - там, де закінчується повне ім'я Getter'а і починається ім'я пов'язаного класу.
А взагалі, мені все одно здається, що нормальним ім'ям було б:
EduPortal_Application_Rating_AddonTestingGetter, а ще краще юзати неймспейси.
Якщо у вас технічні проблеми і так зробити не виходить - прийдеться вам мучитися з незрозумілими довгими рядками ... що ж, привід подолати технічні проблеми;)
1. Ні в якому разі не називайте класи Родітель_діте_ итд
2. Використовуйте неймспейси, це позбавить від уродское назв
3. Подивіться на іменування класів в Зенден (бенкеті), логіка тамтешніх назв говорить сама за себе
Якщо будете триматися цих трьох пунктів, то ніколи не заблукаєте =) і назви будуть красиві і структурна логіка буде завжди зрозуміла.
1. Це і стало причиною такого питання (^_^) Є Response, тобто DynamicResponse, успадковані від Response, і є ResponseCookie, який використовується Response. Response_Dynamic і Response_Cookie - ІМХО, дурість, тому що відрізнити нащадка від класу-помічника неможливо без коду, але інших символів-роздільників, крім підкреслення, немає (-_-).
2. Ні неймспейсов, хоч і хочеться (-_-) (див. Попередній відповідь).
3. Дивився, зараз перегляну ще уважніше.
У Zend немає адаптерів між компонентами з різних систем, на кшталт модуля фреймворка, модуля чужого сайту і модуля власної розробки, а мені вони поки що потрібні (поки я не придумав рішення краще) - див. Першу відповідь, в ньому я дав конкретний приклад.
/ library
/ Responce /
/AbstractResponse.php
/Dinamic.php
/Cookie.php
Класи називатися будуть приблизно:
Responce_Dinamyc і Responce_Cookie
Я б зробив так.
А щодо квіток і пелюсток Ви мали рацію
/ Library /
/ Flower
/Petal.php
/Flower.php
І класи відповідно:
Flower і Flower_Petal (тут вже логіка не один з батьків - спадкоємець, а співвідношення об'єкт до подобьекту)
Ось вона-то і проблема: Response_Dynamic успадковується від Response, а Response_Cookie немає, але при побіжному погляді і без коду це зрозуміти не можна. Мене це і наштовхнуло на подібне питання.