学习日记之抽象工厂模式和Effective C++

抽象工厂模式(Abstract Factory):提供一个创建一系列相关或者相互依赖对象的接口。而无需制定他们详细的类。

(1),工厂方法模式是定义一个用于创建对象的接口。让子类决定实例化哪一个类。

(2),为创建不同的产品对象,client应使用不同的详细工厂。

抽象工厂模式的长处和缺点:

(1)。优点是便于交换产品系列,因为详细工厂类在一个应用中仅仅须要在初始化的时候出现一次,这就使得改变一个应用的详细工厂变得很easy。它仅仅须要改变详细工厂就可以使用不同的产品配置。

(2),它让详细的创建实例过程和client分离。client是通过他们的抽象接口操纵实例。产品的详细类名也被详细工厂的实现分离。不会出如今client代码中。

(3),用简单工厂能够改进抽象工厂。

(4)。用反射+抽象工厂的数据訪问程序。

(5)。用反射+配置文件实现数据訪问程序。

(6)。全部在用简单工厂的地方,都能够考虑用反射技术来去除 switch 或 if。解除分支推断带来的耦合。

Effective C++:

1:转型操作符。

(1)。const_cast 通经常使用来将对象的常量性去掉(cast away the constness )。

它也是唯一有此能力的 C++-style 转型操作符。

(2)。dynamic_cast 主要用来转型“安全向下转型” (safe downcasting),也就是用来决定某对象是否归属继承体系的某个类型。它是唯一无法用旧式语法执行的动作,也是唯一肯呢过耗费重大执行成本的转型动作。

(3)。reinterpret_cast 意图运行低级转型,实际动作以及结果可能取决于编译器,这也就表示它不可移植。比如讲一个 pointer to int 转型为 一个 int。

这一类转型在第几代码以外非常少见。

(4)。static_cast 用来强迫隐式转换(implicit conversions)。比如将 non-const 对象转为 const 对象,或将 int 转为 double 等等。

它也能够用来运行上述多种转换的反向转换,比如将 void* 指针转为 typed 指针。将 pointer-to-base 转为 pointer-to-derived。

但它违法将 const 转为 non-const。

2:尽量少做转型动作

(1),假设能够,尽量避免转型,特别是在注重效率的代码中避免dynamic_casts。假设这个设计须要转型动作,试着发展无需转型的替代设计。

(2),假设转型是必要的。试着将它隐藏于某个函数背后。客户随后能够调用该函数,而不需将转型放进他们自己的代码内。

(3),宁可使用 C++-style 转型。不要使用旧式转型。前者非常easy辨识出来,并且有着比較愤懑别类的执掌。

3:避免返回 handles 指向对象内部成分

(1)。避免返回 handles (包含 references、指针、迭代器)指向对象内部。遵守这个条款可添加封装性,帮助 const 成员函数的行为像个 const。并将发生“虚吊号码牌”(dangling handles)的可能性降到最低。

时间: 2024-10-29 19:10:38

学习日记之抽象工厂模式和Effective C++的相关文章

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

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

学习日记之职责链模式和Effective C++

职责链模式(Chain of Responsibility):使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系.将这个对象连成一条链,并沿着该条链传递该请求,直到有一个对象处理它为止. (1),当客户提交一个请求时,请求时沿着链传递直到有一个 ConcreteHandler 对象负责处理它. (2),接收者和发送者都没有对方的明确信息,切链中的对象自己也不知道链的结构.结果是职责链可简化为对象之间的连接,它们仅需保留一个指向其后继者的引用.而不惜保留它所有的候选接收者的引用

学习日记之享元模式和Effective C++

享元模式(Flyweight):运用共享技术有效地支持大量细粒度的对象. (1),享元模式可以避免大量非常相似的开销.在程序设计中,有时需要生成大量细粒度的类实例来表示数据.如果能发现这些实例除了几个参数外基本上都是相同的,有时就能大幅度地减少需要实例化的类的数量.如果能把这些参数移到类的外面,在方法调用时将他们传递进来,就可以通过共享大幅度减少实例的数目. (2),如果一个应用使用了大量的对象,而这些对象造成很大的存储开销的时候就考虑使用:还有就是对象的大多数状态可以外部状态,如果删除对象的外

设计模式学习03—抽象工厂模式

1.动机与定义 工厂模式中,一个工厂仅仅能提供一个或一类产品,当产品种类较多,形成产品系列(比方我们要创建跨平台的button,菜单,文本框等等一系列GUI控件: 单纯使用工厂模式会产生大量工厂,并且后期维护也不方便,我们能够从产品中找到规律,假设产品等级相对固定,以后仅仅会新增产品族,那么我们就能够把整个产品族放到一个工厂创建,以后新增其它系统产品族也很方便,例如以下图: 这样的模式就是抽象工厂,工厂方法模式针对的是一个产品等级结构,而抽象工厂模式则须要面对多个产品等级结构,一个工厂等级结构能

创建型-抽象工厂模式学习

1.抽象工厂模式的意图: 提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类. 2.抽象工厂模式的适用性: 一个系统要独立于它的产品的创建.组合和表示时. 一个系统要由多个产品系列中的一个来配置时. 当你要强调一系列相关的产品对象的设计以便进行联合使用时. 当你提供一个产品类库,而只想显示它们的接口而不是实现时. 3.场景描述: 考虑一个生产多种不同风格的家具的工厂(FurnitureFactory),不同风格的家具系列可以提供不同的门.窗.地板等的组合,为同一所住房可以提供不同

设计模式——抽象工厂模式学习

要想正确的理解设计模式,首先必须明确它是为了解决什么问题而提出来的. 抽象工厂设计模式概念: 针对抽象工厂这个设计模式,我查找了不少资料,感觉只有涉及产品级别和产品族的才是理解了抽象工厂设计模式的精髓,工厂方法模式针对的是一个产品等级结构:而抽象工厂模式针对的是多个产品等级结构.有些观点认为抽象工厂模式是为了解决客户端代码与工厂类的耦合问题,我认为这种观点的解决方案只是简单工厂模式的一个应用,而这种观点认为的抽象工厂模式是: 工厂模式+简单工厂模式=抽象工厂模式,这是不正确. 针对的问题: 针对

设计模式学习(二)——简单工厂模式、工厂模式、抽象工厂模式

最近抽时间将之前看过的"程序人生"公众号推送的一篇工厂模式的介绍进行了实践,为了加深自己理解,特将自己的学习理解记录于此.初识设计模式,就被设计模式的精妙深深吸引,感觉脱离设计模式的代码就失去了美丽.作为一个测试,平日写代码的机会肯定不如开发多,但是希望自己能通过努力逐步提升代码水平,有一天也能写出优美的代码.如果有对于工厂模式或其他设计模式感兴趣的朋友欢迎一起探讨. 一.简单工厂模式 定义:专门定义一个类用来创建其他类的实例,被创建的实例通常具有共同的父类. 场景一:恰巧今天,老大兴

Java研究之学习设计模式-抽象工厂模式详解

 简介:          当每个抽象产品都有多于一个的具体子类的时候,工厂角色怎么知道实例化哪一个子类呢?比如每个抽象产[1] 品角色都有两个具体产品.抽象工厂模式提供两个具体工厂角色,分别对应于这两个具体产品角色,每一个具体工厂角色只负责某一个产品角色的实例化.每一个具体工厂类只负责创建抽象产品的某一个具体子类的实例. 每一个模式都是针对一定问题的解决方案,工厂方法模式针对的是一个产品等级结构:而抽象工厂模式针对的是多个产品等级结构.(摘自百度百科) 话语说得太抽象,程序员最好的表示方式

java/android 设计模式学习笔记(4)---抽象工厂模式

再来介绍一下抽象工厂模式(Abstact Factory Pattern),也是创建型模式之一,上篇博客主要介绍了工厂方法模式.抽象工厂模式和工厂方法模式稍有区别.工厂方法模式中工厂类生产出来的产品都是具体的,也就是说每个工厂都会生产某一种具体的产品,但是如果工厂类中所生产出来的产品是多种多样的,工厂方法模式也就不再适用了,就要使用抽象工厂模式了. 抽象工厂模式的起源或者最早的应用,是对不同操作系统的图形化解决方案,比如在不同操作系统中的按钮和文字框的不同处理,展示效果也不一样,对于每一个操作系