Сравнение шаблонов дизайна - PullRequest
Новая
       20

Сравнение шаблонов дизайна

0 голосов
/ 21 мая 2010

Я изучаю шаблоны проектирования с использованием C #. Одна из проблем, с которыми я сталкиваюсь, заключается в том, что они выглядят одинаково. Не могли бы вы помочь мне отличить их - в основном, когда их использовать? - Почему не другой?

  1. Мост и Стратегия
  2. Состояние и стратегия
  3. Фасад и стратегия
  4. Композит и стратегия

Я понимаю, что в Интернете доступно множество ресурсов. Однако они не относятся к этому особому сценарию.

[Примечание: я ищу примеры реализации и обоснование выбора; не просто объяснения]

Спасибо за ваш ответ. Я сделал больше попыток выучить Бридж.

У меня есть следующий сценарий.

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

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

  1. Как преобразовать его в Бридж?

  2. Какое преимущество я получу, переведя в Bridge?

    публичный класс PhilliTV { public void Begin () { Console.WriteLine ("PhilliTV Bagan"); } } 

    public class SonTV
    {
        public void Initiate()
        {
            Console.WriteLine("SonTV Initiated");
        }
     }




  public class SonRemote : IRemote
    {
        SonTV stv = new SonTV();
        public void Play()
        {
            stv.Initiate();
        }
    }


 public class PhilliRemote : IRemote
    {
        PhilliTV ptv = new PhilliTV();
        public void Play()
        {
            ptv.Begin();
        }
    }


  public class URemoteConsumer
    {
        IRemote remote = new PhilliRemote();

        public void MyPlay()
        {
            remote.Play();
        }

Ответы [ 3 ]

8 голосов
/ 21 мая 2010

Я могу рекомендовать Head First Design Patterns для этого. Из этой книги:

Разница между государством и стратегией заключается в намерении. Используя шаблон State, вы динамически изменяете поведение в течение жизни вашего объекта. Это альтернатива для операторов if по всему классу. Используя шаблон Стратегии, вы обычно делаете это один раз, когда объект построен. Это альтернатива для подклассов. Поведение является гибким, но для активного объекта вы настраиваете его один раз.

Фасад и Стратегия не имеют ничего общего друг с другом. Стратегия предназначена для настройки поведения (реализации) во время выполнения. Фасад просто упрощает существующий интерфейс. Если у вас сложная система банкоматов, вам может потребоваться 2 интерфейса. Один со всей мощью, включая всевозможные методы обработки ошибок и тому подобное, и один для вызова внешним интерфейсом, что может быть проще. Внешний код не должен знать, как обрабатывать ошибки, обработчик ошибок где-то еще позаботится об этом. Нужно только знать, что является ошибкой. Упрощенный интерфейс (который, как мы надеемся, также будет более постоянным во времени) сделает жизнь интерфейсного разработчика проще и скроет возможные изменяющиеся элементы. Вот когда вы делаете фасад. У вас есть полнофункциональный интерфейс, но большинство людей используют только подмножество. Это подмножество будет Фасад.

Составной шаблон позволяет составлять объекты в древовидные структуры. Я не вижу, как вы не можете увидеть разницу с шаблоном стратегии. У них вряд ли есть что-то общее.

Возможно, некоторые мысли о фактическом использовании этих шаблонов:

  • Мост, когда ваша модель данных еще не ясна. Вы реализуете большую часть своей реализации как обращения к себе. Таким образом, вы можете сделать приличную часть реализации, даже если абстракция все еще не определена
  • Состояние обычно используется, когда существует только ограниченное количество состояний, и поведение явно отличается. Я имею в виду кофемашины и принтеры здесь. Хотя вы могли бы внедрить банковскую систему так, чтобы, если баланс был меньше нуля, вычитание (сумма) всегда приводило к ошибке:)
  • Фасад не редкость. У вас может быть уровень данных (например, Hibernate) с API, который имеет методы, используемые как бизнес-процессами, так и процессами обслуживания. Затем вы можете определить 2 более простых API, один для бизнес-разработчиков и один для разработчиков обслуживания. Эти API-интерфейсы, конечно, вызовут полный API-интерфейс, но вы не увидите этого как разработчика бизнеса.
  • Стратегия довольно распространена, особенно если вы используете Spring или любую другую форму IoC, а для тестирования Junit вы также обычно внедряете альтернативный слой «базы данных».
  • Шаблон Composite, вероятно, наиболее часто используется в приложениях с графическим интерфейсом. Не могу придумать другого варианта использования, который сейчас есть.

Я действительно рекомендую Head First Design Patterns, так как они даже брали интервью у различных шаблонов! Затем шаблоны немного рассказывают о себе и о том, почему они являются лучшими из всех моделей:)

0 голосов
/ 18 июля 2017

".. это объект, который контролирует решение, какой алгоритм использовать .." не так ясно (по крайней мере, мне).

Объект имеет указатель состояния , скажем, указатель "currentState". Все состояния поддерживают один и тот же интерфейс, знают, как обрабатывать методы A, B и C (например).

Когда объект должен выполнить какой-либо метод (A, B или C - предоставляется интерфейсом State), он вызывает currentState.A () , currentState.B () или currentState.C () .

Фактическая обработка выполняется внутри каждого состояния; таким образом мы избегаем использования нескольких условий if-else для определения нашего собственного состояния.

0 голосов
/ 18 марта 2012

Состояние против стратегии. В состоянии именно объект контролирует, какой алгоритм использовать (что зависит от его текущего состояния), в то время как в стратегии это клиент, который контролирует какой алгоритм использовать. .

...