Добрый день. При разработке одной системы столкнулся с вопросом именования классов в сложных случаях. Проблема заключается в том, что в иерархии классов отдельный элемент не всегда имеет только одного «предка» (не только в смысле наследования («цветок наследуется от растения»), но и в более общем «цветок имеет листики»). Собственно, вопрос заключается в следующем — по какому правилу именовать данные элементы?
Несколько примеров классов, с именами которых возникает проблема (прошу прощения за дурацкие примеры):
— Лилия, наследуемая от цветка (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?».
class Leaf {} // лист
class Thorn {} // шип (т.к. тычинка вроде как у всех цветковых есть)
class Flower // цветок
{
Leaf[] leaves;
}
interface Thorny // с шипами
{
Thorn[] thorns;
}
class LilyPetal {} // лепесток лилии
interface CuteThing {} // красивая фигня
// лилия — шипастый цветок, да и к тому же, красивая фигня
class Lily : Flower, Thorny, CuteThing
{
LilyPetal[] petals;
}
class Apartment // квартира
{
CuteThing[] things;
}
По поводу именования файлов в стиле:
«как назвать интерфейс, который позволит Testing_Database_Cache_Cookies использовать посторонний класс Fuston_Http_Response_Cookie как свой собственный Testing_Database_Cache_Cookies_Cookie?»
… то непонятно, зачем это вообще нужно. Особенно учитывая, что зачастую это невозможно.
Название класса должно кратко описывать сущность, а не говорить об особенностях внутреннего устройства.
Прекрасно понимаю ваши слова про именование по смыслу. Сам так хочу, но пока стеной стоит вопрос автозагрузки классов и вообще организации классовой структуры по модулям в условиях отсутствия namespace'ов (т.е. единственным идентификатором класса является его имя, которое, естественно, должно быть уникальным).
Собственно, вы совершенно правы в структуре классов для столь абстрактной задачи с цветами, но в конкретной системе на PHP присутствует мешанина из префиксов классов вроде MyApplication_MyModule_MyService_SubComponent_ClassName (-_-)
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.