Что тут можно сказать? У каждого своя методика (само)обучения. Я придерживаюсь классической схемы: сначала теория, затем практика.

Зачем тебе не знаю, а мне для расширения кругозора. Чтобы не выглядеть дубиной в приличном обществе, хотя бы для этого. Если рассматривать более сложную идею, то для наращивания потенциала, для эффективных умозрительных изысканий. Теория порождает теорию, на голой практике никуда не уедешь. А ты спрашиваешь зачем раньше, даже странно. Чем раньше научишься тем лучше!

Код еще неизвестно кто пишет, а теория, обычно, выдвигается довольно видными деятелями ИТ, как правило высокообразованными. Теория не привязана к ЯП + многие вещи в опенсорс попросту не попадают, особенно в сообществе PHP, про который и поговаривают типа "ты все еще указываешь в резюме знание PHP? Тебе не стыдно?" и т.д. Так что искать в чужом PHP коде особую мудрость занятие весьма неблагодарное. Разве что из крупных проектов, типа Symfony, но их читать заимеешься, пока найдешь (идею) решение своей задачи в виде кода, не зная теории. Ищу то не знаю что. Охрененная тактика, нечего сказать!

От этого он не стал твиноратором, вот в чем соль! Еще раз повтоюсь: паттерны это алгоритмы, они не зависят от реализации. В книгах приводится один из примеров, обычно максимально абстрактный.

Должно было стать грустно. =)

Для меня может и стал. Глубоко наплевать, как называется.

От чего грустить то... Вот сейчас оказывается, что это вовсе не декоратор, как chee сказал. И ты знаешь, эта штука хуже работать не стала, я специально проверил.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Не понял о чем ты, но суть примерно такая:

<?php

class example
{

    public static function firstMethod()
    {  
        return 1;
    }
    
    public static function secondMethod()
    {
        return 2;
    }
}

class twinorator
{

    public static function __callStatic($method, $arguments)
    {
        return example::$method($arguments);
    }
    
    public static function secondMethod()
    {
        return '<b>'. example::secondMethod() .'</b>';
    }
}


    echo twinorator::firstMethod();
    echo twinorator::secondMethod();

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Речь ведь о приоритетах была? Или я чего-то упустил?

То есть иными словами наплевать что о тебе подумают люди, когда вместо общепринятого названия начнешь объяснять сложными фразами суть решения. Тебе скажут, так это ж декоратор! А ты им: "мне плевать". Так что ли? Не думаю что получится оставить о себе благоприятное впечатление. Тем хуже будет, если выдавать чужие достижения за свои наработки, тем более хорошо известные. Тут люди могут даже обозлиться под соусом "за кого он нас принимает".

Не понимаю, чего ты хочешь доказать, упорно настаивая, что невежество не является чем-то зазорным. Мне эти знания (заранее) не нужны; плевать как называются общепринятые и широкоизвестные в специальности вещи; я и сам сусам. Да? Искренне не понимаю этот месседж.

Он сделал предположение, попросил уточнений. Прокся и декоратор вещи настолько похожие, что декоратор можно считать серией последовательно вызванных проксей в указанном порядке. И то и другое от одного и того же интерфейса реализуется обычно. Юз кейс декоратора оч простой, например динамическая агрегация или фильтрация (данных). Другое дело, что этот функционал стараются спихнуть по максимуму на СуБД.

Твин, в твоем примере самое обычное делегирование. Здесь вообще нет никакого паттерна, максимум прокся, ито какая-то убогая.

Ну ты же сам говорил, что паттерн, это не реализация, а идея. Идея декоратора, на сколько я понял, изменить часть функционала на изменяя интерфейса. Его еще враппером называют. Оберткой. Просто вы привыкли, что обернуть можно только объект. А почему?

В том коде, что я написал, что не так? Интерфейс сохранился, часть функционала изменилась (причем не переопределилась, а именно изменилась, дополнилась). Идея вроде не нарушена. А реализация - моё право.

Прокся там есть внутри, но в ваших декораторах она тоже используется. Не обязательно выносить сюда все методы. Делегирование, это то, что chee подумал. Если бы в классе были другие публичные методы, то да - делегирование. А тут интерфейс сохранен. Объясни в чем претензия. Может в том, что я тут прямой вызов написал, без call_user_func_array(), но это тоже реализация. К идее отношения не имеет... Растолкуй невежде, раз ты все понимаешь.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Просто здесь нет контракта раз и в примере прокся два. Раз уж реализацию не обсуждаем, тогда ладно, готов согласиться на проксю. Действительно, реализация дело каждого.

Боже упаси, я далеко не всё понимаю. Буду благодарен за некоторые по части общеизвестных/общепринятых моментов.

Контракт тут причем... Это тоже тонкости реализации.

Э, нет. Так не пойдет. Я все же настаиваю, что это декоратор чистой воды. Для пущей важности готов убрать проксю и добавить контракт, хотя терпеть их не могу:

<?php

interface exInterface
{
    public static function firstMethod();
}

class example implements exInterface
{
    public static function firstMethod()
    {  
        return 1;
    }
}

class twinorator implements exInterface
{
    public static function firstMethod()
    {
        return '<b>'. example::firstMethod() .'</b>';
    }
}


    echo example::firstMethod();   
    echo twinorator::firstMethod();

Что тут не так?

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Декоратор подразумевает нечто вроде цепочки вызовов, которая определяет последовательность. Я ее тут не вижу, в последнем примере это опять же прокся для example. Получается последовательность определена в методах, а это ниразу не декоратор, так себя не ведет даже прокся, которой передается инстанс объекта делегирования типа интерфейс. То есть заранее не известно куда будет делегирование. У тебя это хардкодится, так что даже прокся получается хреновая. Захочешь подменить класс Examle на NewExample и чего, лазить по всем методам переписывать вызовы? Главное днамики нет. =( Да, понимаю, IDE может выполнить сию задачу, ок, отняли у тебя среду разработки или сглючила она, не знаю, срочно из консоли нужно подменить на тестовую версию NewExample ситуаций масса.

В идеале объекты (классы) не должны ничего друг о друге знать, кроме интерфейса, никаких названий класса. Тогда получается для декоратора в твоем случае нужно передавать в первый метод (вызова) массив, содержащий цепочку и на каждой "итерации" выбивать из него имя текущего класса. Так получится, но опять же убого, почему просто не использовать объекты, в чем сложность?

Интерфейсы нужно любить, потому что они являют собой нечто вроде документации, далеко не всегда реализуются только методы интерфейса, часто есть дополнительные. Как потом выискивать что именно относится к контракту, чтобы не поломать проект? Понадобился еще один полиморфный объект/класс и чего делать? Долго выяснять, а так заглянул в интерфейс и всё понятно становится. Кроме того будет выброшена фатальная ошибка раз и IDE будет орать два. Можно сразу сгенерировать заголовки методов контракта. Удобно это, что не говори.

Или нет? Тогда прошу подключиться других участников к беседе, все мы люди, я тоже могу ошибаться, думаю мне никто не откажет в этом праве?

Нет, не подразумевает. Есть такая штука, можно тоже паттерном обозвать. Она так и называется - цепочка декораторов. Но суть самого декоратора тут соблюдена.

Нет, это не прокся. Прокся просто передает управление, а тут изменяется функционал. Причем не просто изменяется, а дополняется. Если в декорируемом классе заменить 1 на 2, декоратор завернет в теги двойку. Тоесть он не переопределяет метод основного класса, тот работает как обычно. Декоратор дополняет результат своей спецификой.

Нет тут никакой последовательности. Это просто обертка. Враппер. Декоратор.

Это опять про цепочку, но можно и это сделать, если так нужна последовательность. Ведь по сути ты в переменной передаешь вовсе не объект, а ссылку на него. Ни кто мне не помешает передать, так же как ссылку, строку с адресом класса. Но еще раз повторю - я говорю не про цепочку декораторов, а именно про декоратор. Обертку. Я всегда раньше называл это оберткой. Оказалось - это целый паттерн, да еще и с красивым названием.

Может ты и прав, в светских беседах это может дать какй то профит, что я теперь знаю его название. Но в программировании это не дает ровным счетом ничего.

Стопэ. Куда поехал))) Это вообще не важно, это реализация. Пусть у меня трижды говнокод и я не смогу ничего подменить, но декоратором это быть не перестает.

Про интерфейсы отдельная тема, с этим пока не разобрались.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

У тебя интерфейс тот же, то есть суть прокси. Поведение вовсе тут не при чем, это полиморфизм: возможность изменять поведение без изменения интерфейса (то есть без влияния на объект-клиент). Эт не паттерн, но принцип.

Сами названия для разработчика одиночки, который ни с кем никогда не общается конечно же не важны, главное суть.

Ты сам говорил, что нельзя воспринимать паттерны по примерам. А вот я тебе сюда прям выдержки из вики:
Декоратор.

А вот про прокси:

У декоратора тоже должен быть такой же интерфейс. не в этом суть.

Прокси не меняет функционал, в сотый раз говорю. В том и различие.

Ну так какие же они идентичные?

А про цепочку, я уже говорил. Не важно, захардкожены ссылки или я строкой передам, это к идее отношения не имеет. Если мне не нужно несколько декораторов, один только нужен. Причем тут цепочка.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Ты послушай тот вебинарчик)) Там чувак про это как раз и говорил. Внутри команды можно называть это как угодно. В светских беседах и на собеседованиях - да. Можно блеснуть. Теоретически. Но кроме ЧСВ это ничего не даст. Практического применения этому мало. Суть да, важна. А названия, диаграмы эти, примеры... Только запутать могут. Вот мы сейчас черти скока времени не можем придти к общему знаменателю. Оба знаем название паттерна. Оба читали о нем в разных источниках. И что? Это как то помогло нам найти общее видение паттерна? Хрентотам. И в команде тоже самое. Важен стиль архитектуры, а не эта теоретическая мишура.

Вот мы называем это декоратором. Ты пришел, и говоришь - не. Это прокся. Начался холивар. Где тут ускорение разработки и слаженность комманды?

А вот если ты пришел, а тебе говорят - это твиноратор. И всё, инцидент исчерпан в зародыше. Начинаем работать.

Так что как еще посмотреть, где лучше, где хуже. Я давно говорил, сколько программистов, столько и мнений. И никакими названиями и примерами этого не упорядочить. Только практика поможет.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Если нужен один, то настаиваю, что это НЕ декоратор (по крайней мере).

Давай так, мы похоже столкнулись по терминологии/восприятию. Я с места не сойду, ты, видимо, тоже. Предлагаю спросить у господ форумчан, скилловых естественно, что они думают по поводу нашего спора. Не в целом, а конкретно прокси vs декоратор, когда речь не идет о "цепочках" (которые твин берет и выбрасывает из паттерна, хотя они являют суть и главное отличие от прокси).

Потому что мы спорим о тонкостях абстрактных вещей, чего делать не нужно. Структурно эта пара идентична, но декоратор подразумевает цепочки. Всё-таки, ну я так считаю, ты считаешь иначе, повод нашей полемики ерундовый, если так работать в команде она с места не сдвинется, вот что я тебе скажу. Не по паттернам будем спорить, так по другим поводам, мы не работаем в команде а уже коснулись целого пласта проблем. Так нельзя в любом случае если о команде речь.