Я в свое время (пару лет назад) за 4к купил Xerox Workcentre 3119 (самый маленький на то время лазерный МФУ) — до сих пор работает, не жалуюсь (оф. расходник 3к, но можно купить что-то вроде T2 за 1.5к, а можно и заправлять (нечем, а искать других влом)). Были и дешевле, но размеры для дома совершенно неподходящие (я этот-то зателепался нести).
1. Не до конца понял вас. В моем примере наследование используется только в 3 случаях: «Лилия» extends «Цветок», «Мак» extends «Цветок», «Лилия as Красивая фигня» extends «Красивая фигня» («Красивая фигня» и «Цветок» вполне могут быть как абстрактными классами, так и интерфейсами). Все остальное — использование: внутри метода «старшего» класса просто создается и используется объект используемого класса.
class B
{
function someMethod()
{
$someVar = new C;
}
}
2. Проблема даже не в автозагрузке, а в пересечении названий классов из-за отсутствия namespace'ов.
Хм. Если куки будут называться Response_Cookie, т.к. относятся к Response, то как обозвать тогда динамический отклик (DynamicResponse)? От же не относится к Response в прямом виде (Response его не использует).
Опять же, куда писать какой-нибудь Foobar, который используется ResponseDynamic и ResponseStatic (которые оба наследуются от Response), но не используются самим Response? Выносить как Response_Foobar? Он не используется Response'ом. Вообще наверх, в Foobar? Сдался мелкий класс реализации на самом высоком уровне приложения.
Вот-вот:
1. Имя класса не будет влезать на строчку — критично для распечатанного исходного кода, да и читаемость убивает
2. Вполне ожидаемый вопрос «ШОЗАНАХ?», ибо эта длинная строка ни о чем не говорит, где кончается описание конкретного класса (геттер для рейтинга) и начинаются параметры описания (откуда тырит данные)
3. Автозагрузка классов хромает — обычный принцип «подчеркивание на слеш» не применишь в силу его абсурдности в данном случае, а умничать с ней пока не хочется
Дык они только респонзовые (О_О) Или вы предлагаете в случае появления чего-либо, что будет использовать класс, принадлежащий только одному модулю (и слава богу), этот класс выносить на самый верхний уровень иерархии?
Извините, задумался и забыл ответить. Идея хорошая, но косяк тот же — кроме EduPortal_Application_Rating появился MathSite_Rating — чей геттер EduPortal_Addon_Testing_RatingGetter?
Собственно, вы совершенно правы в структуре классов для столь абстрактной задачи с цветами, но в конкретной системе на PHP присутствует мешанина из префиксов классов вроде MyApplication_MyModule_MyService_SubComponent_ClassName (-_-)
Прекрасно понимаю ваши слова про именование по смыслу. Сам так хочу, но пока стеной стоит вопрос автозагрузки классов и вообще организации классовой структуры по модулям в условиях отсутствия namespace'ов (т.е. единственным идентификатором класса является его имя, которое, естественно, должно быть уникальным).
Вот она-то и проблема: Response_Dynamic наследуется от Response, а Response_Cookie нет, но при беглом взгляде и без кода это понять нельзя. Меня это и натолкнуло на подобный вопрос.
Странное имя вызвано автозагрузкой классов и желанием распихать классы одной «области» в одну директорию. В вашем случае и в стандартах Zend абстрактный класс лучше будет обозвать либо _Getter, либо _Getter_Abstract, т.к. файл BaseGetter.php и папка Getter на быстрый взгляд плохо вяжутся друг с другом.
В Zend нет адаптеров между компонентами из разных систем, вроде модуля фреймворка, модуля чужого сайта и модуля собственной разработки, а мне они пока что нужны (пока я не придумал решения лучше) — см. первый ответ, в нем я дал конкретный пример.
1. Это и стало причиной такого вопроса (^_^) Есть Response, есть DynamicResponse, наследуемый от Response, и есть ResponseCookie, который используется Response. Response_Dynamic и Response_Cookie — ИМХО, глупость, т.к. отличить потомка от класса-помощника невозможно без кода, но других символов-разделителей, кроме подчеркивания, нет (-_-).
2. Нет неймспейсов, хоть и хочется (-_-) (см. предыдущий ответ).
3. Смотрел, сейчас пересмотрю еще внимательней.
Интересует именно именование, т.к. с использованием проблем нет. Могу дать конкретный пример: есть модуль тестирования 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 зависит последний получатель?
Наследование здесь только самое что ни на есть простейшее, например, Response отражает абстрактный отклик, StaticResponse — отклик, тело которого задается в виде строки, и DynamicResponse — отклик, тело которого генерируется во время отправки самого отклика. Все остальное не наследуется, а всего лишь используется (например, класс Response использует класс Cookie для объектного отображения печенек).
