程序设计--设计模式六大原则
设计模式
面向对象语言开发过程中,遇到各种场景和问题的解决方案和思路,沉淀下来就是设计模式(套路)
设计模式六大原则
面向对象语言开发过程中,推荐的一些指导性的原则(并不是强制要求的)
- 类T负责两个不同的职责。职责P1,职责P2。当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障。
- 方法层面:也需要考虑单一职责原则,方法有多个分支或还可能发生扩展变化的,最好拆分成多个方法。从方法层次实行单一职责。
- 类层面:肯定要遵循单一职责原则,一般业务开发流程,接受输入–数据验证–逻辑计算–数据库操作–日志。这些一般都需要分层次编写。从类的层次实行单一职责。
- 类库层面:把项目拆分成多个类库,可以重用,方便维护。从类库层次实行单一职责。
- 项目层面:把系统拆分成多个项目;客户端;管理后台;定时任务;远程接口;从项目层次实行单一职责。
- 系统层次:(也可以理解为微服务)成熟的互联网企业有许多产品、项目,有很多重复的功能,比如IP库/日志库/监控系统/在线统计等等,这些功能可以用服务的形式进行提供。从系统层次实行单一职责。(服务方式 1 ,定时任务2)
- 子类必须完全实现父类有的方法,如果子类没有父类的某项东西,就断掉继承;
- 子类可以有父类没有的东西,所以子类出现的地方,不一定能用父类来代替。
- 透明,就是安全,父类的东西换成子类后不影响程序
a. 父类已经实现的东西,子类不要去隐藏基类的东西(子类可以用new来隐藏)
b. 父类已经实现的东西,想改的话,就必需用virtual+override 避免埋雷
- 两个名词:
a. 直接朋友,类A和B的关系为关联或组合或聚合,那么他们就是直接朋友。
b. 间接朋友,类A依赖B,B就是A的间接朋友。 - 迪米特法则本质为只和直接朋友通信,
- 去掉内部依赖------降低访问修饰符
- 门面模式(也叫外观模式)遵循的就是迪米特法则,举个例子:
一个客户端执行订单操作,它需要生成订单-----操作库存-----操作钱库-------写日志,等一系类操作。虽然这些操作都是客户端的直接朋友,但是客户端直接操作这些朋友明显是不好的。这时就需要在封装一层门面类来操作这些朋友,客户端操作门面类。 - 中介者模式,也是用的迪米特法则。举个例子:
服务A、B、C、D、E、F,两两之间都有可能进行通信,那么A就有BCDEF五个直接朋友,同理每个服务都有五个朋友,这样就造成了依赖混乱。中介者模式就是起一个中介者的服务G,G有ABCDEF六个朋友,由G负责中转通信。这样G的依赖度上升,但ABCDEF的依赖都降低了,这就是中介者模式。
- 依赖抽象9而不是依赖细节。
- 也就是面向抽象编程,底层模块里面尽量都有抽象类/接口;在声明参数、变量、属性的时候,尽量的都是接口/抽象类。
- 依赖细节:程序写死了,不谈什么扩展。
- 依赖抽象,更具有通用性;而且具备扩展性;
- 细节是多变的,抽象是稳定的;
- 系统架构基于抽象来搭建,会更稳定,更具备扩展性。
- 扩展技巧:建议接口和实现分开生成DLL。
- 一个类对另一个类的依赖应该建立在最小的接口上;
- 实现一个接口的时候,只需要自己必须的功能;
- 通俗来说就是,一个接口可以代表多个功能(但不包括实现);但是接口隔离原则建议一个接口只代表一个功能或一个单位的功能。
- 用到哪个功能就实现哪个接口。
- 接口隔离原则不建议,建立一个功能大而全的接口;原则建议拆分功能。
- 如果有对功能扩展变化的需求,希望是增加类而不是修改
- 修改可能会影响原有的功能,引入错误;增加类就不会影响原有的东西。
- 原则的原则,五大原则是手段,这个是目标。
- 扩展功能时,从影响最大的做法-------->影响最小的做法:
修改方法–>增加方法(修改类) -->增加类 --> 增加dll -->修改配置文件