设计模式-单一职责原则（简介和使用）

一、简介

  单一职责原则 准确的解释应该是,就一个类而言,应该仅有一个引起它变化的原因.

  如果一个类有一个以上的职责,这些职责就耦合在了一起.当一个职责发生变化时,可能会影响其他的职责.并且也会影响复用.

  此原则的核心是解偶和增强内聚性.遵守单一职责原则,将不同的职责封装到不同的类或模块中.

  比如,T负责两个不同的职责:职责P1,职责P2,当由于职责P1需求发生变化而需要改变类T时,有可能会导致原本运行正常的职责P2功能发生故障.职责P1和P2被偶和在了一起.

  单一职责原则不仅仅是面向对象编程思想所特有的,只要是模块化的程序设计,都适用单一职责原则,比如这个原则不仅仅适用于类,还适用于方法.

二、举例

  1.service层负责业务处理,dao层负责数据库操作.

  2.ProductController负责商品相关职责,OrderController负责订单相关职责.商品和订单解偶互不干涉.

  3.之前做供应链项目的时候设计库存更改的dubbo接口,一开始写了一个通用接口,通过参数区分业务场景(下单、支付、退款、退货、换货等等),后来发现越来越多,这个接口的内容也越来越负责,每次修改都要考虑对所有的业务影响..这种情况就是没有遵守单一职责原则导致,后来根据业务场景和实现功能将dubbo接口拆分成多个,既解耦合了,又将dubbo接口的压力分散开.