"围观"设计模式(28)--总结之设计模式六大准则

设计模式源码下载地址

设计模式源码下载地址

1 单一功能原则

单一功能原则(Single responsibility principle)规定每个类都应该有一个单一的功能,并且该功能应该由这个类完全封装起来。所有它的(这个类的)服务都应该严密的和该功能平行(功能平行,意味着没有依赖)。

围观设计模式(1)--单一功能原则

 2 里氏替换原则

在面向对象的程序设计中,里氏替换原则(Liskov Substitution principle)是对子类型的特别定义。它由芭芭拉·利斯科夫(Barbara Liskov)在1987年在一次会议上名为“数据的抽象与层次”的演说中首先提出。

里氏替换原则的内容可以描述为: “派生类(子类)对象能够替换其基类(超类)对象被使用。” 以上内容并非利斯科夫的原文,而是译自罗伯特·马丁(Robert Martin)对原文的解读。其原文为:

Let q(x) be a property provable about objectsx of typeT. Thenq(y) should be true for objectsy of typeS whereS is a subtype ofT.

芭芭拉·利斯科夫与周以真(Jeannette Wing)在1994年发表论文并提出的以上的Liskov代换原则。----维基百科

里氏替换原则我个人的理解是:在继承关系中,父类的对象如果替换为子类的对象,他原来执行的行为依然保持不变,那么这样的程序才符合里氏替换原则,否则违背了里氏替换原则。

"围观"设计模式(2)--里氏替换原则(LSP,Liskov Substitution Principle)

3 依赖倒置原则

In object-oriented programming, the dependency inversion principle refers to a specific form of decoupling software modules. When following this principle, the conventional dependency relationships established from high-level,
policy-setting modules to low-level, dependency modules are reversed, thus rendering high-level modules independent of the low-level module implementation details. The principle states:

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.

B. Abstractions should not depend on details. Details should depend on abstractions.

The principle inverts the way some people may think about object-oriented design, dictating that both high- and low-level objects must depend on the same abstraction.

----WIKIPEDIA

释义(读者可以试着自己翻译下,个人感觉第二句不好翻,不过蛮有意思的):

在面向对象的程序设计中,依赖倒置原则是指解耦软件模块的特殊的形式。传统的依赖关系建立在高层次,而具体的策略设置应用在低层次上。使用依赖倒置原则,使得高层独立于底层的实现细节,依赖关系被倒置,使得低层次模块依赖于高层次模块的抽象。

原则规定:

A. 高层模块不应该依赖于低层模块,双方都要依赖于抽象类。

B. 抽象类不应该依赖于实现细节,实现细节应该依赖于抽象。

这项原则颠覆了一些人对面向对象程序设计的认识,比如:高层和低层都应该依赖于相同的抽象。

"围观"设计模式(3)--依赖倒置原则(DIP,Dependence Inversion Principle)

4  接口隔离原则

接口隔离原则(英语:interface-segregation principles, 缩写:ISP)指明没有客户(client)应该被迫依赖于它不使用方法。接口隔离原则(ISP)拆分非常庞大臃肿的接口成为更小的和更具体的接口,这样客户将会只需要知道他们感兴趣的方法。这种缩小的接口也被称为角色接口(role interfaces)。接口隔离原则(ISP)的目的是系统解开耦合,从而容易重构,更改和重新部署。----WIKIPEDIA

个人对于接口隔离原则的理解是:

设计接口的时候,尽量保证实现接口的那些类尽可能一致的包含着接口中的方法,避免过多的设计了接口中的方法,导致其实现类中需要实现多个完全没有用处的方法(会造成代码的冗余和混乱)。

"围观"设计模式(4)--接口隔离原则(ISP,Interface Segregation Principle)

5  迪米特法则(最少知道准则)

得墨忒耳(迪米特)定律(Law of Demeter,缩写LoD)亦称为“最少知识原则(Principle of Least Knowledge)”,是一种软件开发的设计指导原则,特别是面向对象的程序设计。得墨忒耳(迪米特)定律是松耦合的一种具体案例。该原则是美国东北大学在1987年末在发明的,可以简单地以下面任一种方式总结:

1. 每个单元对于其他的单元只能拥有有限的知识:只是与当前单元紧密联系的单元;

2. 每个单元只能和它的朋友交谈:不能和陌生单元交谈;

3. 只和自己直接的朋友交谈。

这个原理的名称来源于希腊神话中的农业女神,孤独的得墨忒耳。

很多面向对象程序设计语言用"."表示对象的域的解析算符,因此得墨忒耳定律可以简单地陈述为“只使用一个.算符”。因此,a.b.Method()违反了此定律,而a.Method()不违反此定律。一个简单例子是,人可以命令一条狗行走(walk),但是不应该直接指挥狗的腿行走,应该由狗去指挥控制它的腿如何行走。----WIKIPIDIA

个人的理解:

面向对象的程序设计中,对象与对象之间尽量相互独立,具体对象的行为由具体的对象去完成,而不是由某个对象去指定另一个对象去实施行为而且是具体的行为。迪米特法则,核心的思想就是,要求我们在设计的时候,尽量避免类与类之间的耦合,弱化耦合关系可以提升复用率,但是这样的话,会产生中间的跳转类等,导致系统复杂。实际使用的过程中尽量在保证可读性与复杂性较低的情况下,按照迪米特法则去弱化类与类之间的耦合关系(高内聚、低耦合)。"围观"设计模式(5)--迪米特法则(Lod,Law
of Demeter)或最少知道原则(Least Knowledge Principle)

6  开闭原则

在面向对象编程领域中,开闭原则规定“软件中的对象(类,模块,函数等等)应该对于扩展是开放的,但是对于修改是封闭的”,这意味着一个实体是允许在不改变它的源代码的前提下变更它的行为。该特性在产品化的环境中是特别有价值的,在这种环境中,改变源代码需要代码审查,单元测试以及诸如此类的用以确保产品使用质量的过程。遵循这种原则的代码在扩展时并不发生改变,因此无需上述的过程。

开闭原则的命名被应用在两种方式上。这两种方式都使用了继承来解决明显的困境,但是它们的目的,技术以及结果是不同的。----WIKIPEDIA

个人对于开闭原则的理解:

开闭原则相当于一个纲领性质的原则,提倡类等应该在设计完成后通过扩展的方式适应新的业务需求,而不是通过修改的方式去适应新的需求,这样的设计更加灵活、稳定。之前的五大原则是开闭原则思想的具体实现的情况。

"围观"设计模式(6)--开闭原则(Open/Closed Principle)

时间: 2024-10-19 18:45:46

"围观"设计模式(28)--总结之设计模式六大准则的相关文章

"围观"设计模式(30)--结构型设计模式总结(适配器、代理、装饰、外观、桥梁、组合、享元)

设计模式代码下载地址 设计模式代码下载地址 1  适配器模式 在设计模式中,适配器模式(英语:adapter pattern)有时候也称包装样式或者包装(wrapper).将一个类的接口转接成用户所期待的.一个适配使得因接口不兼容而不能在一起工作的类工作在一起,做法是将类自己的接口包裹在一个已存在的类中.----WIKIPEDIA 个人理解 适配器模式:将两个不一致或者说无法直接使用的类或者接口通过适配器模式进行兼容,使得他们可以在一块使用.适配器模式在之前的项目中我是用于处理数据的不兼容的,对

设计模式总纲——单例设计模式

前两天写了设计模式总纲,今天就来讲讲我们在工程代码中最最最常用的设计模式了——单例设计模式,这个模式在工程代码上的出现率几乎为99.99999%,但是虽然很常用,但是用的好的人却不多,今天我们就来深入的说一说单例设计模式. 在学习一项新的知识之前,我们都要向自己提出三个问题,为什么要用这个知识,这个知识用在哪里,这个知识怎么用?既 why,where,how,3W模式,我们先来谈谈为什么需要单例设计模式,先来想想,如果一个工具类,比如一个读取配置文件的工具类,这类工具只是特定的功能类,既读取指定

java设计模式之单例设计模式

设计模式:解决某一类问题最行之有效的方法. java中23种设计模式. 单例设计模式:解决一类在内存中只存在一个对象. Runtime()方法就是单例设计模式进行设计的. 解决的问题:保证一个类在内存中的对象唯一性. 比如:多程序读取一个配置文件时,建议配置文件封装成对象.会方便操作其中数据,又要保证多个程序读到的是同一个配置文件对象,就需要该配置文件对象在内存中是唯一的. 1.为了避免其他程序过多建立该类对象,先禁止其他程序建立该类对象. 2.还为了让其他程序可以访问该类对象,只好在本类中自定

[Android]GOF23种设计模式 & Android中的设计模式

GOF23种设计模式 设计原则: 1. 单一职责原则(SRP):就一个类而言,应该仅有一个引起它变化的原因 2. 开放-封闭原则(OCP):软件实体(类.模块.函数等)应该可以扩展,但是不可修改.即对于扩展是开放的, 对于修改是封闭的. 3. 依赖倒转原则: A. 高层模块不应该依赖低层模块,两个都应该依赖抽象.B.抽象不应该依赖细节,细节应该依赖抽象.说白了,就是要针对接口编程,不要对实现编程. 4. 迪米特法则(LoD):如果两个类不必彼此直接通信,那么这两个类就不应该发生直接的相互作用.如

设计模式之-----------单例设计模式

饿汉式: class Single { //   提前做好! private static final Single s = new Single(); //  私有化 构造函数  无法使用new 创建对象! private Single(){} //  对外提供接口 public static Single getInstance() { return s; } } 懒汉式: 懒汉 顾名思义  就是懒呗 什么时候用到 什么时候创建! class Single1 { private static

大话设计模式1:初识设计模式及设计模式五大基本原则

一什么是设计模式? 设计模式(Design pattern)是一套被反复使用.多数人知晓的.经过分类编目的.代码设计经验的总结.使用设计 模式是为了可重用代码.让代码更容易被他人理解.保证代码可靠性. 毫无疑问,设计模式于己于他人于系统都是多 赢的:设计模式使代码编制真正工程化:设计模式是软件工程的基石脉络,如同大厦的结构一样. 二为什么要使用设计模式? 为什么要提倡Design Pattern呢?根本原因是为了代码复用,增加可维护性.那么怎么才能实现代码复用呢?面 向对象有几个原则:单一职责原

[设计模式] .NET设计模式笔记 - 有多少种设计模式

.NET下的23中设计模式. ※创建型模式篇 ●单件模式(Single Pattern) ●抽象工厂模式(Abstract Factory) ●建造者模式(Builder Pattern) ●工厂方法(Factory Method) ●原型模式(Protype Pattern) ※结构型模式篇 ●适配器模式(Adapter Pattern) ●桥接模式(Bridge Pattern) ●装饰模式(Decorator Pattern) ●组合模式(Composite Pattern) ●外观模式(

java软件设计模式只单例设计模式

概述 设计模式(Design pattern)是一套被反复使用.多数人知晓的.经过分类编目的.代码设计经验的总结.使用设计模式是为了可重用代码.让代码更容易被他人理解.保证代码可靠性. 毫无疑问,设计模式于己于他人于系统都是多赢的:设计模式使代码编制真正工程化:设计模式是软件工程的基石脉络,如同大厦的结构一样. 设计模式分为三种类型,共23种.创建型模式:单例模式.抽象工厂模式.建造者模式.工厂模式.原型模式.结构型模式:适配器模式.桥接模式.装饰模式.组合模式.外观模式.享元模式.代理模式.

什么是设计模式?常见的设计模式有哪些?

设计模式是众多软件开发人员经过长期的软件开发过程中总结得来的.针对的一般性问题的通用解决方案,是一套被分类编目的.软件开发人员都知晓的.可被反复利用的.代码设计经验的总结. 使用设计模式可以提高代码的复用.避免程序大量修改从而保证代码的可靠性,同时使代码更容易被他人理解.显然设计模式不管是对自己.对他人还是对系统都是有益的,设计模式使得代码编制真正的工程化,是软件工程的基石. 在Gang of Four中总结了23种经典的设计模式,常用的设计模式有:单例模式.工厂模式.观察者模.适配器模式.亨元