学习日记之迪米特法则、外观模式和 Effective C++

迪米特法则(最少知识原则):如果两个类不必彼此直接通信,那么两个类就不应该发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话,可以通过第三者转发这个调用。

(1),在类的结构设计上,每一个类都应当尽量降低成员的访问权限。

(2),迪米特法则的根本思想是强调了类的松耦合。

(3),类之间的耦合越弱,越有利于复用,一个处于弱耦合的类被修改,不会对有关系的类造成影响。

外观模式(Facade):为了系统中的一组接口提供一个一致的界面,此模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。

(1),在设计初期阶段,应该要有意思的将两个不同的层分离,层与层之间建立外观 Facade。

(2),在开发阶段,子系统往往因为不断地重构演化而变得越来越复杂,增加外观 Facade 可以提供一个简单的接口,减少他们之间的依赖。

(3),在维护一个遗留的大型系统时,可能这个系统已经非常难以维持或扩展了,为新系统添加一个 Facede 类,来提供设计粗糙或高度复杂的遗留代码的比较清晰简单的接口,让新系统与 Facade 对象交互, Facade 与遗留代码交互所以复杂的工作。

Effective C++ :

1:将成员变量声明为 private。

(1),切记将成员变量声明为 private。这可赋予客户访问数据的一致性、可细微划分访问控制、允诺约束条件获得保证,并提供 class 作者以充分的实现弹性。

(2),protected 并不比 public 更具有封装性

2:宁以 non-member、non-friend 替换 member 函数

(1),宁可拿 non-member non-friend 函数替换 member 函数。这样做可以增加封装性、包裹弹性(packaging flexibility) 和机能扩充性。

学习日记之迪米特法则、外观模式和 Effective C++

时间: 2024-08-06 13:18:18

学习日记之迪米特法则、外观模式和 Effective C++的相关文章

headFirst学习笔记之七:适配器模式与外观模式(4.30)

1.什么是适配器: 现实生活:如果要在欧洲使用美国制造的笔记本,可能需要一个交流电的适配器.有些交流电适配器只是改变插座的形状,有些会改变电流符合装置的需求. OO适配器:将一个接口转换成另一个接口,以符合客户的期望. 例子:如果它走起来像鸭子,叫起来像鸭子,那么它必定可能是一只鸭子包装了鸭子适配器的火鸡. 1 public interface Duck{ 2 public void fly(); 3 public void quack(); 4 } 5 6 public class Malla

设计模式——11.外观模式

1. 模式动机 2. 模式定义 外观模式(Facade Pattern):外部与一个子系统的通信必须通过一个统一的外观对象进行,为子系统中的一组接口提供一个一致的界面,外观模式定义了一个高层接口,这个接口使得这一子系统更加容易使用.外观模式又称为门面模式,它是一种对象结构型模式. 3. 模式结构 外观模式包含如下角色: Facade: 外观角色 SubSystem:子系统角色 4. 时序图 5. 代码分析 #include <iostream> #include "Facade.h&

java/android 设计模式学习笔记(14)---外观模式

这篇博客来介绍外观模式(Facade Pattern),外观模式也称为门面模式,它在开发过程中运用频率非常高,尤其是第三方 SDK 基本很大概率都会使用外观模式.通过一个外观类使得整个子系统只有一个统一的高层的接口,这样能够降低用户的使用成本,也对用户屏蔽了很多实现细节.当然,在我们的开发过程中,外观模式也是我们封装 API 的常用手段,例如网络模块.ImageLoader 模块等.其实我们在开发过程中可能已经使用过很多次外观模式,只是没有从理论层面去了解它. 转载请注明出处:http://bl

面向对象五大原则-----迪米特法则

什么是迪米特法则 迪米特法则(Law of Demeter )又叫做最少知识原则,也就是说,一个对象应当对其他对象尽可能少的了解.不和陌生人说话.英文简写为: LoD. 迪米特法则最初是用来作为面向对象的系统设计风格的一种法则,于1987年秋天由lan holland在美国东北大学为一个叫做迪米特的项目设计提出的. 迪米特法则的模式与意义 迪米特法则可以简单说成:talk only to your immediate friends. 对于OOD来说,又被解释为下面几种方式:一个软件实体应当尽可

设计模式学习(十) 外观模式

迪米特法则(最少知识原则): 一个软件实体应当尽可能少的与其他实体发生相互作用. 外观模式核心: -- 为子系统提供统一的入口,封装子系统的复杂性,便于客户端调用. 以办理公司为例: package com.lp.facade; public interface 工商局 { void checkName(); } class 海淀区工商局 implements 工商局{ @Override public void checkName() { System.out.println("检查名字是否有

2015-03-10--模板方法模式,迪米特法则

今天上午有事,下午回来先休息了一下,后来开始学习.今天先看的其实是STL的vector,不是简单的看啊,用谁不会,要自己亲自动手实践一个,不过到现在了还没有实现,明天自己再做一个vector吧,今天主要是看了别人的代码了,并且分析了一下,其实有时候分析和设计的环节要是比真正编写代码还重要啊. 后来晚上继续我们的设计模式,今天仍然是看的比较少,看了模板方法模式和迪米特法则.我们一个一个的收,先说模板方法模式. 上图: 模板方法模式是通过把不变行为搬移到超类,去除子类中的重复代码来体现它的优势. 其

学习日记之状态模式和Effective C++

状态模式(State):当一个对象内在状态改变时,允许改变其行为,这个对象看起来像是改变了其类. (1),状态模式主要负责解决的是当控制一个对象转换的条件表达式过于复杂时的情况.把状态的判断逻辑转移到表示不同状态的一系列类中,可以把复杂的判断逻辑简化. (2),状态模式的好处是将与特定状态相关的行为局部化,并且将不同状态的行为分割开来. (3),将特定的状态相关的行为都放入一个对象中,由于所有与状态相关的代码都存在于某个ConcreteState中,所以通过定义新的子类可以很容易地增加新的状态和

学习日记之解释器模式和Effective C++

解释器模式(interpreter):给定一个语言,定义它的文法的一种表示,并定义一个解释器,这个解释器使用该表示来解释语言中的句子. (1),如果一种特定类型的问题发生的频率足够高,那么可能就值得将该问题的各个实例表述为一个简单语言的句子.这样可以构建一个解释器,该解释器通过解释这些句子来解决该问题. (2),当一个语言需要解释执行,并且你可将该语言中的句子表示为一个抽象的语法树时,可使用解释器模式. (3),容易改变和扩展文法,因为该模式使用类来表示文法规则,你可以使用继承来改变和扩展该文法

学习日记之中介者模式和Effective C++

中介者模式(Mediator):用一个中介对象来封装一系列的对象交互.中介者使各对象不需要显示地相互引用,从而使其耦合松散,而且可以独立地改变他们之间的交互. (1),中介者模式很容易在系统中应用,也很容易在系统中误用.当系统出现多对多交互复杂的对象群时,不要急于使用中介者模式,而要反思你在系统的设计上是不是合理. (2),中介者的出现减少了各个对象的耦合,使得可以独立地改变和复用各个对象和中介者. (3),由于把对象如何协作进行了抽象,将中介者作为一个独立的概念并将其封装在一个对象中,这样关注