设计模式之6大原则

好久没有更新博客了,一个自己这段时间忙于项目;另外一个原因就是自己这段时间干了一件美满的事情,找到了人生的另一半(虽然现在还是女朋友阶段);但是我还是希望能够有足够的时间、心情能够将自己这段时间的一些收获用文字的形式记录下来;

说到设计模式,其实大家都不陌生,应该说都是非常熟悉的。因为在项目里面都会不知不觉的用到它们,我想最耳熟能详的单例模式,大家应该都是熟悉的“不要不要”的吧。但是如果我问你,在设计模式里面有6条最基本的设计原则,你知道是哪些吗?

单一职责原则,这条原则大家望文生义就应该知道它大概的主旨思想了。讲的是一个对象类、方式里面尽量只完成一件事情,只完成属于它所在范畴里面的事情。比如:吃饭这件事情,你会需要做什么事情呢?吃饭之前你肯定需要先洗菜、切菜、炒菜、煮饭...,那如果我们用程序来模拟一下这个场景呢?首先我们来定义一个菜类Vegetables,在这个菜类里面我们希望做什么事情呢?首先定义两个属性,分别表示整个做菜过程中的时间和菜的数量,然后有三个方法分别表示洗菜、切菜、煮菜的动作。请看下面的类图:,然后我们再来看看饭的动作,它应该具有哪些属性呢?首先我们同样需要定义一个属性time,两个方法:淘米、设时开煮,请看下面的类图:。看到这里你会不会觉得有什么不妥的地方吗?这里我们留个自由发挥的地方,大家可以自己想想。

里氏替换原则,这什么意思呢?光从字面理解好像并不能很准确理解它的含义。让我们来看看,最正宗的定义:如果对每一个类型为S的对象o1,都有类型为T的对象o2,使得以T定义的所有程序P在所有的对象o1都代换成o2时,程序P的行为没有发生变化,那么类型S是类型T的子类型。哦,其实里氏替换原则说白了就是面向对象里面的抽象、继承。通过抽象、继承的扩展我们可以获得很好的扩展性、封装性。下面让我们来模拟一下这个常用场景:我们去买水果,通过水果的颜色、大小、价格来决定是否购买。买完水果回家,我们需要洗洗、尝尝水果。首先我们肯定需要模拟出一个基类,里面应该包含水果的相关属性。然后通过扩展该基类来获取不同水果,最后就开始进入洗、吃的阶段了。请看下面的类图:,通过里氏替换原则,我们将可以很容易的扩展出新的水果。

依赖倒置原则,这个名字可能比较抽象。但是如果写出下面几个特性:1.模块之间的依赖关系都是通过接口或者抽象类发生的,两个模块之间不存在直接的依赖关系;2.接口或者抽象类不依赖于实现类;3.实现类依赖于接口或者抽象类;通过上面的特性分析,我们就能够总结出依赖倒置原则的好处了:能够有效的降低系统之间的耦合,增强系统的稳定性;说到这里也许你就应该明白,依赖倒置说白了就是面向抽象编程。当我们在一个对象里面需要注入另外一个对象的时候,通常来说有两种方式:1.构造函数注入;2.Set方法注入;3.接口注入;让我们来具体看一个例子:,如果我拿到了C照是不是不管宝马还是奔驰我都应该可以开呢?那肯定是的,所以我们让宝马和奔驰都实现ICar接口,然后通过构造函数注入的方式去让每一个司机都有一辆车。这样的话,我们最终只要在device方法里面调用ICar的run方法就可以了。以后不管司机是否会换车,我们只要添加新的ICar实现就好了。

接口隔离原则,说白了就是面向接口变成。但是这个原则要求我们做到:接口尽量简单、纯洁,就是一个接口里面不要去做太多的事情;

迪米特原则,就是封装原则。这个原则在我们的项目开发过程中可能经常会遇到,比如我们需要给第三公司提供SDK,但是我又想第三方公司对我们公司的SDK尽量少知道,只需要按照我给他们的手册一步一步调用指定的方法就可以了,其他的不需要他们关心;所以当我们在项目里面想要按照迪米特原则去写代码的时候,就是一个类只和自己有关系的那个类发生关系,其他的我遵循高内聚、低耦合;请看下面的例子:老师让学习委员清点班级女生的人数。UML图如下:在这三个类里面,老师只需要知道学习委员,通过学习委员来清点人数。当学习委员点数的时候,响应的女生只需要回答:“到”就可以了。

开闭原则,相信这个原则大家肯定非常的熟悉。”面向扩展开放、面向修改关闭“,其实在上面的依赖倒置原则和里氏替换原则我们就可以在一定程度上面能够实现扩展开放,然后迪米特原则我们又可以在一定程度上面实现修改关闭,这样的话就要求我们在定义一个类的时候,尽量遵照最小权限原则;

时间: 2024-10-13 05:17:16

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

设计模式之6大原则(5)-迪米特法则

迪米特法则(Law of Demeter)又叫作最少知识原则(Least Knowledge Principle 简写LKP),就是说一个对象应当对其他对象有尽可能少的了解,不和陌生人说话.英文简写为: LoD. 迪米特法则可以简单说成:talk only to your immediate friends. 对于面向OOD来说,又被解释为下面几种方式:一个软件实体应当尽可能少的与其他实体发生相互作用.每一个软件单位对其他的单位都只有最少的知识,而且局限于那些与本单位密切相关的软件单位. 迪米特

设计模式之6大原则(6)开闭原则

1. more第一版 实现基础功能,显示每一页固定24行文本,"q Enter"退出, "Enter" 下一行, "space Enter"下一页. /************************************************************************* > File Name: more01.c > Author: qianlv > Mail: [email protected] &

[设计模式](转)Java中的24种设计模式与7大原则

*:first-child { margin-top: 0 !important; } body > *:last-child { margin-bottom: 0 !important; } a { color: #4183C4; text-decoration: none; } a.absent { color: #cc0000; } a.anchor { display: block; padding-left: 30px; margin-left: -30px; cursor: poin

设计模式的6大原则:也是编程者编程时应该追求和遵循的

1.开闭原则(Open Close Principle) 开闭原则就是说对扩展开放,对修改关闭.在程序需要进行拓展的时候,不能去修改原有的代码,实现一个热插拔的效果.所以一句话概括就是:为了使程序的扩展性好,易于维护和升级.想要达到这样的效果,我们需要使用接口和抽象类,后面的具体设计中我们会提到这点. PS:曾经笔者面试的时候,被问过,为何要使用接口编程,那个时候我答不上来,准确说是没深入了解开闭原则之前,我都不能答上. 2.里氏代换原则(Liskov Substitution Principl

24种设计模式与6大原则

一.总体来说设计模式分为三大类: 创建型模式,共五种:工厂方法模式.抽象工厂模式.单例模式.建造者模式.原型模式. 结构型模式,共七种:适配器模式.装饰器模式.代理模式.外观模式.桥接模式.组合模式.享元模式. 行为型模式,共十一种:策略模式.模板方法模式.观察者模式.迭代子模式.责任链模式.命令模式.备忘录模式.状态模式.访问者模式.中介者模式.解释器模式. 二.设计模式的六大原则 1.开闭原则(Open Close Principle) 开闭原则就是说对扩展开放,对修改关闭.在程序需要进行拓

Java中的24种设计模式与7大原则 (转)

一.创建型模式 1.抽象工厂模式(Abstract factory pattern): 提供一个接口, 用于创建相关或依赖对象的家族, 而不需要指定具体类.2.生成器模式(Builder pattern): 使用生成器模式封装一个产品的构造过程, 并允许按步骤构造. 将一个复杂对象的构建与它的表示分离, 使得同样的构建过程可以创建不同的表示.3.工厂模式(factory method pattern): 定义了一个创建对象的接口, 但由子类决定要实例化的类是哪一个. 工厂方法让类把实例化推迟到子

Java中的24种设计模式与7大原则

一.创建型模式 1.抽象工厂模式(Abstract factory pattern): 提供一个接口, 用于创建相关或依赖对象的家族, 而不需要指定具体类.2.生成器模式(Builder pattern): 使用生成器模式封装一个产品的构造过程, 并允许按步骤构造. 将一个复杂对象的构建与它的表示分离, 使得同样的构建过程可以创建不同的表示.3.工厂模式(factory method pattern): 定义了一个创建对象的接口, 但由子类决定要实例化的类是哪一个. 工厂方法让类把实例化推迟到子

设计模式之7大原则

一.单一职责原则 类的职责要单一,不能将太多的职责放在同一个类中 二.开放封闭原则 软件实体对扩展开放,对修改关闭. (注:软件实体可以指一个软件模块.一个由多个类组成的局部结构或一个独立的类. 抽象化是开闭原则的关键) 三.里氏代换原则 在软件系统中,能接受基类对象的地方,必然可以接受一个子类对象 (注:里氏代换原则是实现开闭原则的重要方式之一,由于使用基类对象的地方都可以使用子类对象,因此在程序中尽量使用基类类型来对对象进行定义,而在运行时再确定其子类类型,用子类对象来替换父类对象.) 四.

设计模式6大原则

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