公司的手游大概是11月上线，目前我在做抽奖模块,写这个模块用到了几个常用的设计模式，现在，在这里和一些对设计模式概念比较模糊的同学做一个简单的交流。通过了解一些常用的设计模式后，把这些设计模式运用到自己的项目中，你会发现自己的代码质量提高很多，别的同学读你的代码也简单易懂，老是写让人家看不懂的代码，这样不太好，假设你离职不干了，谁敢去维护你的代码，因为，你在代码里‘下毒’。

在了解设计模式前，先说六大设计原则：

1.单一职责原则

2.里氏替换原则

3.依赖倒置原则

4.接口隔离原则

5.迪米特法则

6.开闭原则

首先来了解，第一大原则。

单一职责原则:应该有且仅有一个原因引起类的变更,英文名称是 Single Responsibility Principle,简称SRP.

现在手游火到不行了，不过用户平台还是被老马给占领了，不得不让我们这些码农更加努力做出好的游戏。下面以RPG游戏中的一个抽奖模块来说明这个原则。

抽奖模块介绍：

有两种宝箱，一种是青铜宝箱，另一种是黄金箱。每个宝箱都有自己的属性：1.宝箱名称（只举一个属性）。每个宝箱有三种抽奖方式：1.免费抽奖，2.抽一次，3抽十次。

宝箱里有这么多信息和行为要去维护，那设计一个这样的接口：

这个类图画出来后，你就会觉得有问题，因为宝箱的属性和宝箱的行为没有分开，这一点咱都知道。那科学一点，把宝箱属性抽取成一个BO（bussiness object，业务对象）,把宝箱行为抽取成一个BIZ(bussiness logic,业务逻辑)。重新封装这两个接口，IChestInfo的职责是就是用来加载宝箱信息和反馈宝箱信息，IChestBiz的职责就是负责完成宝箱的抽奖。如下图：

现在是面向接口编程，Chest这个类实现了IChestInfo就可以 获取宝箱的基础信息，实现了IChestBiz就可以进行宝箱抽奖。

单一职责原则的定义：应该有且仅有一个原因引起类的变更。

对于接口在设计的时候，一定要做到单一，但是对于实现类就需要多方面考虑了。生搬硬套单一职责原则会引起类的倶增，给维护带来麻烦，原则是死的，人是活的。

对接口，类，方法使用了单一职责原则，那么快乐的不仅仅的是你，还有你身边的小伙伴，大家可以进行轻松愉快的开发，减少了无谓的人员和资源浪费。