[Серия «Учимся вместе»] Режим стратегии: так много уток

Шаблоны проектирования
[Серия «Учимся вместе»] Режим стратегии: так много уток

универсальное определение

Определить семейство алгоритмов, реализации каждого алгоритма можно заменять друг другом, а реализация алгоритма изолирована от конкретного сценария использования алгоритма.

Эволюция режима стратегии

【Продукт】: Мне нужна куча уток, красных, зеленых, черных, и они умеют летать! Еще звонит!

[Разработка]: Я понимаю, это можно сделать за секунды.Пока N видов уток унаследуют мой класс Duck и перепишут его, все будет сделано!

public abstract class Duck {
    /**
     * 颜色属性
     */
    String color;

    /**
     * 飞行方法
     */
    fly();

    /**
     * 呱呱叫的方法
     */
    quack();
}

Some times later...


【БОСС】: Низкий поклон! что с тобой не так! ! ! Скажите, почему в небе летают резиновые уточки? ! ! ? ? ?

[Развитие]: (Говорить не смейте, только внутренний монолог: Оказывается, безмозглое наследство вызовет большие проблемы... Кто я... Где я... Что мне делать...)

100 000 вопросов

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

Q2.Только при использовании инкапсуляции наследование, кажется, не работает, кажется, есть полиморфизм?

Вопрос 3. Как я могу использовать полиморфизм?

Q4. Могу ли я использовать это поведение полета?"Определите его как интерфейс, а затем поместите этот интерфейс... в базовый класс утки! ! !"

основной код

public abstract class Duck {
    /**
     * 飞行行为是动态的,可能会变的,因此抽成多个接口的组合,而不是让Duck类继承
     */
    FlyBehavior flyBehavior;

    /**
     * 每个鸭子的叫声不同,抽象成接口
     */
    QuackBehavior quackBehavior;
}

На этот раз, похоже, действительно все решено: вы можете летать, как хотите, и можете называть это как хотите.

Принципы дизайна, которым нужно следовать

  • пакетные изменения
  • Больше композиции, меньше наследования
  • Программа для интерфейса, а не для реализации

Мое предыдущее недоразумение

Когда вы впервые изучаете Java, вы должны быть в состоянии избежать части шаблонов проектирования.В то время мое понимание шаблонов стратегии было таким.Основной код выглядит следующим образом:

// 不需要看全貌,就看这一段核心代码
public strategyChoose(String mainName){
    switch (name){
        case "A":
            story = new StoryB(name);
            break;
        case "B":
            story = new StoryA(name);
            break;
        default:
            story = new StoryB(name);
            break;
    }
}

"Следующее недоразумение:"

Раньше я думал, что режим стратегии, как следует из названия, заключается в том, чтобы определять разные стратегии (т.е. алгоритмы), а затем вызывать их динамически, например, я определяю две стратегии, A и B, а затем выбираю стратегию с помощью переключателя заявление филиала.

Ошибка в таком понимании состоит в том, что оно неправильно понимает ключевой момент паттерна стратегии и ошибочно рассматривает выбор стратегии паттерна фабрики как паттерн стратегии.

"Текущее понимание:"

  • Шаблоны проектирования определенно имеют свои варианты, нам не нужно быть слишком жесткими и ограничивать себя
  • Любое определение имеет свое общее понимание, мы не можем полностью сбиться с пути, пробиваясь сквозь себя
  • так"Суть шаблона реальной стратегии: инкапсуляция поведения, опора на интерфейсы и комбинирование вместо наследования."

Почему шаблон стратегии часто смешивают с шаблоном фабрики или перечислением?

Прежде всего, мы знаем исходное происхождение и ключевые моменты паттерна стратегии:"Сочетание абстракции и интерфейса поведения или алгоритма"

Затем возникает проблема, когда у нас есть несколько стратегий, количество и типы стратегий будут значительно увеличены, поэтому вызов N стратегий определенно требует простой логики для лучшего вызова, тогда перечисление стратегий или простое проектирование станет одним из первых способов, которыми мы учтите, а из-за этого будут недопонимания, которые я видел выше

стратегии в жизни

  • В LOL мне нравится играть за няню, потому что няня может добавлять кровь, поэтому при разработке навыков героя добавление крови — это поведение, и конкретные детали различны для каждого героя, что является проявлением режима стратегии.

  • Например, в сценарии оплаты мы будем извлекать заказ, статус, плательщика, деньги и другую информацию в информации о платеже, но детали платежа могут быть Alipay или WeChat.

Верный и неверный режим стратегии

При написании этой статьи я также проверил много информации в Интернете, и обнаружил, что режим стратегии у всех всегда имеет некоторые детали, которые отличаются.Далее я покажу часть кода.Вы можете субъективно судить, относится ли он к режиму стратегии. режим стратегии или нет. Замените другими шаблонами проектирования

/**
 * 网络玄幻小说的故事梗概接口
 * 固定的一些套路
 * 策略模式:网络小说的固定套路
 */
public interface Synopsis {
    /**
     * 穷困潦倒的开始
     */
    void badStart();

    /**
     * 突然有天遇到神人/捡到神器,实力大涨
     */
    void adventure();

    /**
     * 在一场战斗中以弱胜强
     */
    void winABattle();

    /**
     * 从此飞速成长
     */
    void growFast();

    /**
     * 组团刷怪,经历九死一生(主角怎么也死不了)
     */
    void manyFights();

    /**
     * 最终功成名就,妻妾成群
     */
    void succeed();

    /**
     * 组合起来就是小说内容
     */
    void getContent();
}

/**
 * 故事 A ,恶魔法则
 */
public class StoryA implements Synopsis {
    // 实现省略
}

/**
 * 故事 B ,诛仙
 */
public class StoryB implements Synopsis {
    // 实现省略
}

Класс выбора стратегии:

/**
 * 策略选择类
 */
public class WriteNovel {
    private Synopsis mSynopsis;     //故事梗概
    private String mMainActorName;  //主角名称

    /**
     * 梗概、内容都差不多确定后,换个名称就是另一部小说
     * @param mainName
     */
    public WriteNovel(String mainName){
        switch (mainName){
            case "张小凡":
                mSynopsis = new StoryB(mainName);
                break;
            case "杜维":
                mSynopsis = new StoryA(mainName);
                break;
            default:
                mSynopsis = new StoryB(mainName);
                break;
        }
    }

    /**
     * 获取小说内容
     */
    public void getNovelDetail(){
        mSynopsis.getContent();
    }
}

Наконец

Прикрепите UML-диаграмму шаблона стратегии.

UML-диаграмма шаблона стратегии

А потом трогательная маленькая история~

6 мая 2020 года я обнаружил ошибку в Nuggets, и не мог загрузиться весь интерфейс (исправлено~)

На следующий день я нашел г-жу Юхуо, директора по работе с продуктом, и дал ей положительный отзыв об ошибке.В то же время я дал небольшую рекомендацию для своей собственной статьи, а затем статью, которую я разместил для долгое время был в очередной раз на самой горячей странице.Одна,доказательства таковы(счастлив взорваться):

实锤

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

Ах~

Такого рода позитивная, техническая атмосфера - это то, к чему стремятся наши техники~, я надеюсь, что каждый сможет внести свой вклад и получить максимальное удовольствие от программирования и жизни!