设计模式六大原则
来源:互联网 发布:扣扣闪图制作软件 编辑:程序博客网 时间:2024/05/16 14:04
设计原则
单一职责原则
有且仅有一个原因引起类的变更
里氏替换原则
只要父类能出现的地方,子类就可以出现,使用者不需要知道是父类还是子类 (反过来就不一定行)
- 子类必须完全实现父类的方法
- 如果子类不能完整的实现父类的方法,或者父类的某些方法在子类中已经发生畸变,则建议断开父子继承关系,采用依赖,聚合,组合等关系代替继承
- 子类可以有自己的个性
- 子类出现的地方,父类未必可以胜任
- 但应避免子类的个性,一旦子类有个性,子类和父类的关系就很难调和了
- 覆盖或实现父类的方法时输入参数可以被 放大
- 子类方法的参数可以大于等于父类的方法的参数 (父类方法返回值或者父类方法返回值的父类)
- 覆写或实现父类的方法时输出结果可以被 缩小
- 子类方法的返回值可以小于等于父类方法返回值 (父类方法返回值或者父类方法返回值的子类)
依赖倒置原则
面向接口编程
- 高层模块不应该依赖低层模块,两者都应该依赖其抽象。
- 抽象不应该依赖细节。
- 细节应该依赖抽象。
接口隔离原则
类间的依赖应该建立在最小的接口上(适度)
迪米特原则
一个对象应该对其他对象有最少的了解
- 只和朋友交流
- 朋友类:出现在成员变量,方法的输入输出参数中的类称为朋友类,而出现在方法体内部的类不属于朋友类。
- JDK API提供的类除外
- 朋友间也是有距离的
- 一个类公开的public属性或方法越多,修改时涉及的面也就越大,变更引起的风险也就越大
- 设计时需要反复衡量,是否还可以再减少public方法和属性,是否可以加上final关键字等
- 是自己的就是自己的
- 如果一个方法放在本类中,既不增加类间关系,也对本类不产生负面影响,那就放置在本类中
- 谨慎使用Serializable
开闭原则
一个软件实体如类,模块和函数应该对扩展开放,对修改关闭。
一个项目的基本路径应该是这样的: 项目开放,重构,测试,投产,运维
其中重构可以对原由的设计和代码进行修改,运维尽量减少对原有代码的修改,保持历史代码的纯洁性,提高系统的稳定性
前5个原则是指导设计的工具和方法,而开闭原则才是其精神领袖。
抽象约束
- 通过接口或抽象类可以约束一组可能变化的行为,并且能够实现对扩展开放
- 通过接口或抽象类约束扩展,对扩展进行边界限定,不允许出现在接口或抽象类中不存在的public方法
- 参数类型,引用类型尽量使用接口或者抽象类,而不是实现类
- 抽象层尽量保持稳定,一旦确定即不允许修改
元数据控制模块行为
尽量使用源数据(配置参数)来控制程序的行为,减少重复开发。
达到极致: 控制翻转
制定项目章程
指定所有人员都必须遵守的约定
封装变化
- 将相同的变化封装到一个接口或抽象类中
- 将不同的变化封装到不同的接口或抽象类中,不应该有两个不同的变化出现在同一个接口或抽象类中
设计模式复习的读书笔记于《设计模式之禅第二版》
0 0
- 设计模式六大原则
- 设计模式六大原则
- 设计模式六大原则
- 设计模式六大原则
- 设计模式六大原则
- 设计模式六大原则
- 设计模式六大原则
- 设计模式六大原则
- 设计模式六大原则
- 设计模式六大原则
- 设计模式六大原则
- 设计模式六大原则
- 设计模式六大原则
- 设计模式六大原则
- 设计模式六大原则
- 设计模式六大原则
- 【设计模式】六大原则
- 设计模式六大原则
- linux_grub引导修复
- javascript中的this到底是神马
- JavaScript基础——JSON
- java Executors介绍
- iOS开发实践之UIWebView
- 设计模式六大原则
- C#学习笔记(二)变量
- Fragment android碎片化管理
- 链表之单链表约瑟夫问题(一)
- 自定义shape
- NSMutableString 使用
- Flask Web开发背景介绍及环境配置
- Random Walk for Image Segmentation 论文笔记
- 闪存浪潮下不得不知的知识(2)-颗粒篇