设计模式的几大原则

1.单一职责原则

类的职责要单一,不能将太多的职能放在一个类中。

2.开闭原则

软件实体对扩展是开放的,但对修改是关闭的,即在不修改一个软件的基础上去扩展其功能。实现开闭原则的关键是抽象化,找到系统的可变因素,将它封装起来。

3.里氏替换原则

一个可以接受基类对象的地方必然可以接受一个子类对象。在程序中尽量使用基类类型来对对象进行定义,而在运行时再确定其子类类型,使用子类来替换父类对象。

4.依赖倒转原则

要针对抽象层编程,而不要针对具体类编程。

5.接口隔离原则

不应该依赖那些它不需要的接口,使用多个专门的接口来取代一个统一的接口。

6.合成复用原则

系统中应该尽量多使用组合/聚合关系,少用甚至不用继承关系。

在面向对象设计中,可以通过两种基本方法来复用已有的设计和实现,即通过组合/聚合关系或者通过继承。

继承复用:实现简单,易于扩展。但是破坏系统的封装性。从基类继承而来的实现是静态的,不可能在运行时发生改变,没有足够的灵活性,只能在有限的环境中使用。(“白箱”复用)

组合/聚合复用:耦合度相对较低,选择性地调用成员对象的操作,可以在运行时动态进行。(“黑箱”复用)

7.迪米特法则

一个软件实体对其他实体的引用越少越好,或者说如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用,减少类之间的耦合度。

时间: 2024-10-10 14:53:13

设计模式的几大原则的相关文章

设计模式的六大原则

设计模式六大原则(1):单一职责原则 定义:不要存在多于一个导致类变更的原因.通俗的说,即一个类只负责一项职责. 问题由来:类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障. 解决方案:遵循单一职责原则.分别建立两个类T1.T2,使T1完成职责P1功能,T2完成职责P2功能.这样,当修改类T1时,不会使职责P2发生故障风险:同理,当修改T2时,也不会使职责P1发生故障风险. 说到单一职责原则,很多人都会不屑一顾

设计模式——设计模式与设计原则

设计模式--设计模式与设计原则 一.设计模式  1.设计模式简介 设计模式(Design pattern)是一套被反复使用.多数人知晓的.经过分类编目的.代码设计经验的总结.使用设计模式是为了可重用代码.让代码更容易被他人理解.保证代码可靠性. 设计模式于己于他人于系统都是多赢的,设计模式使代码编制真正工程化,设计模式是软件工程的基石. 模式的经典定义:每个模式都描述了一个在我们的环境中不断出现的问题,然后描述了该问题的解决方案的核心,通过这种方式,我们可以无数次地重用那些已有的解决方案,无需再

设计模式之设计原则学习

设计模式的设计原则包含了:单一职责原则.里氏替换原则.依赖倒置原则.接口隔离原则.迪米特法则和开闭原则等6大原则. 单一职责原则(Single Responsibility Principle,简称SRP),英文介绍为:There should never be more than one reason for a class to change,即一个类,应当只有一个引起它变化的原因.单一职责原则,要求对象不能承担太多的职责,充分保证对象的高内聚.单一职责的优点有:1.降低了类的复杂性:2.提

设计模式之SOLID原则再回首

    本科阶段学过设计模式,那时对设计模式的五大原则--SOLID原则的概念与理解还是比较模糊,此时过去了2年时间,在学习<高级软件工程>课程中老师又提到了设计模式,课程中还详细讨论了五大原则的过程,这次SOLID原则再回首作者提出了一些更通俗的理解吧~ 一. 什么是设计模式?     那么,什么是设计模式呢? 从广义角度讲设计模式是可解决一类软件问题并能重复使用的设计方案; 从狭义角度讲设计模式是对被用来在特定场景下解决一般设计问题的类和相互通信的对象的描述,是在类和对象的层次描述的可重复

设计模式之六大原则(转载)

关于设计模式的六大设计原则的资料网上很多,但是很多地方解释地都太过于笼统化,我也找了很多资料来看,发现CSDN上有几篇关于设计模式的六大原则讲述的比较通俗易懂,因此转载过来. 原作者博客链接:http://blog.csdn.net/LoveLion/article/category/738450/7 一.单一职责原则 原文链接:http://blog.csdn.net/lovelion/article/details/7536542 单一职责原则是最简单的面向对象设计原则,它用于控制类的粒度大

设计模式6大原则

单一职责原则 里氏替换原则 依赖倒置原则 接口隔离原则 迪米特法则 开闭原则 设计模式六大原则(1):单一职责原则 定义:不要存在多于一个导致类变更的原因.通俗的说,即一个类只负责一项职责. 问题由来:类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障. 解决方案:遵循单一职责原则.分别建立两个类T1.T2,使T1完成职责P1功能,T2完成职责P2功能.这样,当修改类T1时,不会使职责P2发生故障风险:同理,当修

设计模式概述与原则

一 . 设计模式概述 总体来说设计模式分为三大类: 创建型模式,共五种:工厂方法模式.抽象工厂模式.单例模式.建造者模式.原型 模式. 结构型模式,共七种:适配器模式.装饰器模式.代理模式.外观模式.桥接模式. 组合模式.享元模式. 行为型模式,共十一种:策略模式.模板方法模式.观察者模式.迭代子模式.责任 链模式.命令模式.备忘录模式.状态模式.访问者模式.中介者模式.解释器模式. 具体如下: 其中创建型有: 一.Singleton,单例模式:保证一个类只有一个实例,并提供一个访问它的全局访问

设计模式之设计原则(中)

接口隔离原则(Interface Segregation Principle ),简称ISP:该原则核心思想就是客户端不应该被强迫实现一些不会使用的接口,应该把胖接口中的方法分组,然后用多个接口来代替,每一个接口只服务与一个子模块.这个跟上次分享的单一职责原则类似. 设计接口隔离原则的目的:当我们设计应用程序时,如果一个模块包含多个子模块,那我们应该正对该模块抽象.设想该模块由一个类实现,我们可以把系统抽象成一个接口,但是我们想要添加新的模块扩展程序时,如果要添加的模块只包含原来系统的一些子模块

设计模式--6大原则--单一职责原则

单一职责原则(Single Responsibility Principle),简称SRP. 定义: There should never be more than one reason for a class to change. 应该有且仅有一个原因引起类的变更. 有时候,开发人员设计接口的时候会有些问题,比如用户的属性和用户的行为被放在一个接口中声明.这就造成了业务对象和业务逻辑被放在了一起,这样就造成了这个接口有两种职责,接口职责不明确,按照SRP的定义就违背了接口的单一职责原则了. 下