'
Добро пожаловать в первый пост из серии «Открытые шаблоны дизайна». В этой серии статей мы собираемся раскрыть каждый шаблон дизайна с нуля.
Простое знание языка программирования и его конструкций не сделает из вас лучшего программиста или разработчика. Для создания программного обеспечения, которое будет работать сегодня и в будущем, требуется знание шаблонов проектирования.
Многие разработчики уже сталкивались с теми проблемами дизайна, с которыми вы сталкиваетесь прямо сейчас или столкнетесь в будущем. Они указали стандартный способ решения этой проблемы. Таким образом, используя шаблоны проектирования, вы получаете преимущество использования проверенных методов.
Каждый шаблон дизайна предназначен для решения конкретной ситуации, могут быть ситуации, когда можно использовать более одного шаблона дизайна.
Большинство программистов просто пытаются решить стоящую перед ними проблему, не беспокоясь о шаблонах проектирования, избыточном коде или даже о тесной связи. Но хорошие программисты начинают иначе. Они думают о сегодняшних требованиях, будущих требованиях, поддержке кода и возможности повторного использования кода.
Хорошие программисты не торопятся начинать писать код, когда получают требования. Они сидят и думают о том, подойдет ли их дизайн. Если да, то будет ли он работать через 6 месяцев, когда требования изменятся.
Хорошие программисты берут ручку и бумагу и начинают проектировать свои классы и отношения между классами. Они пытаются добиться слабой связи и высокой сплоченности в своем дизайне, при этом имея в виду объектно-ориентированные принципы. Они не сразу попадают внутрь низкоуровневого кода. Чтобы разрабатывать гибкое и многократно используемое программное обеспечение, вы должны следовать этому подходу, иначе вы всегда будете изменять код, который вы написали ранее.
В индустрии программного обеспечения неизменна только одна вещь: Изменить. Требования, безусловно, будут меняться. Так как же разработать программное обеспечение, которое можно легко адаптировать к вашему коду в соответствии с требованиями будущего? Для этого вам нужно начать заранее и спроектировать его таким образом, чтобы будущие требования не нарушили ваш предыдущий код.
Как я могу это сделать?
Что ж, это можно сделать, следуя принципам дизайна и шаблонам дизайна, основанным на этих принципах.
функция goto c ++
Теперь давайте погрузимся в кодирование и начнем путь, чтобы стать лучшим программистом. В этом посте мы собираемся раскрыть одну из самых важных закономерностей. - Шаблон стратегии .
Когда я говорю о самом важном, это отражает общую проблему, которую решает шаблон стратегии.
Что такое шаблон стратегии?
Вот определение прямо из книги «Банда четырех»: «Шаблон стратегии используется для создания взаимозаменяемого семейства алгоритмов, из которого во время выполнения выбирается требуемый процесс.».
Если тыне в состоянии понять, не волнуйтесь, мы объясним это впрощепутьдля васПонимаю.
Давайте сначала разберемся с проблемой, а затем посмотрим, как шаблон стратегии может ее решить.
На приведенной выше диаграмме UML у нас есть абстрактный класс Animal и два конкретных класса, Dog и Bird, являющиеся расширением суперкласса Animal.
Итак, давайте определим абстрактный класс Animal и два конкретных класса Dog и Bird.
Что вы думаете о вышеуказанном дизайне? В нашем дизайне есть одна большая ошибка.
Все животные не могут летать, как и в приведенном выше случае собака не может летать. Но все же он ведет себя «летать».
Мы допустили ошибку, написав абстрактный метод fly () внутри класса Animal. Этот дизайн заставит каждый подкласс Dog, Bird, Penguin, Crocodile, Goose и т. Д. Реализовать метод fly ().
Мы должны были понять, что полет - это способность, которой обладают не все животные. Предоставляя метод fly () в абстрактном классе Animal, мы установили способность летать во всех подклассах, что не подходит для всех подклассов животных.
Вы можете подумать, в чем проблема при реализации метода fly в подклассах. Хотя вы можете реализовать метод fly () в нелетающих подклассах Animal, чтобы просто вывести «Я не могу летать». Но проблема в том, что вы все еще придаете «муху» нелетающим животным. Это не так.
Каково это - вызвать dog.fly () или crocodile.fly ().
Итак, теперь мы поняли, что наш дизайн неправильный, и нам следует удалить метод fly () из подкласса Animal.
Каким еще один способ спроектировать наши классы таким образом, чтобы наш дизайн не заставлял все подклассы Animal иметь поведение мух?
Одно из решений, которое сразу приходит на ум, состоит в том, что мы можем создать летающий интерфейс с методом fly, и только животные, которые могут летать, будут реализовывать этот летающий интерфейс. Таким образом, мы не будем заставлять все подклассы Animal определять поведение мух. Итак, давайте запрограммируем этот дизайнерский подход.
Теперь наш класс Animal будет выглядеть так, как показано ниже, после удаления метода fly из класса Animal.
Теперь давайте определим интерфейс Flying
Теперь класс собак будет изменен.так какприведенный ниже код, и он не обязательно должен иметь поведение полета.
Давайте посмотрим на некоторые из наших подклассов Animal, которые будут летать.
Мы решили нашу предыдущую проблему, но у нас возникла новая проблема, и это «Дублирование кода».
Скажем, у нас будет 100 различных подклассов летающих животных. Мы должны продублировать код для поведения полета, поскольку интерфейс полета не может предоставить какую-либо реализацию для поведения полета, а позже, если мы захотим изменить реализацию метода fly () в любом подклассе, нам придется открыть этот класс и изменить код, что плохо. Нам не хватает чего-то большого, то есть мы не можем изменить поведение класса во время выполнения.
Но не волнуйтесь, шаблон стратегии поможет вам решить эту проблему.
Итак, давайте реорганизуем наш код, чтобы использовать шаблон стратегии.
Летающий интерфейс останется прежним. Теперь, вместо того, чтобы каждый летающий подкласс реализует сам летающий интерфейс, мы собираемся определить отдельные конкретные классы, которые будут реализовывать различное поведение в полете. Посмотрим, как это сделать.
Итак, как все это работает, давайте посмотрим на TestClass
Используя шаблон стратегии, мы теперь можем изменить поведение любого животного во время выполнения, и это без принуждения каких-либо подклассов для определения самого поведения полета.
Когда использовать шаблон стратегии?
Если вы хотите иметь возможность динамически изменять поведение во время выполнения.
Чтобы убедиться, что вы четко понимаете паттерн стратегии, давайте рассмотрим другой пример.
В приведенном выше классе Employee мы устанавливаем заработную плату сотрудника в зависимости от его / ее назначения. Если сотрудник является «стажером», мы добавляем 10% премию к основной заработной плате для расчета реальной заработной платы.
Если сотрудник является «веб-разработчиком», мы добавляем 20% бонуса к базовой заработной плате для расчета реальной заработной платы, и аналогичный процесс применяется для других типов сотрудников. Хотя наш алгоритм расчета реальной заработной платы очень прост, чтобы его было легче понять, но в большинстве случаев он включает в себя множество сравнений и вычислений.
как установить путь Java в окнах
Итак, что не так с кодом класса служащего?
Ну код для расчета зарплаты (getPay ()) статический. Допустим, я хочу изменить бонус для «Стажер» с 10% на 14%. Мне нужно будет открыть код класса Employee и изменить его.
И еще одна проблема - я не могу изменить алгоритм оплаты труда сотрудника во время выполнения. Итак, как это сделать? Шаблон стратегии специально используется для решения такого рода проблем.
Давайте проведем рефакторинг кода для использования шаблона стратегии.
Я собираюсь определить несколько алгоритмов расчета заработной платы. Тогда я смогу использовать любой из этих алгоритмов для расчета оплаты во время выполнения.
Теперь посмотрим, как изменится класс Employee.
Заметка: Я удалил логику расчета зарплаты из класса Employee и создал метод набора PayAlgorithm (), с помощью которого я буду устанавливать PayAlgorithm, который я хочу использовать для расчета оплаты.
Это даст мне гибкость при расчете оплаты, указав любой алгоритм PayAlgorithm динамически во время выполнения. Также обратите внимание, что позже, если мне придется изменить логику расчета оплаты, я могу создать новый алгоритм PayAlgorithm и использовать его для расчета оплаты. Мне не нужно менять предыдущий код, не правда ли?
Итак, давайте посмотрим, как это работает.
Надеюсь, вы очень хорошо поняли паттерн стратегии. Лучший способ чему-то научиться - это практиковаться.
Если у вас есть какие-либо вопросы, связанные с шаблоном стратегии или любым другим шаблоном, оставьте свои запросы ниже.
Следите за следующей публикацией, в которой мы расскажем об одном из самых популярных паттернов дизайна - Factory Pattern.
А пока вы можете загрузить код, поиграться с ним и убедиться, что вы закрепили шаблон стратегии в своей голове.
Есть вопрос к нам? Упомяните их в разделе комментариев, и мы свяжемся с вами.
Похожие сообщения: