здесь было уже десятка три холиваров на тему «ООП в ПХП» и всегда сходится к одному мнению, что ооп в этом мусоре как пятая нога, ни реализации, ни применения./blockquote>
Не хочу никого оскорбить, но кто именно высказывал такое мнение? Этот человек/люди имеет опыт программирования на PHP? У него большой опыт программирования в целом? Кто конкретно развел холивар? Школота, купившая инвайт на Хабр за $25 и кричащая «Я — крутой профи», а другие — отстойные недоноски? Это мнение высказывалось аргументировано? Делались сравнения, обобщения, анализ? Или просто так — кинул в пустоту «PHP — гавно» и пошел дальше?
Особенно если учесть, что ооп себя оправдывает в проектах в десятки (а то и сотню) тысяч строк, а судя по современным проектам (стартапам, хе-хе!) таких насчитываются единицы.
То есть, мы говорим уже о том, что ООП вообще не нужен в небольших проектах?
Кстати, а что работа Facebook, Yahoo Bookmarks (Delicious) и Dailymotion на PHP вам недостаточно? Проекты, скажем так, не маленькие. Впрочем, я соглашусь, что сайтов действительно астрономического масштаба на PHP действительно не так уж много. Впрочем, их вообще в мире не так уж много, не так ли?
Почитайте эти холивары, там много чего интересного есть в плане статистики и выводов, которые люди делают. Не говоря о применении, уж реализацию обсосали со всех сторон. Там, в этих постах, и будет опровержение вашего вывода.
Если вы накидаете мне ссылок, я с удовольствием почитаю. Если, конечно, в этих ссылках не говносрач пустой, а какая-то более-менее взрослая дискуссия с аргументами или хотя бы ссылками на мнения уважаемых людей.
Почему же совершенно другого? Вы можете как-то обосновать свое мнение? Что такого «совсем другого» есть в моей реализации? Что, совсем на примесь не похоже? Ни капельки?
Что касается агрегации с делегированием, реализация методов все же требуется. Приведу два примера агрегирования:
class A {
public function hello();
}
class B {
public function hello2();
}
class Aggregator1 {
private $a;
private $b;
public function __construct() {
$this->a = new A();
$this->b = new B();
}
public function hello() {
$this->a->hello();
}
public function hello2() {
$this->b->hello2();
}
}
$test = new Aggregator1();
$test->hello();
$test->hello2();
class Aggregator2 {
public $a;
public $b;
public function __construct() {
$this->a = new A();
$this->b = new B();
}
}
$test = new Aggregator2();
$test->a->hello();
$test->b->hello2();
Второй пример Aggregator2 достаточно неуклюж, правда? Не агрегирование, а кошмар какой-то. С таким же результатом можно отдельные объекты иметь.
А первый пример Aggregator1 для добавления в Aggregator1 реализации новых методов helloX() требует их явного определения. Разве не так? Или я вас не так понял?
и ничего агрегация с делегированием не требует, не выдумывай.
Если не возражаете, я бы вас попросил о более уважительном отношении к собеседнику. Возможно, я вас не понял, но, в таком случае, может быть, вы сможете сделать свою точку зрения более понятной?
Измерять быстродействие чего бы то ни было бессмысленно, если все в этом чем-то было использовано к месту и грамотно. Весь вопрос в том, что нужно измерить быстродействие, а затем, если оно неудовлетворительно, искать вещи, использованные не к месту или неграмотно.
Если бы были на свете программисты, умеющие использовать ВСЕ БЕЗ ИСКЛЮЧЕНИЯ к месту и грамотно, у нас бы не было программ с багами и тормозами.
Да, для каждой примеси внутри объекта-агрегатора создается объект, хранящий состояние примеси. Доступ к этому объекту имеет только слой агрегатора, который отвечает за диспетчеризацию вызовов.
Разумеется, это не настоящая примесь, а только эмуляция, о чем красноречиво говорит заголовок статьи.
Агрегация и делегирование требуют ручной реализации методов агрегированных объектов. В моей реализации все автоматизировано. Агрегация и делегирование — более фундаментальные понятия, чем примесь, которая на них основана. Я бы не стал путать эти понятия.
А преждевременная оптимизация — зло. На фоне запросов к БД вызов магических методов — ерунда, не стоящая внимания. Если, конечно, как я уже говорил, они не вызываются в цикле тысячи раз.
Я уже отмечал, что декоратор сильно отличается от примесей. Примесь — достаточно стандартный подход в программировании, о котором многие знают. Кто интересуется чем-то помимо своего единственного и неповторимого языка программирования, конечно.
Да и вообще, данная статья не ставила своей целью пропаганду использования примесей везде и всюду. Я просто выполнял упражнение по реализации в языке возможности, в нем изначально отсутствующей. Я вовсе не призываю ее широко использовать или вообще использовать. Это просто упражнение. Практикум. Экзерсис :)
Совершенно верно. Что делать, если есть одинаковые функции в примеси и основном классе решает язык. В Ruby я так и не понял, какие правила действуют в данном случае. В моей реализации при конфликте имен будет произведен доступ к полю/методу, примесь которого была помешана первой.
Я не хочу сказать, что это хорошо. Это отвратительно. Неоднозначности и сложности такого рода меня всегда раздражают. Но, в принципе, и без примесей в ООП языках достаточно возможностей, которые легко использовать неправильно.
А вы вообще понятие о правилах приличия имеете? Или вам эго мешает им следовать? Элементарное понятие об уважении, я смотрю, у вас вообще отсутствует.
Что касается агрегации с делегированием, реализация методов все же требуется. Приведу два примера агрегирования:
Второй пример Aggregator2 достаточно неуклюж, правда? Не агрегирование, а кошмар какой-то. С таким же результатом можно отдельные объекты иметь.
А первый пример Aggregator1 для добавления в Aggregator1 реализации новых методов helloX() требует их явного определения. Разве не так? Или я вас не так понял?
Если не возражаете, я бы вас попросил о более уважительном отношении к собеседнику. Возможно, я вас не понял, но, в таком случае, может быть, вы сможете сделать свою точку зрения более понятной?
Если бы были на свете программисты, умеющие использовать ВСЕ БЕЗ ИСКЛЮЧЕНИЯ к месту и грамотно, у нас бы не было программ с багами и тормозами.
Разумеется, это не настоящая примесь, а только эмуляция, о чем красноречиво говорит заголовок статьи.
Агрегация и делегирование требуют ручной реализации методов агрегированных объектов. В моей реализации все автоматизировано. Агрегация и делегирование — более фундаментальные понятия, чем примесь, которая на них основана. Я бы не стал путать эти понятия.
Фабьену тоже руки оторвем? Вместе с Yahoo? :)
Примеси реализованы в таком фреймворке, как Symfony, например. Думаю, мнение Фабьена достаточно весомый аргумент.
Да и вообще, данная статья не ставила своей целью пропаганду использования примесей везде и всюду. Я просто выполнял упражнение по реализации в языке возможности, в нем изначально отсутствующей. Я вовсе не призываю ее широко использовать или вообще использовать. Это просто упражнение. Практикум. Экзерсис :)
Я не хочу сказать, что это хорошо. Это отвратительно. Неоднозначности и сложности такого рода меня всегда раздражают. Но, в принципе, и без примесей в ООП языках достаточно возможностей, которые легко использовать неправильно.