策略模式

在现在的开发中，大概有23种设计模式，其中用途最多最广的无外乎单例，策略，适配器，委托几种模式，大概讲一下策略模式，因为可能会用到。

策略模式简单来说就是根据不同的环境和条件自动选择不同的算法和实现，即策略模式是对算法的封装，它把算法的责任和算法本身分割开，委派给不同的对象管理。

下面看一段代码（大概看上两三行就可以继续往下翻）：

public static void setAction(JMenuItem menuItem) {
        if (menuItem.getText().equals("New")) {
            menuItem.addActionListener(
                    event -> {
                    //someting to do.
                    }
            );
        } else if (menuItem.getText().equals("Open")) {
            menuItem.addActionListener(
                    event -> {
                        //someting to do.
                    }
            );
        } else if (menuItem.getText().equals("Exit")) {
            menuItem.addActionListener(
                    event -> {
                        //someting to do.
                    }
            );
        } else if (menuItem.getText().equals("Goto")) {
            menuItem.addActionListener(
                    event -> {
                        //someting to do.
                    }
            );
        } else if (menuItem.getText().equals("Help")) {
            menuItem.addActionListener(
                    event -> {
                        //someting to do.
                    }
            );
        } else if (menuItem.getText().equals("Windows")) {
            menuItem.addActionListener(
                    event -> {
                        //someting to do.
                    }
            );
        } else if (menuItem.getText().equals("Setting")) {
            menuItem.addActionListener(
                    event -> {
                        //someting to do.
                    }
            );
        }
}

简单看来，这段代码是用到了策略模式，不过和我们所看到的标准定义有所不同，他是通过if和else来进行的判断。

NOTE：所谓设计模式，其实并没有标准定义，而我所说的“标准定义”其实是，被大家公认的，接受的定义，因为有了定义才方便我们去交流，不然我们交流起来就是——“我写了一个方法（函数），去将各个不同的算法封装，然后将参数传递给这个方法之后，由该方法去决定如何选择算法。” 又臭又长，谁愿意看，切记一点，设计模式是一种思想，虽然现在被形式化的定义了，但是却并不是必要关系。有了设计模式的思想才有了形式化的定义，而不是有了形式化的定义之后才有了设计模式，不要颠倒因果关系（也别死磕）。

可以看出来这应该代码应该是写的菜单事件，还用了Lambda表达式，嘿哟，有点儿意思。

但是也能看出来，硬伤很多，先不说后期可能增加的菜单项有多少，就说为了完善这个按钮事件，代码量就绝对不会少，一个函数封装了百行以上的代码，真的是很少见了。

这有违我们追求的简洁代码。

简化代码

对这段代码的简化很简单，每个人都有每个人不同的方法。

就比如说：

按钮事件的实现分发给其他方法，在这个方法中不对按钮的事件进行实现，在本方法中只保存if…else…结构，这样一来，我们保证了一个函数\方法完成一个功能这一准则，方便了后期的维护。
当然了，我们还能使用多类，每一个类职责单一，如上述代码，NewItem类实现按钮New的功能，由于是一个类，我们甚至可以为这个按钮做更多事情。不难想象，这样会扩充类库，使类库变得更加臃肿（可能只有大型项目会要求避免这种问题），但，不失为一个很好的方法。
路由……对上述代码的结构和功能可能不太实用。

简单来条实现（真的很简陋）：

public static void setAction(JMenuItem menuItem) {
	//这里使用反射，也就是采用了上述第二个方法。
	if (menuItem.getText().equals("New") setAction("New", menuItem);
	//else if ……
}

方法多种多样，但要记住一句话：方法本身是没有对不对的问题，有的只是适不适合的问题。

择优啊，兄弟们。

笔者注：标题浮夸了不行，太务实也不行，这就是我讨厌起标题的原因了。