Как же вы все одинаковы... Меня очень настораживает тот факт, что вы все в упор не видите сути обсуждаемой проблемы и акцентируетесь на совершенно других аспектах. Вы реально так рассуждаете или просто меня тролите?

twin: В современном ООП существует тенденция замены наследования делегированием. А значит наследование не может считаться основополагающим постулатом ООП.
chee: Ничего подобного. Наследование хейтят несколько джавистов, которые сами не могут объяснить почему.
twin: Проблемы наследования описаны в книге Банды Четырех, на момент написания которой JAVA еще вообще не существовала.
chee: Банда Четырех написала теоретическое бла-бла. Ты мне кодом покажи.
twin: Вот код. Примерно так выглядит замена наследования делегированием. Код весьма условный.
Ron: Это говнокод.
twin: Я знаю и не стану спорить. Но суть не в этом, а в делегировании.
chee: Дада! Говнокод! Эту задачу любой квалифицированный программист решал бы декоратором! Еще сеттеры говно и вообще ты ООП не понимаешь. Использовал класс как контейнер для функций.
twin: Ты пытаешься уйти от темы. Да, ты прав, любой квалифицированний программист решал бы задачу композицией, а не наследованием. Делегирование - частный случай композиции. А значит наследование, это не концептуальная фишка ООП.
chee: Ты серьезно считаешь, что предложил корректный пример? Я бы решал задачу так:
twin: Фу! Яркий пример как делать не надо! Потому что:

chee: окей вернемся к началу. Применение наследование является базовым принципом, но почему-то ты его вынес за рамки, на основе некоторых умозаключений Фаулера и Банды 4.
twin: Я не говорил, что нужно исключить наследование. Я говорил, что в современном ООП наследование не может считаться фундаментальным постулатом. Это со слов ваших же гуру.
chee: отвечу я тебе кодом

twin: ты сделал попытку привести его к норме, то есть к наследованию интерфейса, а не реализации. Сам того не заметив.

И тут пошла жара. Выделяю суть диспута, которую вы в упор не видите:

Valick:

Ron: Блин, да оберните вы уже стрку в VO объявите интерфейс, и декорируйте его. Длинные веревки если что за фасад, он же проконтролирует валидные последовательности формата на промежуточном этапе.
twin: Вот у Valick'а лучше получается. Правда мы делегирование обсуждали, но декорация тож годится. Важно что тут принцип наследования интерфейса и манипуляция объектами. Зависимостями, если угодно. А не дремучее наследоваение как таковое.
Ron: У меня главная претензия к твину такая: зачем брать пример под декоратор, делать наикривейшую реализацию без оного и заявлять о каноническом "нашем" ООП?
twin: Я же обозначил в топике, что это условно. Конечно примитив, не хотелось писать портянку. Вот вы всегда так, к мелочам придираетесь, а сути не хотите видеть. Я показывал отношения объектов, распределение обязанностей, суть делегирования, а они пристали к мелочам.
Нате вам портянку:

chee: не поверишь, но твой код явно yo-yo (больше подходит антипаттерн "Завистливые функции"). Я читая его начал запутываться куда, что передается, а главное зачем. И почему ты изменил концепцию изначального кода?
twin: Хорошо. Вот тебе первоначальный код с рефакторингом по Фаулеру.

twin: В чем я виноват, если вы не видите сути в простом коде, вам кучу паттернов подавай, чтоб не придирались.
Ron: Еще как видим, а суть такая: алгоритм (паттерн) подобран к задаче не правильно. Все остальное вторично на фоне таких ляпов
twin: Я старался суть показать. Принципа замены наследования делегированием. И не более того.
chee: Я тебя попросил показать что ты имеешь ввиду под сложным форматтером, а ты переписал весь свой код.
twin: Я меньше всего думал о сложном форматере. Я показывал суть делегирования. А вы ничерта не поняли. Ron'у и Valik'у декоратор пригрезился, тебе какой то сложный форматер... На кой это все? Я вообще о другом говорил
Ron: Наверное от того, что декоратор, в отличае от твоей стратегии, позволяет бороться с комбинаторным взрывом
Valick: композиция с делегированием это и есть декоратор
заставили таки меня открыть книгу, получайте)))

twin: Ron'у >>>Вы просто попытались применить свои знания паттернов туда, где им вообще было не место... Изначально стояла задача показать кодом отличие делегирования от наследования. Какой нахрен еще взрыв? О чем ты? Куда тебя поперло?
Valick'у >>> Не композиция с делегированием есть декоратор. Наоборот. Декоратор, это композиция с делегированием. Не валите все в одну кучу.
Ron: под задачу форматирования текста, twin!
twin: Покажи мне место, где была поставлена такая задача.
Ron: суслик.
Santehnick: ты придумал задачу, написал решение, затем всё переписал, получилось всё равно плохо, но продолжаешь свои заблуждения приписывать нам.

Какие заблуждения? Я даже признал, что декоратор лучше подходит под задачу форматирования, хотя у меня другое мнение. Но не было задачи сделать форматер. Не было! Была задача пояснить, чем делегирование предпочтительнее наследованию. Этого ни кто в упор не видит. Либо вы видите и пытаетесь перевести стрелки, выискивая недостатки кода, которые вообще к теме не относятся.

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

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

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

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

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