面向对象设计原则01-单一职责原则.docVIP

单一职责原则 就一个类而言，应该只专注于做一件事和仅有一个引起变化的原因。这就是所谓的单一职责原则 。该原则提出了对对象职责的一种理想期望。对象不应该承担太多职责，正如人不应该一心分为二用。唯有专注，才能保证对象的高内聚；唯有单一，才能保证对象的细粒度。对象的高内聚与细粒度有利于对象的重用。一个庞大的对象承担了太多的职责，当客户端需要该对象的某一个职责时，就不得不将所有的职责都包含进来，从而造成冗余代码或代码的浪费。这实际上保证了DRY原则，即不要重复你自己（Dont Repeat Yourself），确保系统中的每项知识或功能都只在一个地方描述或实现。 单一职责原则还有利于对象的稳定。所谓职责，就是对象能够承担的责任，并以某种行为方式来执行。对象的职责总是要提供给其他对象调用，从而形成对象与对象的协作，由此产生对象之间的依赖关系。对象的职责越少，则对象之间的依赖关系就越少，耦合度减弱，受其他对象的约束与牵制就越少，从而保证了系统的可扩展性。 单一职责原则并不是极端地要求我们只能为对象定义一个职责，而是利用极端的表述方式重点强调，在定义对象职责时，必须考虑职责与对象之间的所属关系。职责必须恰如其分地表现对象的行为，而不至于破坏和谐与平衡的美感，甚至格格不入。换言之，该原则描述的单一职责指的是公开在外的与该对象紧密相关的一组职责。例如，在媒体播放器中，可以在MediaPlayer类中定义一组与媒体播放相关的方法，如Open 、Play 、Stop 等。这些方法从职责的角度来讲，是内聚的，完全符合单一职责原则中专注于做一件事的要求。如果需求发生扩充，需要我们提供上传、下载媒体文件的功能。那么在设计时，就应该定义一个新类如MediaTransfer，由它来承担这一职责；而不是为了方便，草率地将其添加到MediaPlayer类中。 分层架构模式实际上也体现了这一原则，它将整个系统按照职责的内聚性分为不同的层，层内的模块与类具有宏观的内聚性，它们关注的事情应该是一致的。例如，领域逻辑层就主要关注系统的业务逻辑与业务流程，而数据的持久化与访问则交由数据访问层来负责。以订单的管理为例，我们在领域逻辑层中定义如下的类OrderManager： public?class?OrderManager private?IOrderRepository?repository RepositoryFactory.CreateOrderRepository ; public?void?Place Order?order if? order.IsValid repository.Add Order ; else throw?new?InvalidOperationException Order?cant?be?placed.? ; public?void?Cancel Order?order if? order.IsValid ??order.CanCancel DateTime.Now repository.Remove Order ; else throw?new?InvalidOperationException Order?cant?be?canceled.? ; public?static?class?RepositoryFactory public?static?IOrderRepository?CreateOrderRepository return?new?OrderRepository ; OrderManager类的实现体现了单一职责原则的思想。首先，OrderManager类中的Place 和Cancel 方法均属于订单管理的业务逻辑，与领域逻辑层关注的事情是一致的。在这两个方法的实现中，我们需要检验订单的正确性（检验订单是否包含了必要的信息，如联系人、联系地址与联系电话），以及判断当前时间是否在允许取消订单的时间范围内。虽然它们仍然属于订单处理的业务逻辑，但拥有这些检查信息的是Order对象，而不是OrderManager，即Order对象是检查订单的信息专家 。因此，IsValid 和CanCancel 方法应该被定义在Order类中。至于添加和移除订单的操作，虽然保证了下订单和取消订单的业务逻辑实现，但其实现却属于数据访问层的范畴，因而该职责被委派给了OrderRepository类 。至于RepositoryFactory类，则是负责创建OrderRepository对象的工厂类。这些类的职责以及协作关系如图2-4所示。 图2-4? 订单处理的职责与协作 将数据访问的逻辑从领域对象中分离出去是有道理的，因为数据访问逻辑的变化方向与订单业务逻辑的变化方向是不一致的，引起职责发生变化的原因也不相同。这也是单一职