越的专栏

为了更好的理解工厂模式，写了一个游戏中常用的例子：敌人死亡后的物品掉落。如果直接在敌人死亡后，采用if-else或者switch的方法决定掉落对象，也可以实现这项功能。这样，敌人所依赖的具体物品就太多了，而且只会越来越多。这时，如果物品的具体实现变了，你还要找到敌人掉落物品这段代码进行修改。其实如果结构理想，我们不论怎么修改物品的实现，都不应该影响到敌人里面的代码。之所以出现这种情况，就是因为

策略模式是把算法和使用算法的客户分离，使用组合的方式让他们之间产生联系的方法。复用是继承具有的最大优势之一，但同时也可能给维护带来很大的包袱。比如在使用多态时，有些子类的具体行为可能有区别，这时你的第一反应可能是覆盖这个方法，但如果这个区别在一直拓展呢？你要把每个子类中的方法全部覆盖一遍么，那么继承还有存在的意义吗？这种情况就是策略模式登场的时候了。策略模式的方法是：把这些行为与超...

首先，工厂模式可分为简单工厂模式和抽象工厂模式。简单工厂模式主要是把实例化推迟到子类中完成。抽象工厂模式则更注重抽象类之间的组合关系。虽然我们不断地为了把代码从实际工厂中解耦，但实例化还是无法避免的。所以，大部分情况下，抽象工厂是包含简单工厂的，即我们还是需要在具体工厂中使用简单工厂，完成具体的实例化操作。以老外最爱的比萨举例。首先，我们需要制作比萨的原料：// Dough

关于观察者模式，目前接触到的最直接最明显的，就是项目中用到的前端消息通讯了吧，偷个懒：点击打开链接这是之前自己写的前端通讯。原理就是使用委托+观察者，当有对象注册为观察者时，他还需要遵循主题的结构，传入自己在收到消息时，希望得到的数据。只要观察者加入主题的队列。主题就会通过委托，在触发消息的一瞬间，先把观察者需要的数据填充好，然后向所有关注这条消息的观察者发送消息。这样做最大的好处，就

这个模式先上例子吧，我也是看了第二遍才明白，第三遍才算掌握了点。希望直接把我的理解讲出来对大家有帮助。假如你现在在厨房，需要自己做个饭。手里的主食有米，面条等；菜有肉，蔬菜等。讲道理，你做个炒饭，肯定需要把米饭和肉啊菜啊什么的放一起炒；或者做个汤面，肯定需要把面条和肉，菜什么的放一起煮。假如我们现在要做炒饭，手里有肉和蔬菜（为了清楚点，少举几个例子）。先看一个简单粗暴的例子：p

今天写个状态机，吧。先假设我们的角色只有两个状态：攻击状态和受击状态。一般情况下，我们的代码可能是这样的： public enum State { Attack, BeHit, } public class Player { State state; public

今天下馆子喽。日常生活中，我们去饭店吃饭，其实就是一种设计模式的体现：命令模式。命令模式主要是把请求封装起来，把命令的请求者和命令的执行者解耦。在直白点，就是命令的请求者不知道具体的执行细节，而命令的执行者不知道谁在请求命令。他们之间唯一的联系就是命令对象本身了。再说回到我们的饭店。我们顾客一般到了饭店，就是把点的订单交给服务员。服务员再把顾客的订单交给厨师，厨师做对应的菜。在这个过程