Привет!
В предыдущих лекциях мы уже встречались с таким понятием как «паттерн проектирования».
Если ты забыл, напомним: этим термином обозначают некое стандартное решение распространенной в программировании задачи.
На JavaRush мы часто говорим, что ответ практически на любой вопрос можно загуглить. Поэтому задачу, похожую на твою, наверняка уже кто-то успешно решил.
Так вот, паттерны — это проверенные временем и практикой решения наиболее распространенных задач или методы разрешения проблемных ситуаций.
Это те самые «велосипеды», которые ни в коем случае не нужно изобретать самому, но нужно знать, как и когда их применить :)
Другая задача паттернов — приведение архитектуры к единому стандарту.
Читать чужой код — задача не из легких! Все пишут его по-разному, ведь одну и ту же задачу можно решить многими способами. Но использование паттернов позволяет разным программистам понять логику работы программы, не вникая в каждую строку кода (даже если они видят его впервые!)
Сегодня мы рассмотрим один из наиболее распространенных паттернов под названием «Стратегия».
Представим, что мы пишем программу, активно работающую с объектом Автомобиль. В данном случае даже не особо важно, что именно делает наша программа.
Для этого мы создали систему наследования с одним родительским классом Auto и тремя дочерними классами: Sedan, Truck и F1Car.
public class Auto {
public void gas() {
System.out.println("Едем вперед");
}
public void stop() {
System.out.println("Тормозим!");
}
}
public class Sedan extends Auto {
}
public class Truck extends Auto {
}
public class F1Car extends Auto {
}
Все три дочерних класса наследуют от родительского два стандартных метода — gas() и stop()
Программа у нас совсем простая: машины умеют только ехать вперед и тормозить.
Продолжая нашу работу, мы решили добавить машинам новый метод — fill() (заправить топливо).
Добавим его в родительский класс Auto:
public class Auto {
public void gas() {
System.out.println("Едем вперед");
}
public void stop() {
System.out.println("Тормозим!");
}
public void fill() {
System.out.println("Заправить бензин!");
}
}
Казалось бы, разве могут в такой простой ситуации возникнуть проблемы? Ну, на самом деле, они уже возникли…
public class ChildrenBuggies extends Auto {
public void fill() {
//хм... Это детский багги, его не надо заправлять :/
}
}
В нашей программе появился автомобиль, который не вписывается в общую концепцию — детский багги. Он может быть с педалями или радиоуправляемым, но одно ясно точно — бензин в него заливать некуда.
Наша схема наследования привела к тому, что мы раздали общие методы даже тем классам, в которых они не нужны.
Что нам делать в такой ситуации? Ну, например, можно переопределить метод fill() в классе ChildrenBuggies, чтобы при попытке заправить багги ничего не происходило:
public class ChildrenBuggies extends Auto {
@Override
public void fill() {
System.out.println("Игрушечную машину нельзя заправить!");
}
}
Но это решение сложно назвать удачным как минимум из-за дублирования кода. К примеру, большая часть классов будет использовать метод из родительского класса, но другая часть классов будет вынуждена его переопределить.
Если у нас будет 15 классов, и в 5-6 мы будем вынуждены переопределять поведение, дублирование кода станет довольно обширным.
Может, нам смогут помочь интерфейсы?
Например, вот такой:
public interface Fillable {
public void fill();
}
Мы создадим интерфейс Fillable с одним методом fill(). Соответственно, те машины, которые необходимо заправлять, будут имплементировать этот интерфейс, а другие машины (к примеру, наш багги) — не будут.
Но и этот вариант нам не подойдет.
Наша иерархия классов может в будущем разрастись до очень большого числа (представь, сколько разных видов автомобилей есть на свете).
Мы отказались от предыдущего варианта с наследованием, потому что не хотели много раз переопределять метод fill(). Здесь же нам придется реализовывать его в каждом классе! А что если их у нас будет 50?
И если в нашу программу будут вноситься частые изменения (а в реальных программах почти всегда так и будет!), нам придется носиться с высунутым языком между всеми 50 классами и менять поведение каждого из них вручную.
Так как же нам в итоге поступить?
Чтобы решить нашу проблему, выберем иной путь. А именно — отделим поведение нашего класса от самого класса.
Что это значит?
Как ты знаешь, любой объект имеет состояние (набор данных) и поведение (набор методов).
Поведение нашего класса машин состоит из трех методов — gas(), stop() и fill().
С первыми двумя методами все в порядке. А вот третий метод мы вынесем за пределы класса Auto. Это и будет отделением поведения от класса (точнее, мы отделяем только часть поведения — два первых метода остаются на месте).
Куда же мы должны перенести наш метод fill()? Сходу ничего не приходит в голову :/ Он, вроде как, был вполне на своем месте.
Мы перенесем его в отдельный интерфейс — FillStrategy!
public interface FillStrategy {
public void fill();
}
Зачем нам нужен этот интерфейс? Все просто.
Теперь мы сможем создать несколько классов, которые будут этот интерфейс реализовывать:
public class HybridFillStrategy implements FillStrategy {
@Override
public void fill() {
System.out.println("Заправляем бензином или электричеством на выбор!");
}
}
public class F1PitstopStrategy implements FillStrategy {
@Override
public void fill() {
System.out.println("Заправляем бензин только после всех остальных процедур пит-стопа!");
}
}
public class StandartFillStrategy implements FillStrategy {
@Override
public void fill() {
System.out.println("Просто заправляем бензин!");
}
}
Мы создали три стратегии поведения — для обычных машин, для гибридов и для болидов Формулы-1.
Каждая стратегия реализует отдельный алгоритм заправки. В нашем случае это просто вывод в консоль, но внутри метода может быть и какая-то сложная логика.
Что же нам делать с этим дальше?
public class Auto {
FillStrategy fillStrategy;
public void fill() {
fillStrategy.fill();
}
public void gas() {
System.out.println("Едем вперед");
}
public void stop() {
System.out.println("Тормозим!");
}
}
Мы используем наш интерфейс FillStrategy в качестве поля в родительском классе Auto. Обрати внимание: мы не указываем конкретную реализацию, а используем именно интерфейс.
А конкретные реализации интерфейса FillStrategy понадобятся нам в дочерних классах-автомобилях:
public class F1Car extends Auto {
public F1Car() {
this.fillStrategy = new F1PitstopStrategy();
}
}
public class HybridAuto extends Auto {
public HybridAuto() {
this.fillStrategy = new HybridFillStrategy();
}
}
public class Sedan extends Auto {
public Sedan() {
this.fillStrategy = new StandartFillStrategy();
}
}
Посмотрим, что у нас получилось:
public class Main {
public static void main(String[] args) {
Auto sedan = new Sedan();
Auto hybrid = new HybridAuto();
Auto f1car = new F1Car();
sedan.fill();
hybrid.fill();
f1car.fill();
}
}
Вывод в консоль:
Просто заправляем бензин!
Заправляем бензином или электричеством на выбор!
Заправляем бензин только после всех остальных процедур пит-стопа!
Отлично, процесс заправки работает как надо!
Кстати, ничто не мешает нам использовать стратегию в качестве параметра в конструкторе!
Например, вот так:
public class Auto {
private FillStrategy fillStrategy;
public Auto(FillStrategy fillStrategy) {
this.fillStrategy = fillStrategy;
}
public void fill() {
this.fillStrategy.fill();
}
public void gas() {
System.out.println("Едем вперед");
}
public void stop() {
System.out.println("Тормозим!");
}
}
public class Sedan extends Auto {
public Sedan() {
super(new StandartFillStrategy());
}
}
public class HybridAuto extends Auto {
public HybridAuto() {
super(new HybridFillStrategy());
}
}
public class F1Car extends Auto {
public F1Car() {
super(new F1PitstopStrategy());
}
}
Запустим наш метод main() (он остался без изменений), и получим тот же результат!
Вывод в консоль:
Просто заправляем бензин!
Заправляем бензином или электричеством на выбор!
Заправляем бензин только после всех остальных процедур пит-стопа!
Паттерн «Стратегия» определяет семейство алгоритмов, инкапсулирует каждый из них и обеспечивает их взаимозаменяемость. Он позволяет модифицировать алгоритмы независимо от их использования на стороне клиента
(это определение взято из книги “Изучаем паттерны проектирования” и кажется мне крайне удачным).
Мы выделили интересующее нас семейство алгоритмов (виды заправки машин) в отдельных интерфейс с несколькими реализациями. Мы отделили их от самой сущности автомобиля. Поэтому теперь, если нам понадобится внести какие-то изменения в тот или иной процесс заправки, это никак не затронет наши классы машин.
Что касается взаимозаменяемости, то для ее достижения нам достаточно добавить один метод-сеттер в наш класс Auto:
public class Auto {
FillStrategy fillStrategy;
public void fill() {
fillStrategy.fill();
}
public void gas() {
System.out.println("Едем вперед");
}
public void stop() {
System.out.println("Тормозим!");
}
public void setFillStrategy(FillStrategy fillStrategy) {
this.fillStrategy = fillStrategy;
}
}
Теперь мы можем менять стратегии на ходу:
public class Main {
public static void main(String[] args) {
ChildrenBuggies buggies = new ChildrenBuggies();
buggies.setFillStrategy(new StandartFillStrategy());
buggies.fill();
}
}
Если вдруг детские машины-багги начнут заправлять бензином, наша программа будет готова к такому варианту развития событий :)
Вот, собственно, и все! Ты выучил еще один паттерн проектирования, который, несомненно, тебе понадобится и еще не раз выручит в работе над реальными проектами :)
До новых встреч!
Senior Java-разработчик и преподаватель в LearningTree
Senior Java-разработчик и преподаватель Java на курсах программирования Learning Tree International. Иногда пишу всякие глупости п ...
[Читать полную биографию]
Шикарное и простое объяснение! Спасибо!
Что я понял? В классе, вместо реализации метода, создаешь поле, помещаешь туда объект с реализацией метода (интерфейса), а в своем методе вызываешь метод объекта из поля.
package com.javalearning.strategy.example02.strategy;
public interface FillStrategy {
public void fill();
}
package com.javalearning.strategy.example02.strategy;
public class F1PitstopStrategy implements FillStrategy{
@Override
public void fill() {
System.out.println("Заправляем бензин только после всех остальных процедур пит-стопа!");
}
}
package com.javalearning.strategy.example02.strategy;
public class HybridFillStrategy implements FillStrategy {
@Override
public void fill() {
System.out.println("Заправляем бензином или электричеством на выбор!");
}
}
package com.javalearning.strategy.example02.strategy;
public class StandartFillStrategy implements FillStrategy {
@Override
public void fill() {
System.out.println("Просто заправляем бензин!");
}
}
Классы автомобилей
package com.javalearning.strategy.example02;
public abstract class AbstractAnyAuto {
public void gas() {
System.out.println("Едем вперед!");
}
public void stop() {
System.out.println("Тормозим!");
}
}
package com.javalearning.strategy.example02;
import com.javalearning.strategy.example02.strategy.FillStrategy;
public abstract class AbstractRealAuto extends AbstractAnyAuto {
FillStrategy fillStrategy;
public void fill() {
fillStrategy.fill();
}
public void setFillStrategy(FillStrategy fillStrategy) {
this.fillStrategy = fillStrategy;
}
}
package com.javalearning.strategy.example02;
public class ChildrenBuggies extends AbstractAnyAuto {
}
package com.javalearning.strategy.example02;
import com.javalearning.strategy.example02.strategy.F1PitstopStrategy;
public class F1Car extends AbstractRealAuto {
public F1Car() {
this.fillStrategy = new F1PitstopStrategy();
}
}
package com.javalearning.strategy.example02;
import com.javalearning.strategy.example02.strategy.HybridFillStrategy;
public class HybridAuto extends AbstractRealAuto {
public HybridAuto() {
this.fillStrategy = new HybridFillStrategy();
}
}
package com.javalearning.strategy.example02;
import com.javalearning.strategy.example02.strategy.StandartFillStrategy;
public class Sedan extends AbstractRealAuto {
public Sedan() {
this.fillStrategy = new StandartFillStrategy();
}
}
package com.javalearning.strategy.example02;
import com.javalearning.strategy.example02.strategy.StandartFillStrategy;
public class Main {
public static void main(String[] args) {
ChildrenBuggies buggies = new ChildrenBuggies();
System.out.println("Создаём детскую машинку, её не надо заправлять и у неё нет метода fill() равно как и FillStrategy:");
buggies.gas();
buggies.stop();
System.out.println("\nА теперь создадим стандартное авто с ДВС:");
Sedan sedan = new Sedan();
sedan.gas();
sedan.stop();
sedan.fill();
System.out.println("\nАвто с гибридным двигателем:");
HybridAuto hybridAuto = new HybridAuto();
hybridAuto.fill();
hybridAuto.gas();
hybridAuto.stop();
System.out.println("Меняем стратегию. В нашем гибриде закончился в дороге заряд, но у нас есть канистра с бензином...");
hybridAuto.setFillStrategy(new StandartFillStrategy());
hybridAuto.fill();
}
}
Вот, добавил ещё UML-диаграмму:
Таким образом добавив еще один уровень абстракции, мы решили проблему с игрушечным авто. Или нет? Автору статьи спасибо за хороший пример, хорошего паттерна😃
P/S: Как тут добавить спойлер, а то как-то много кода получилось, не хочется стену текста городить на форуме, так что извиняюсь конечно, но я и вправду не нашёл как добавить спойлер, может подскажет кто-то?
А я так и не понял, как решилась проблема дублирования кода, если теперь для каждого класса с заправляемыми машинами надо создать еще по одному классу. Бред -.-
1) Теперь при создании новых классов можно при необходимости создать новое поведение для метода fill();
2) Если скажем поведение у HybridFill авто поменяется нам достаточно изменить поведение только в этом классе, а не искать в программе каждый класс которому мы писали такое поведение.
Проблема в была в том, что у детского багги нет топливного бака, а значит метод fill() ему не нужен.
В итоге мы либо получаем ошибку, либо пишем какой-то код, который ничего не должен делать, но уведомить об этом пользователя...
Вот так при помощи простых манипуляций мы научились из буханки белого (или черного) хлеба делать трамвай. Остался только один вопрос: зачем нам это нужно?
Это лекция - пересказ первых 70 страниц книги Head First Design Patterns. Если хотите больше узнать про паттерны, советую прочитать эту книгу. В ней всё объясняется намного понятнее и раскладывается прям по полочкам. Книга классная, так и хочется читать (я уже на половине)
Хорошая стратегия, но игрушечную машинку наследовать от Car все равно варварство, если программа предполагает что там не только игрушечные машины есть)
В приведенном примере проблема для багги на батарейках не решена. Багги наследуется от Auto, получает поле fillStrategy. Дальше что? fillStrategy = null? Ну круто, чо.
ничто не мешает, сделать отдельный класс -реализацию FillStrategy, который будет подходить именно для "багги на батарейках", и в этой модели авто в переменную класса setter_ом установить именно подходящий класс, реализацию FillStrategy.
улыбнуло.
это будет не бОльшим "извращением", чем считать заправкой .fill() зарядку батареек обычных электро-автомомобилей.
P.S. но главное : "А, забыл, было бы желание спорить и несоглашаться, будучи увереным только в своей правоте,- и тогда считать "извращением" и придираться можно к чему угодно" )).
P.P.S. просто шутка, не чтобы вызвать агрессию или продолжать спор.
А вопрос действительно открыт. Если поле FillStrategy все равно попадет к незаправляемым машинам, то чем это лучше переопределения метода?
если
public void fill() {
System.out.println("меняем ААА батарейки");
}
В таком случае наследование метода вполне подходит, наша же цель была избавиться от этого метода в некоторых наследниках, а в некоторых оставить как я понял
получается fillStrategy = null единственное решение?
тогда наверное лучше было бы
public void fill() {
throw new RuntimeException("незаправляемая машина");
}
или вроде того.
Чесно говоря приемуществ потерна не понял к сожалению((
А вообще почитал комменты ниже, есть смысл чтоб быстро менять реализацию метода в некоторых классах, подсунул туда нужную стратегию и реализация метода fill() изменилась
удобно согласен. Но надо сделать акцент что тут именно в скорости подмены реализации смысл
Не только в скорости. Можно загружать классы в рантайме. То есть, можно изменить код класса стратегии, перекомпилировать его и перезагрузить на горячую, не останавливая программу.
Чтобы не было метода fill() у не заправляемых машин, достаточно создать новый класс FillableAuto и в него уже добавить поле FillStrategy. Подход напоминает абстрактный метод, но в случае с абстрактным методом, нам придется в каждом новом классе - наследнике дублировать код, а с помощью стратегии только выбирать стратегию реализации. Ну и в случае изменения класса, мы соответственно не переписываем реализацию, а меняем ее стратегию. Плюс в случае, когда мы поменяем стандарт процесса заправки, нам так-же нужно поменять ее реализацию в стратегии, тем самым 1. не вмешиваясь в логику клиента, 2. не переписывая код у всех дочерних классов.
public void fill(Class<? extends FillStrategy> clazz){
if (FillStrategy.class.isAssignableFrom(clazz)){
fillStrategy.fillFull();
}else {
System.out.println("Не нужно заправлять ничего");
}
}
Проверяем наследника, но в мэйн нужно указывать стратегию класса, в методе fill.
sedan.fill(StandartStrategy.class);
hybrid.fill(HybridStrategy.class);
f1.fill(F1Strategy.class);
toys.fill(BuggiesCar.class);
Если запустить все работает корректно.
Все потому, что шаблон Strategy не про возможность избежать поведения класса-родителя в классе-наследнике, а про возможность менять алгоритм поведения объектов в зависимости от поставленной задачи. Соответственно вместо того, чтобы сочинять весьма оторванный от жизни пример с машинами и детскими багги, можно было просто указать, что интерфейс Comparator является эталонной реализацией шаблона Strategy в Java: в зависимости от реализации компаратора, передаваемого, например, в метод Collections.sort() мы можем менять стратегию сортировки объектов в коллекции - в естественном порядке, в обратном порядке, через один, ещё как-нибудь...
А новые модели велосипедов кто будет изобретать?
А вообще, я к тому, что в java есть много библиотек и классов, позволяющих сделать одно и то же, просто что-то подходит лучше под одно, что-то под другое, а что-то просто лучше, потому что использует современный подход, а другое - устарело. Так что придумывать новые способы, сделать старые вещи - нужно
Я скорее всего что-то упускаю, но ведь можно дефолтно реализовать метод fill() в интерфейсах и наследовать их там, где надо - результат же тот же будет...
Ну вот будет у тебя реализация дефолтная и 100 классов. Из них например 80 требуют недефолтной реализации = надо 80 раз переопределить метод. И опять же все 100 классов должны реализовывать интерфейс.
походу основная ценность "Стратегии" в
- (1) отделении поведения из родительского базового класса в отдельный интерфейс ,с возможностью разных реализаций.
- (2) лёгкости внесения изменений только в нужный класс, реализующий отделённый интерфейс поведения,(FillStrategy), не затрагивая наследников базового класса (Auto).
пункт (1) можно обойтись и без "Стратегии", дефолтным поведением интерфейса и добавлением этого интерфейса к базовому классу. но тогда
пункт (2) будет усложнён, так как придётся находить все классы, где поведение после его изменения нужно править вручную.
а вот в случае со "Стратегией", это изменённое поведение достаточно будет подправить в том отдельном классе, реализовавшем FillStrategy, и оно автоматом изменится во всех класса-наследниках базового класса Auto, которые содержат изменившееся поведения как переменную класса.
(расширенность ответа может только больше запутывать, да и наверное уже не актуально,
но попробовал подсумировать статью. мне она показалась полезной))
Суть не в реализации интерфейса, а в его применении. В первом случае интерфейс применялся конкретно к потомку Auto, во втором случае были созданы классы СтратегияЗаправкиСтандартная, Гибридная и т.п. и интерфейсы применены к этим классам. В суперклассе auto было добавлено поле "Стратегия заправки" и метод fill остался в суперклассе, что избавило тебя от имплементации интерфейсного fill в каждом потомке суперкласса, как было бы в первом случае.
Хорошая и наглядная статья. А вот пример с заправкой детского багги можно было бы дополнить применением конструктора без параметров у авто, который бы вызывал конструктор у какого-нибудь промежуточного интерфейса, который сам наследуется от авто и описывает незаправляемую сущность. Но такого рода недосказанность в статье заставляет почесать голову и дополнить пазл, что явно не ухудшает восприятие материала.
"Мы создадим интерфейс Fillable с одним методом fill(). Соответственно, те машины, которые необходимо заправлять, будут имплементировать этот интерфейс, а другие машины (к примеру, наш багги) — не будут.
Но и этот вариант нам не подойдет."
"Куда же мы должны перенести наш метод fill()? Сходу ничего не приходит в голову :/ Он, вроде как, был вполне на своем месте.
Мы перенесем его в отдельный интерфейс — FillStrategy!"
Fillable нельзя, а назовем FillStrategy, то можно?
концовка, решение для детских машинок не впечатлило.
Да, частичная замена наследования(имплементации) на композицию добавило гибкости, но изночально поставленная задача с детскими машинками кажется не решена, это решение не то, что "нам обещали в начале статьи". Хотя паттерн интересный.
Так себе решение)
В таких случаях обычно кидается UnsupportedOperationException. И тут два варианта: либо сделать это реализацией по умолчанию (плохо), либо делать это ручками в каждом классе (тоже плохо). Тут уже каждый выберет зло поменьше.
Глупо, конечно, докапываться до учебных примеров, но я соглашусь с замечанием автора треда: пример так себе. Из-за этого мы как минимукм не поняли, как паттерн решает нашу проблему. Суть материала, может быть, и ясна, но на остальные моменты (в данном случае на структуру) забивать нельзя. Хорошая статья по этому паттерну.
А адекватно решить сложившуюся проблему с заправкой можно изменив структуру. Например введя еще один уровень абстракции:
Класс Auto делаем абстрактным. Это логично. От него наследуем абстрактные классы всех вариантов: игрушечная машина, электрокар, бензинка, дизель, гибрид. От бензиновой машины наследуем еще один абстрактный класс машины на газу :)
Во всех этих классах реализуем метод заправки. В игрушечной машинке кидаем исключение. Теперь тема заправки будет окончательно закрыта. Даже "Стратегия" не понадобилась, хех:)
Блин всегда при разборе паттернов восхищаюсь чистотой кода и тривиальностью решений проблем, будет время и я начну понимать где их и когда применять эти паттерны, а пока все что прочитал без практики улетучивается почти вся инфа.
Блин, я не фига не понял фишки этого патерна.
Т.е. мы создаем какую-то неизведанную хрень, и для этого нам надо:
1. в интерфейсе FillStrategy добавить свой метод
2. создать новый класс nnnFillStrategy, в котором переопределяем этот метод
3. подставить этот класс в конструкторе нашего класса
и в чем преимущество, по сравнению с первым вариантом:
1. Создаем новый интерфейс nnnFillable
2. имплементим его в свой класс
Что в первом, что во втором варианте нам надо что-то менять в своем коде.
Вот только, если у нас появиться одна, потом вторая, потом третья хрень и т.д. - в первом варианте, создаем сколько надо интерфейсов и наимплиментить их можно тоже сколько угодно.
А как быть с нашим патерном? У нас привязка к конкретной переменной. Тут придется переписывать уже имеющийся код? Но это не есть гут
Может я не прав, первый раз с ним столкнулся, поэтому буду рад справедливой критике, особенно если это поможет мне понять как это использовать на практике
Отличие в том, что если у твою логику nnnFillable имплементирует несколько классов (например, 20), то в каждом из них тебе придется переопределять метод fill() вручную. И каждый раз, когда у тебя будет добавляться класс, имплементирующий существующую логику fill() тебе придется делать одно и то же. Во втором же способе, ты создаешь класс nnnFillStrategy, который уже переопределил логику fill() и добавляешь его в качестве поля в родительский класс. То есть если там внутри огромная логика, то ты заменяешь переписывание этой логики правильным определением поля FillStrategy. А дальше добавляй сколько угодно классов, имплементирующих существующую логику fill(), в них нужно будет всего лишь правильно определить переменную FillStrategy (одна строка кода)
Грубо говоря, преимущество следующее:
1. Если делать реализацию неудобного метода внутри класса-родителя, то во многих наследниках придётся его переопределять - очень много лишнего кода (и методов таких может быть несколько)
2. Если вынести этот метод в интерфейс, то таких интерфейсов опять же может быть очень много (особенно в крупной программе) и классы наследники, имплементирующие десятки интерфейсов, будут очень сложны в поддержке + эти методы этого интерфейса придётся реализовать (т.е. много лишнего кода). Да и кода много получается (больше даже чем в первом варианте).
3. В паттерне "Стратегия" нам предлагают завести интерфейс в качестве поля класса-родителя. Будет несколько классов, имплементирующих этот интерфейс и, в зависимости от того, какой класс-наследник мы создаём, в конструктор класса-родителя будет передаваться одна из реализаций этого интерфейса со своей реализацией неудобного метода.
Ну, логика есть в этом, сократить код можно ощутимо (мы пишем столько реализаций метода, сколько их всего есть, и не пишем одинаковые реализации), только этот паттерн для очень конкретных случаев.
Если вернуться к проблеме что детский багги не нужно заправлять вовсе, то у нас осталась та же проблема. Нужно или переопределять метод fill() который будет ничего не делать и таким образом мы вернемся к той же проблеме - переопределяй метод который есть у класса родителя пустой реализацией если он тебе мешает. А если таких методов 20 и классов 40?
А если не переопределять, то мы получим NullPointerException, т.к. поле fillStrategy будет не проинициализировано! А метод fill все так же можно вызвать, и вызовется он на null.
Изучив подробнее этот паттерн не нашел информации что можно избежать проблемы описанной выше. Стратегия используется для группировки схожего поведения в отдельный класс, для упрощения основного, для простоты поддержки и сокрытия реализации.
Статья в целом написана хорошо.
Все понятно в отдельности.
Но в целом ни...я не понятно в чем преимущество данного патерна перед переопределением методов и созданием интерфейса, так как все равно нужно писать многоэтажный код!!
Вообщем тема не раскрыта.
преимущество действительно есть, они сначала реализовали все возможные случаи заправки автомобиля, а потом просто применяют их к определенным типам. Если нужно будет создавать сотни классов, то преимущество станет более заметным
На мой взгляд, все гораздо проще:
если у суперкласса есть методы, реализация которых в дочерних классах требует быть в нескольких вариантах(в зависимости от дочернего класса, его сущности ), то реализацию таких методов необходимо определить в отдельных классах-стратегиях. То есть, к примеру, есть у нас три стратегии (три варианта реализации одного и того же метода) и в зависимости от абстрактного смысла дочернего класса мы выбираем "вот наверное реализация данного метода в таком варианте нам подойдёт больше, поэтому выбираем такую то стратегию."
А механика реализация показана хорошо в данной статье (путем создания объекта класса нужной нам стратегии и вызова метода выбранной стратегии).
Заправка машинки так и не раскрыта.
Примечание к определению паттерна Стратегия из книги "Headfirst. Паттерны проектирования":
Используйте ЭТО определение, когда вам понадобится произвести впечатление на друзей или начальство.
BMW I3 есть модель електро+750кубовьій ДВС которьій крутит генератор всегда на оптималньіх оборотах, работает как в смешаном цьікле так и чисто електро. Если не заряжать розеткой может тупо ехать на бензине. Ниссан випустил нечто похожее но они пока только в азии.
Хотел бы еще дополнить, что в данном конкретном примере можно сделать еще вот такую вещь (за счет того, что интерфейс FillStrategy содержит один метод и по сути является функциональным):
По моему паттерн про то, что можно создать репозиторий-клас с вот этими стратегиями и расширять его, не меняя старый связанный код. А вариант с интерфейсом Филлабл, похоже куда проще для решения проблемы с детским багги ))
Тема заправки детского баги не раскрыта :(. Так что делать с багги? ведь метод fill придется в нем реализовывать, а я так понял из текста статьи - от этого хотели уйти: "Наша схема наследования привела к тому, что мы раздали общие методы даже тем классам, в которых они не нужны."
Согласно тексту мы так и остались с методом fill у багги, только теперь мы еще и прикрутили различные стратегии, вместо того чтобы просто переопределить метод у "багги".
ИМХО подача получилась запутанной. Как мне кажется надо было либо вовсе не упоминать багги, либо дописать реализацию еще одной стратегии, применимой к багги.
Тема заправки детского баги не раскрыта :(. Так что делать с багги? ведь метод fill придется в нем реализовывать
Метод fill() мы из класса-багги убрали (как и из других классов-автомобилей). Точнее, не убрали, а делегировали его выполнение полю-стратегии (сам-то метод fill() есть в родительском классе Auto, просто он теперь ничего не делает - а просто вызывает метод из стратегии)
public class Auto {
FillStrategy fillStrategy;
public void fill() {
fillStrategy.fill();
}
}
Для багги (и других не-заправляемых автомобилей) просто создадим стратегию FillNoWay,к примеру
public class FillNoWayStrategy implements FillStrategy {
@Override
public void fill() {
System.out.println("Эти автомобили не нужно заправлять!");
}
}
public class Main {
public static void main(String[] args) {
ChildrenBuggies childrenBuggies = new ChildrenBuggies(new FillNoWayStrategy());
childrenBuggies.fill();
}
}
Ну так и я о том же, вместо того чтобы переопределить метод в багги:
- создали интерфейс стратегии
- создали различные реализации стратегий
- добавили поле стратегии
- еще не забываем что нам теперь нужно выполнить дополнительное действие по "прокидыванию" стратегии в классы автомобилей
P.S.: Я знаю что такое паттерн стратегия и для чего он нужен - мое замечание было к изложению материала. Т.к. из изложенного следует что у паттерна больше минусов нежели плюсов. А плюс у паттерна один (в свете дефолтных методов в интерфейсе) - это возможность "на лету" заменить стратегию.
По-моему, Вы немного усложняете.
У нас есть алгоритм заправки автомобилей. Этих алгоритмов будет штуки 3-4.
Если у нас будет интерфейс Fillable и 50 классов-автомобилей (а вот их легко может быть 50) - нам надо будет:
- реализовать 50 методов fill() (а не 3-4, как со стратегиями)
- еще и помнить в каких классах какая реализация fill(), на случай если их придется менять
Со стратегией все проще - создали 3-4 варианта, инжектим нужную стратегию в виде поля в нужный класс, и больше не думаем про это. Надо будет что-то поменять - отлично, у нас очень маленький набор стратегий, который легко держать в голове. Даже если изменения будут глобальными и нам надо будет перелопатить все 50 классов - нам достаточно будет просто поменять объект стратегии внутри класса, а не вникать каждый раз в тонкости алгоритма.
Про default-методы интерфейсов говорить не буду, так как это условие за рамками задачи.
Я говорю все-таки исходя из Java 7, поскольку большая часть курса изложена на этой версии.
С default-методами ситуация, конечно, совсем другая.
Да я не о паттерне пишу - паттерн этот хороший. Я о подаче материала пишу. Начало подачи - за здравие, а вот завершение получилось скомканное, и мне кажется, новичкам сложно понять всю прелесть этого паттерна из приведенных примеров.
P.S.: Про понятность мнение строю на основе практики обучения джуниоров.
На JavaRush мы часто говорим, что ответ практически на любой вопрос можно загуглить. Поэтому задачу, похожую на твою, наверняка уже кто-то успешно решил.
Так вот, паттерны — это проверенные временем и практикой решения наиболее распространенных задач или методы разрешения проблемных ситуаций.
Это те самые «велосипеды», которые ни в коем случае не нужно изобретать самому, но нужно знать, как и когда их применить :)
Другая задача паттернов — приведение архитектуры к единому стандарту.
Читать чужой код — задача не из легких! Все пишут его по-разному, ведь одну и ту же задачу можно решить многими способами. Но использование паттернов позволяет разным программистам понять логику работы программы, не вникая в каждую строку кода (даже если они видят его впервые!)
Сегодня мы рассмотрим один из наиболее распространенных паттернов под названием «Стратегия».
Представим, что мы пишем программу, активно работающую с объектом Автомобиль. В данном случае даже не особо важно, что именно делает наша программа.
Для этого мы создали систему наследования с одним родительским классом 
Мы выделили интересующее нас семейство алгоритмов (виды заправки машин) в отдельных интерфейс с несколькими реализациями. Мы отделили их от самой сущности автомобиля. Поэтому теперь, если нам понадобится внести какие-то изменения в тот или иной процесс заправки, это никак не затронет наши классы машин.
Что касается взаимозаменяемости, то для ее достижения нам достаточно добавить один метод-сеттер в наш класс
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ
Comparatorявляется эталонной реализацией шаблона Strategy в Java: в зависимости от реализации компаратора, передаваемого, например, в методCollections.sort()мы можем менять стратегию сортировки объектов в коллекции - в естественном порядке, в обратном порядке, через один, ещё как-нибудь...