[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Design Patterns
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
VeRTak
user posted image

Продолжайте. В этот раз что-то очень скучно
chee
twin, Между проксёй и декоратором есть фатальное различие. Декоратор, может декорировать другие декораторы, но по факту ты все равно будешь иметь вызовы не декоратора (а именно декорируемого объекта). Если в методе декоратора исключить вызов декорируемого объекта, он сразу станет чем-то другим, но ни как не декоратором. Также если в декоратор добавить новый метод, то это тоже уже будет не декоратор, читай правило которое я написал постами выше.

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


По декоратору все в вики описано, если вчитываться, а не вырывать из контекста.

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
twin
Цитата (Ron @ 4.09.2017 - 18:12)
У тебя разве декоратор добавляет новую функциональность? Я этого не вижу, форматирование текста не является новым функционалом, относительно интерфейса.
Да ешкин кот, ты опять про реализацию. Это просто пример. Кто из нас абстрагироваться не может то. Ну на тебе функциональность:
<?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()
{
$num = rand();
return example::firstMethod() + $num;
}
}
Цитата (Ron @ 4.09.2017 - 18:12)
Если нужен один, то настаиваю, что это НЕ декоратор (по крайней мере).
Я тоже настаиваю на своем. В подписи посмотри)))

Ну давай подождем кто что скажет. А пока, чтоб не скучно было, на тебе другие мнения. Я прям из гугла по порядку:
Тут.
Цитата
При такой структуре нам не важно является ли компонент декоратором или конкретной реализацией, потому как интерфейс у них совпадает, и, как результат, мы можем делать цепочки декораторов.
А можем и не делать.

Тут
Цитата
Динамически добавляет новую функциональность в экземпляры классов.
Ни слова о цепочках, даже в примерах. Кстати, там все захардкожено, и ничего, живут как то люди. :)

Тут Декоратор с проксей. И ни слова про цепочки.

Это, на секундочку, на первой странице выдачи по запросу "паттерн декоратор php".

Так что единого мнения ты не услышишь. Никогда. Потому что еще раз говорю, каждый судит со своей колокольни (читай: согласно корпоративному стилю архитектуры).

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

Я понимаю, что замахнулся на святое. Как же так, паттерн, святая святых ООП, да вдруг без объекта. Но целая куча паттернов применима и применяется не только в ООП.

А примеры сплошь и рядом только с объектами. А где же абстракции, где идеи? Сплошная узурпация. :D



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

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

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

user posted image
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2025 Invision Power Services, Inc.