策略模式：网络小说的固定套路

百度一搜“唐家三少”，好家伙，几年不见又出了这么多新书，产量惊人啊！把这些小说简介一看，啧啧，还是那个 屌丝逆袭 套路啊。

知乎上唐家三少有人喷有人捧，但有几句说的比较中肯：

因为现在的读者很多都是学生，找部小说来看着激动一下，激动过后呢？再找小说来激动，就这样以此循环，虚度光阴。

也许不能全怪作者，写太好读者看不懂，小学生作文水平刚好能迎合绝大部分读者。

铁打的小说流水的读者，导致了当前网络小说的固定套路，作家只要把故事梗概提取出来，把主角名字、背景什么的一换，就又是一本新书。唉，竟无语凝噎。

这种情况用代码怎么实现呢，我们来试试。

• 不幸的开始

• 突然有天遇到神人/捡到神器

• 以弱胜强，暂露光芒

• 开挂似的升级超快

• 组团刷怪九死一生（主角怎么也死不了）

• 功成名就 + 妻妾成群

有了梗概剩下的就是填内容了，我们分别创建两个具体小说类 StoryA 、 StoryB：

故事 A ，跳舞的恶魔法则：

故事 B ，萧鼎的诛仙，这个小说的文笔、情节中是我最喜欢的小说之一，但也是有一些固定套路：

故事梗概、具体内容都有了，剩下的就是量产了，据悉 唐家三少 日产 7k 字，实在佩服：

可以看到，我们 把小说内容的选择封装在了 WriteNovel 中，减少了客户端与 WriteNovel 的耦合，这样等我们要换小说的具体实现时，客户端不用修改代码。

客户端只要输入主角名称，就可以得到一部小说，比如写一部类似诛仙的小说，主角名称为 张拭心：

@Test
public void testGetNovelDetail() throws Exception {
    WriteNovel writeNovel = new WriteNovel("张拭心");
    writeNovel.getNovelDetail();
}

我们可以把 WriteNovel 类中的 default 设置为 StoryB ，即 诛仙：

public WriteNovel(String mainName){
    switch (mainName){
        //...省略掉不关键的内容
        default:
            mSynopsis = new StoryB(mainName);
            break;
    }
 }

假如现在需求变了，要写一部穿越的小说，主角还是 张拭心，这时只需修改 WriteNovel 中的 default 设置为 StoryA ，即 恶魔法则 即可，客户端不需要修改：

我们将公共的情节提取到梗概接口 Synopsis 中，然后创建不同的故事类，写小说时WriteNovel 中有一个接口的引用，根据客户端传入主角名称创建不同的实现类。

可以发现，这其实就是把在客户端代码中的判断提取了出来，让客户端减少对具体实现的依赖，转向对接口依赖，不就是我们之前说的 设计模式六大原则： 老板是如何减轻负担的 – 依赖倒置原则 吗？(这里指投稿作者的博客文章)

其实这就是传说中的 策略模式。

策略模式封装了变化。

策略模式又叫算法簇模式。它定义了一系列的算法用来完成相同的工作。策略模式让算法独立于使用它的客户而独立变化。

– 大话设计模式

只要遇到很多 if-else 或者 有很多 case 的 switch，就可以考虑使用策略模式了，将这些行为独立的封装起来，可以在公共类中消除条件语句。

在实践中，只要听到需要在不同情况下应用不同的业务，就可以考虑使用策略模式来封装这种变化的可能性。