设计原则能够帮助我们发现程序中的问题，并能够促使程序代码看上去清晰明了。
设计原则有很多，经常用到的有以下5个：
1. 单一职责原则；
2. 开放封闭原则；
3. 里氏替换原则；
4. 依赖倒置原则；
5. 接口隔离原则；
在实践中发现TDD的开发方式能够更容易维护一个相对单一的职责。相关阅读：《为什么那些人选择TDD这种方式开发？》
这些原则的组合使用，能够实现代码上的高内聚、低耦合、易修改。这篇文章将聚焦设计原则中的单一职责原则。
单一职责原则指对一个类或者一个方法而言，引起其变化的只有一个原因。
什么是职责？
职责可以被定义为“变化的原因”，如果你能够想到多于一个动机去改变类，那么这类就具有多于一个的职责。这是较为严格的定义。
知易行难，工作中我们会遇到多种场景，以下列举了3中场景：
1. 有的场景因为简单我们会始终坚持单一职责原则;
2. 有的场景稍微复杂，注意力有可能就被转移到某个环节，而忽略了单一职责原则；
3. 还有一些场景，对这是一个类或者一个方法是职责是一个还是多个会犹豫不决。
我们不妨通过一个例子来看看如何保持一个类或者方法的职责单一。
需求
这是一个被简化了的需求
创建订单：将商品，收件人名称、电话、地址保存到订单信息
实现
单考虑单一职责原则，我们可以用下面的实现方法。
Order.java
public class Order {
private String id;
private String productId;
private String consignee;
private String consigneePhoneNumber;
private String consigneeAddress;
}
OrderService.java
@Service
public class OrderService {
@Autowired
private OrderRepository orderRepository;
public void createOrder(Order order) {
orderRepository.save(order);
}
}
在上面的例子中，OrderService.java包含一个方法createOrder职责算是单一的，因为引起变化的原因和订单订单相关。
因为上面的场景足够的简单，所以很容易体现单一职责原则。那么，更具业务稍加修改就能让这个类的职责不在再是职责单一的类。
假设新需求要求，创建订单前应该扣减库存，你会怎么改这段代码呢？
下面我列举了三种常见的修改代码的方法，你看看哪种符合单一职责原则。
修改方法一
如果你只是在createOrder中添加几行，例如下面的代码
public void createOrder(Order order) {
Product product = productRepository.findOne(order.getProductId());
product.setCount(product.getCount()--);
productRepository.save(product);
orderRepository.save(order);
}
是不是着个方法职责变多了。查询商品，扩建商品数量，保存商品最新信息，保存订单。引起这个类变化的原因不再是order了，同时product相关信息的变化都会引起变化。
修改方法二
方法一，中有一扣减库存的实现不应该出现在OrderService中，应该单独抽离抽离出去，修改方法是这样的。
@Service
public class OrderService {
@Autowired
private OrderRepository orderRepository;
@Autowired
private ProductService productService;
public void createOrder(Order order) {
productService.deductInventory(order.getProductId());
orderRepository.save(order);
}
}
ProductService.java
@Service
public class ProductService {
@Autowired
product ProductRepository productRepository;
public void deductInventory(String productId) {
Product product = productRepository.findOne(order.getProductId());
product.setCount(product.getCount()--);
productRepository.save(product);
}
}
这个修改方法确实将扣减库存的职责抽离了出去，由ProductService来承担变化的响应。但是OrderService中的createOrder方法依旧职责不够单一，方法二相比于方法二，只是职责上转变了，由方法一的维护扣减逻辑过程变成了调度扣减，所以一旦发生发辫一起OrderService发生变化的仍旧不止一个。那么再来看看方法三。
修改方法三
在《Clean Code》中描述方法职责的描述：
方法应该只做一件事，做好一件事，只做一件事。
翻译的这么重复，就是在强调一个方法只做一件事。如果不加任何限制，你会发现这一件事可大可小，事情太大依旧是职责不单一。那么怎么办呢？
如果方法只做了该方法名下同一个抽象层及上的步骤，则函数还是只做了一件事。
为了更好的理解这句话，一上面的需求为例，创建订单可以认为是经历了两个步骤：扣减商品库存、保存订单信息。所以这两个步骤应该是在一个抽象层级上的。而具体扣减逻辑、订单保存的实现都是另外一个更细粒度的层级上的。
OrderContext.java
@Service
public class OrderContext {
@Autowired
private OrderService orderService;
@Autowired
private productService productService;
public void generateOrder(Order order) {
productService.deductInventory(order.getProductId());
orderService.createOrder(order);
}
}
OrderService.java
@Service
public class OrderService {
@Autowired
private OrderRepository orderRepository;
@Autowired
private ProductService productService;
public void createOrder(Order order) {
orderRepository.save(order);
}
}
ProductService.java
@Service
public class ProductService {
@Autowired
product ProductRepository productRepository;
public void deductInventory(String productId) {
Product product = productRepository.findOne(order.getProductId());
product.setCount(product.getCount()--);
productRepository.save(product);
}
}
通过上面的OrderService和ProductService保持单一的职责。但是OrderContext保持了相对单一则职责：创建订单是调度作用。但是似乎也并不完美，因为造成修改的原因不止一个。
那么不得不说方法四了，使用观察者模式。建议不对职责进行拆分。由于时间原因，暂时不上代码，后续将代码不上。
为了更加真实，我准备了下面这样一个场景，后续会更上代码和分析，现在就当作一道思考题吗，如果面对下面这个场景，你如何组织代码，保持单一职责原则？
需求场景：
订单下单时涉及到以下相关业务操作：
1. 价格计算；
2. 优惠券扣除；
3. 积分扣除；
4. 新积分计算；
5. 新积分增加；
6. 将订单中的商品从购物车商品消除；
7. 生成订单；
8. 启动30分钟反馈记时。
如果上文中有什么不对的地方，欢迎指正～。
网友评论