设计模式
Tevior
向无上荣耀的王冠举起锋利至极之剑
展开
-
设计模式:visitor访问者模式
在软件构建的过程中,由于需求的改变,常常需要在某类层次结构中增加新的方法(从基类到派生类都要),如果直接在基类中更改,就会破坏原有设计。visitor模式可以在不改变各元素类的前提下“拓展”作用于这些元素的新变化。本设计模式的主要点是double dispatch二次多态辨析每个visitor派生类都可以定义新的element方法,这样就达到了不该变element结构设计而拓展功能的效果,当然这么做的设计前提是element在结构设计上已经稳定,及不会有新的派生类,要变化的只有增加操作方法。(这个前原创 2022-02-05 23:53:26 · 388 阅读 · 0 评论 -
设计模式:命令模式
将请求(行为)封装成对象,从而更加灵活的使用,比如对行为的记录、撤销、重做等,命令模式将组件的行为和组件本身解耦了。command的模式和c++的仿函数很像,command模式以“接口-实现”来定义接口规范,更加严格,但是虚函数会有性能损失,是运行时绑定。C++的仿函数是以函数签名来定义行为规范,更加灵活,性能也更高,运用了模板(自动推导类型),是编译时绑定。本质都是将行为对象化。#pragma once#include <iostream>#include <vector&原创 2022-02-05 21:27:28 · 190 阅读 · 0 评论 -
设计模式:composite组合模式
属于数据结构模式的一种,常常有一些组件再内部具有特定的数据结构,如果客户程序依赖这些数据结构,那么将极大的破坏组件的服用。我们需要将这些特定的数据结构封装在内部,再外部提供统一的接口,来实现与特定数据结构无关的访问。就是将客户代码与复杂的对象容器结构解耦合。composite模式将对象组合成部分-总体的层次结构,对一对一,一对多统一视为一对一,使得用户对单个对象和组合对象的使用具有一致性。用户无需关心处理的是单个的对象,还是组合的对象容器。使用了composite后,用户将与抽象接口发生依赖,而不是与具原创 2022-02-05 10:45:41 · 2527 阅读 · 0 评论 -
设计模式:memento备忘录模式
就跟游戏的存档的概念一样,在软件构建的过程中,转换某种状态后,出于某种需要,我们需要程序能够回溯到处于某个时间节点之前的状态。但是我们又不能把对象的状态公开(会暴露对象的细节实现)。如何在保持封装性的同时又能有这种类似存档的功能。答案就是备忘录模式(一种思想,而非实现)在不破坏封装性的前提下,捕获一个对象的内部状态,并在对象之外保存这个状态。之后就可以利用这个备份回溯到以前的状态。被保存的状态可能跟实际的结构是一样的,也可能有所差异,比如经过了某些编码或是转换成其他格式,但是只要能“代表”之前的状态,原创 2022-02-04 23:06:43 · 287 阅读 · 0 评论 -
设计模式:享元模式
回答了对纯粹对象方案(就是万物皆对象)在设计大量细粒度对象时候的性能问题,比如字符的字体属性,按说每个字符都需要有字体属性,但是一篇文章一共就几种字体,如果对每个字符都单独设置一个font属性,开销就会很大。享元模式(flyweight)采用对象共享的方法来降低系统中对象的个数,从而降低内存压力。(在实际使用中,享元一般设置为只读的)。我们维护一个享元池,每次需要享元时,我们就尝试根据一个value(所以在代码中pool设计成了map)从中拿共享对象,存在的话就返回,不存在就先创建一个在返回。这样就提高原创 2022-02-04 16:57:13 · 196 阅读 · 0 评论 -
设计模式:状态模式及有限状态机
有时候在组件构建的过程中,某些对象的状态经常面临变化,如何对变化进行有效管理的同时又能保证高层模块的稳定。(状态模式解决的问题)即是根据运行时的条件转换状态。如果不用状态模式,普通开发可能会导致if-else增值过多以及破坏oop原则。状态模式允许一个对象在内部状态改变它的行为,从而是对象看起来似乎修改了其行为。~GOF设计模式state模式将所有的行为都放在state的子类对象中,在对象状态切换时,切换相应的对象。而且这样写可以使状态之间的转换更加明确,可以保证不出现状态不一致的情况,即有限状态机值原创 2022-02-04 10:32:11 · 775 阅读 · 0 评论 -
设计模式 builder模式
也是属于对象创建类模式。使用的一般情况是,需要完成一个复杂的对象创建工作,工作通常由各个部分的子对象用一定的算法构成,比如step1,step2,step3,步骤内部常常发生剧烈的变化,但是组合在一起的算法却相对的稳定。(就是构建一个东西需要好多步骤去组合才能完成)我们的做法是,将复杂对象的构建和表示相分离,使得同样的构建过程(step1,step2,step3)可以创建不同的变化。这里以造房子举例,假设造房子都有3步,floor,upstairs和elec,我们把他们定义为step1,2,3,在派生类原创 2022-02-03 16:13:30 · 314 阅读 · 0 评论 -
游戏开发原型模式
使用原型实例指定创建对象的种类,通过拷贝这些原型来创建新的对象。原型模式也是一种特殊的abstract factory,他的使用情况是,对象比较复杂(难以用工厂模式实现,或者希望保留开发的中间状态),如果初始的状态不太让人满意,那么等到已经开发出一个比较好的状态时,去clone()一个比较满意对象的状态。要求跟之前的工厂模式一样又比较稳定的接口(泛用参数来创建对象),还是不用new,而是去使用clone()的方法去创建新的对象。ps:c++的序列化太难了.jpg,但是有拷贝构造函数所以很niceps原创 2022-02-02 22:33:44 · 1439 阅读 · 0 评论 -
游戏开发设计模式 抽象工厂模式
上次用了factory_method模式,这实际上是抽象工厂模式的一种特例化(指只有一组变化)使用的场合是:需要创建一组产品,产品之间存在互相依赖的关系,类比到游戏开发中,就是在难度1的游戏中,只有难度1的敌人和难度1的地图,不能是难度1的敌人搭配难度2的地图。方法是:提供一个接口,让该接口负责创建一系列”相关或者相互依赖的对象“,无需指定他们具体的类(和工厂方法的概念差不多,就是多了依赖的关系)#pragma once#include <iostream>using namesp原创 2022-02-02 17:29:49 · 1415 阅读 · 0 评论 -
游戏开发设计模式 factory_method模式
属于是对象创建模式的一种,这类模式的特点是:用虚函数运行时依赖的特点创建对象,绕开new,避免对象创建(new)过程的紧耦合。通常是接口抽象后的第一步工作。定义一个用于创建对象的接口(侯捷课上说的,就是相当于重写一个支持多态的new方法)让子类决定实例化哪一个类。Factory_method就启到了一个让类的实例化延迟的作用。就是有个虚函数 (参数就肯定相同了),用的时候根据传来的工厂判断要生产的是什么东西。工厂模式有效的解决了添加新产品必须要修改工厂类代码的问题,新增一种武器只需要新增一个武器类原创 2022-02-02 11:02:05 · 1541 阅读 · 0 评论 -
游戏开发设计模式 桥模式
跟装饰器模式一样,设计上属于职责划分,要划清责任,分清主体和拓展,解决的是(随着需求变化,子类数目极具膨胀的问题)头文件#pragma once#include <iostream>using namespace std;template<typename T>//这里用了下类的前向声明,不然编译过不去class My_character;template<typename T>class My_weapons {public: virtual..原创 2022-02-01 18:00:12 · 389 阅读 · 0 评论 -
C++设计模式 装饰器模式
提出的动机来源于对继承的乱用导致的派生类急速增加的问题。主要是要分清楚积累的派生分别是往“主体”走的or往“拓展”走的装饰器模式特征一般比较明显,父类在被派生类继承的同时也被包含了(用侯捷老师的话是委托delegation,因为这里用的是指针)。//头文件#pragma once#include <iostream>using namespace std;//基类template<typename T>class component {public: vir原创 2022-01-31 23:08:40 · 686 阅读 · 0 评论