面向对象原则之一单一职责原则的爱恨情仇

这是我参与更文挑战的第8天，活动详情查看： 更文挑战

带你了解Android窗口机制Window、PhoneWindow和DecorView之间的关系

一、起因？

1、说到单一职责原则，很多人都会不屑一顾。因为它太简单了；
2、稍有经验的程序员即使从来没有读过设计模式、从来没有听说过单一职责原则；
3、在设计软件时也会自觉的遵守这一重要原则，因为这是常识。在软件编程中，谁也不希望因为修改了一个功能导致其他的功能发生故障。而避免出现这一问题的方法便是遵循单一职责原则。
4、虽然单一职责原则如此简单，并且被认为是常识，但是即便是经验丰富的程序员写出的程序，也会有违背这一原则的代码存在。

二、什么是单一原则？为什么使用

1. 按字面理解，单一职责原则就是自己只负责自己的事，不需要理会别人的事。如果了解面对对象编程，那么应该会很容易了解这个单一职责原则；
2. 在面对对象编程中，每个对象只负责自己的任务，比如该提供数据的就只是提供数据，该负责提供服务的就只提供服务，或者只是维护对象之间的关系，这样的开发方式代码耦合度较低，较灵活，易扩展。当然也可以一个对象负责多个任务，但是任务多了修改起来就比较容易影响到其他的任务。
3. 单一职责，追求的是简单明确的设计，强调的是分工明确，职责简单。这种设计，不局限于类的设计，可以扩展到任何一个程序逻辑单元的设计，如函数的设计，模块的设计，工程的设计，项目的设计，集群的设计等。

三、单一原则优点？

• 可以降低类的复杂度，一个类只负责一项职责，其逻辑肯定要比负责多项职责简单的多；
• 提高类的可读性，提高系统的可维护性；
• 变更引起的风险降低，变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响；
• 需要说明的一点是单一职责原则不只是面向对象编程思想所特有的，只要是模块化的程序设计，都适用单一职责原则。

四、案例分析详解

比如常见的淘宝的购物车

刚开始接口定义如下

public interface ICartShopping {/**** 去结算* @param o*/void toSelGoods(Object o);/**** 计算价格* @param o*/void calprice(Object o);/**** 校验价格*/void checkPrice();/**** 加载商品信息*/void goodDetails();/**** 优惠券信息*/void couponDetails();.........}
复制代码

分析如下：

1、一眼看起来接口设计还挺合理的没什么大的问题，功能都可以实现

2、实际开发中结算、商品信息、优惠券是不同的人开发的，里面的功能也是特别复杂，频繁的改动ICartShopping这个接口会给其他人造成影响，解耦性差，没有遵循单一原则

改动如下

public interface IGoodsShopping {/**** 加载商品信息*/void goodDetails();.........}

public interface ICouponShopping {/**** 优惠券信息*/void couponDetails();.........}

public interface ISelShopping {/**** 去结算* @param o*/void toSelGoods(Object o);/**** 计算价格* @param o*/void calprice(Object o);/**** 校验价格*/void checkPrice();.........}
复制代码

有问题不可怕，可怕的是，发现问题不去改动，不进步

单一原则总结如下：

单一职责的核心可以理解为：化整为零，将整体分解为局部的逻辑单元，不同的逻辑单元之间尽可能的相对独立，并且职责明确。例如，一个项目，可以分解为多个工程；一个工程，可以分解为多个模块；一个模块，可以分解为多个包和类；一个类，可以分解为多个属性和方法行为，设计层面的分解，可以对应到具体实现层面的分离。

带你了解Android窗口机制Window、PhoneWindow和DecorView之间的关系