没有合适的资源?快使用搜索试试~ 我知道了~
资源推荐
资源详情
资源评论
11 种设计原则
类原则
1.单一职责原则 - Single Responsibility Principle(SRP)
就一个类而言,应该仅有一个引起它变化的原因。 职责即为“变化的原因”。
2.开放-封闭原则 - Open Close Principle(OCP)
软件实体(类、模块、函数等)应该是可以扩展的,但是不可修改。对于扩展是开放的,对于更改是封闭的. 关键是抽象.将一个功能的通用部分和
实现细节部分清晰的分离开来。开发人员应该仅仅对程序中呈现出频繁变化的那些部分作出抽象. 拒绝不成熟的抽象和抽象本身一样重要 )
3.里氏替换原则 - Liskov Substitution Principle(LSP)
子类型(subclass)必须能够替换掉它们的基类型(superclass)。
4.依赖倒置原则(IoCP) 或 依赖注入原则 - Dependence Inversion Principle(DIP)
抽象不应该依赖于细节。细节应该依赖于抽象。Hollywood 原则: "Don't call us, we'll call you". 程序中所有的依赖关系都应该终止于抽象类
和接口。针对接口而非实现编程。任何变量都不应该持有一个指向具体类的指针或引用。任何类都不应该从具体类派生。 任何方法都不应该覆写他的任
何基类中的已经实现了的方法。
5.接口隔离原则(ISP)
不应该强迫客户依赖于它们不用的方法。接口属于客户,不属于它所在的类层次结构。多个面向特定用户的接口胜于一个通用接口。
包(类库、DLL)内聚原则
6.重用发布等价原则(REP)
重用的粒度就是发布的粒度。
7.共同封闭原则(CCP)
包(类库、DLL)中的所有类对于同一类性质的变化应该是共同封闭的。 一个变化若对一个包产生影响, 则将对该包中的所有类产生影响, 而对于其
他的包不造成任何影响。
8.共同重用原则(CRP)
一个包(类库、DLL)中的所有类应该是共同重用的。
如果重用了包(类库、DLL)中的一个类,
那么就要重用包(类库、DLL)中的所有类。
(相互之间没有紧密联系的类不应该在同一个包(类库、DLL)中。)
包(类库、DLL)耦合原则
9.无环依赖原则(ADP)
在包的依赖关系图中不允许存在环。
10.稳定依赖原则(SDP)
朝着稳定的方向进行依赖。
应该把封装系统高层设计的软件(比如抽象类)放进稳定的包中,不稳定的包中应该只包含那些很可能会改变的软件(比如具体类)。
11.稳定抽象原则(SAP)
包的抽象程度应该和其稳定程度一致。一个稳定的包应该也是抽象的,一个不稳定的包应该是抽象的. )
其它扩展原则
12.BBP(Black Box Principle)黑盒原则
多用类的聚合,少用类的继承。
13.DAP(Default Abstraction Principle)缺省抽象原则
在接口和实现接口的类之间引入一个抽象类,这个类实现了接口的大部分操作.
14.IDP(Interface Design Principle)接口设计原则
规划一个接口而不是实现一个接口。
15.DCSP(Don't Concrete Supperclass Principle)
不要构造具体的超类原则,避免维护具体的超类。
16.迪米特法则
一个类只依赖其触手可得的类。
Open-Closed Principle 软件设计中的“开-闭原则”
这个原则最早是由 Bertrand Meyer 提出,英文的原文是:Software entities should be open for extension,but closed for modification.意思是
说,一个软件实体应当对扩展开放,对修改关闭.也就是说,我们在设计一个模块的时候,应当使这个模块可以在不被修改的前提下被扩展,换句话说就是,
应当可以在不必修改源代码的情况下改变这个模块的行为.
满足 OCP 的设计给系统带来两个无可比拟的优越性.
1.通过扩展已有的软件系统,可以提供新的行为,以满足对软件的新需求,使变化中的软件系统有一定的适应性和灵活性.
2.已有的软件模块,特别是最重要的抽象层模块不能再修改,这就使变化中的软件系统有一定的稳定性和延续性
接口隔离原则 isp
一个类对另一个类的依赖应该表现成依赖尽可能小的接口。
这个原则是用来处理胖接口的缺陷,避免接口承担太多的责任。比如说一个接口内的方法可以被分成好几组,分别为不同的客户程序服务,说明这个接
口太胖了。当然,确实也有一些类不需要内聚的接口,但这些类不应该做为单独的类被客户程序直接看到,而应该通过抽象基类或接口来关联访问。
接口污染
所谓接口污染就是为接口添加了不必要的职责。在接口中加一个新方法只是为了给实现类带来好处,以减少类的数目。持续这样做,接口就被不断污染,
变胖。实际上,类的数目根本不是什么问题,接口污染会带来维护和重用方面的问题。最常见的问题是我们为了重用被污染的接口,被迫实现并维护不
必要的方法。
分离客户程序就是分离接口。如果客户程序是分离的,那么相应的接口也应该是分离的,因为客户程序对它们使用的接口有反作用力。通常接口发生了
变化,我们就要考虑所有使用接口的客户程序该如何变化以适应接口的变化。如果客户程序发生了变化呢?这时也要考虑接口是否需要发生变化,这就
是反作用力。有时业务规则的变化不是那么直接的,而是通过客户程序的变化引发的,这时我们就需要改变接口以满足客户程序的需要。
分离接口的方式一般分为两种,委托和多继承。前者把请求委托给别的接口的实现类来完成需要的职责,后者则是通过实现多个接口来完成需要的职责。
两种方式各有优缺点,通常我们应该先考虑后一个方案,如果涉及到类型转换时则选择前一个方案。
胖接口会导致客户程序之间产生不必要的耦合关系,牵一发而动全身。分解胖接口,使客户程序只依赖它需要的方法,从设计上讲,简单易维护,重用
度也高。
写出漂亮代码的七种方法
首先我想说明我本文阐述的是纯粹从美学的角度来写出代码,而非技术、逻辑等。以下为写出漂亮代码的七种方法:
1, 尽快结束 if 语句
例如下面这个 JavaScript 语句,看起来就很恐怖:
1 function findShape(flags, point, attribute, list) {
2 if(!findShapePoints(flags, point, attribute)) {
3 if(!doFindShapePoints(flags, point, attribute)) {
4 if(!findInShape(flags, point, attribute)) {
5 if(!findFromGuide(flags,point) {
6 if(list.count() > 0 && flags == 1) {
7 doSomething();
8 }
9 }
10 }
11 }
12 }
13 }
但如果这么写就好看得多:
1 function findShape(flags, point, attribute, list) {
2 if(findShapePoints(flags, point, attribute)) {
3 return;
4 }
5
6 if(doFindShapePoints(flags, point, attribute)) {
7 return;
8 }
9
10 if(findInShape(flags, point, attribute)) {
剩余98页未读,继续阅读
资源评论
小小哭包
- 粉丝: 1906
- 资源: 3930
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
最新资源
- java(结合lucene)版的公交搜索系统
- 【OpenHarmony】ArkTS 语法基础 ④ ( ArkTS UI 渲染控制 - 条件渲染 - 循环渲染 )
- 稽查监控平台标准化设计数据模型设计
- 一款极好用的 Office/WPS/Word/Excel/PPT/PDF工具箱软件 OfficeUtils 2.7
- 基于STM32的家庭环境参数检测系统设计
- 夺宝答题王答题小程序源码 开源可二开 Thinkphp内核
- Linux 系统下 Hadoop 安装配置教程.md
- 用于 CH32 MCU 的 CMake 实用程序(基于 STM32-CMake Proejct
- Linux 系统下 Hadoop 安装配置教程.md
- 基于ESO的 PMSM无传感器控制仿真-Matlab 2021b
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功