Является ли добавление динамического поведения единственным преимуществом использования шаблона Decorator?

Я изучаю дизайн декоратора на данный момент, и это мышление меня очень беспокоит.Является ли добавление динамического поведения единственным преимуществом использования шаблона Decorator?

Было бы проще просто иметь один базовый класс с булевым значением, соответствующим его функции?

Например: Текстовое изображение, может иметь вертикальную прокрутку, горизонтальную прокрутку, границу и т. Д., Если базовый класс textview имеет BOOL для canVerScroll, canHorScroll, hasBorder; почему это не лучше, чем шаблон дизайна Decorator?

Спасибо за помощь!

источник

2017-02-21 Tony Lin

Возможно, вам удастся задать этот вопрос в разделе [стекирование программного обеспечения] (http://softwareengineering.stackexchange.com/), хотя я бы знал, что [перекрестная пересылка] (http: //meta.stackexchange .com/questions/64068/is-cross-posting-a-question-on-multiple-stack-exchange-sites-allowed-if-the-qu) неодобрительно. –

@ RicoKahler да, может быть, извините, я новичок в StackOverflow и не знаю, что у них так много разных сайтов. Я мог бы подождать некоторое время и посмотреть, может ли кто-нибудь помочь здесь, или я просто перееду туда. Thx в любом случае –

Было бы проще просто иметь один базовый класс с булевым значением, соответствующим его функции?

Это нарушило бы SOLID принципа называется Open-Closed принципа. Принцип Open-Closed гласит, что компоненты должны быть открыты для расширения, но закрыты для модификации. Если у вас есть один класс TextView, его нужно будет менять каждый раз, когда вы хотите ввести новое поведение в текстовое представление.

Почему это не лучше, чем дизайн декоратора?

Представьте себе, что пользователи вашего API (которые не имеют доступа к API исходного кода) хотят ввести новое поведение для TextView класса под названием Поворот на 360 градусов. У них есть два варианта: либо дождаться, когда вы добавите новый BOOL в базовый класс TextView и поддержите эту функцию, или выясните способ создания этой функции поверх вашего TextView. Один из вариантов, с которым они могут пойти, - создать TextViewAdapter (см. Adapter pattern), что позволит им добавить требуемую функциональность сверх функциональности, которую вы предоставили.

Не было бы лучше, если бы вы предоставили возможность расширить свой API из коробки, а не создавать API, который не расширяется без вашего вмешательства?

источник

2017-02-21 06:51:22 CKing

Спасибо за отличный ответ! Удивительно отметить принцип открытого закрытия, которого я не заметил! Есть ли хорошие сайты, которые вводят эти принципы? –

Попытка подвести вторую часть, на которую вы ответили. Обычным способом решения этой проблемы является: дизайн декоратора (когда он подходит) или шаблон адаптера поверх него (не совсем приятно, я полагаю?). И на каком-то языке, таком как C# и object-c, у них есть расширение класса. Я полагаю, что это делает ту же работу, что и в расширении класса без изменения существующего кода. Я прав в этих 3 пунктах? Много thx! –

@TonyLin * Stack Overflow * имеет много контента по принципам * SOLID *. Если это не поможет, сообщите мне, чтобы я мог указать вам на некоторые внешние ссылки. Нет необходимости использовать шаблон * Decorator * каждый раз, когда вы хотите, чтобы ваш API был расширяемым.Существуют и другие шаблоны, которые помогут вам достичь той же цели (шаблон стратегии, композитный шаблон и т. Д.). Я не знаком с расширениями класса, поэтому мне было бы некорректно прокомментировать это. Поскольку это ваш первый вопрос на сайте, прочитайте [Что делать, если кто-то отвечает на мой вопрос] (http://stackoverflow.com/help/someone-answers) – CKing

Является ли добавление динамического поведения единственным преимуществом использования шаблона Decorator?

ответ

Смежные вопросы