关系型模式
父类和子类之间
策略模式
模版模式
两个类之间
观察者模式
迭代模式
责任链模式
命令模式
类的状态
备忘录模式
状态模式
通过中间类
访问者模式
中介者模式
解释器模式
状态模式
状态模式是一种行为型设计模式。
它允许对象在其内部状态发生变化时改变其行为。通常,这种模式用于解决一个对象具有多个状态,且在不同状态下可以采取不同的行动方案的问题。状态模式的主要目标是将复杂的状态逻辑分解成简单的组件,并为我们提供了一种灵活、可扩展的方式来处理对象的状态。
优点:
使代码更加清晰、易于维护:将复杂的状态逻辑封装到单独的状态类中,使得各个状态之间相互独立,减少了代码的耦合度;
增加系统的扩展性:由于状态之间相互独立,因此可以很容易地添加新的状态,而无需修改已有代码;
使代码符合开闭原则:通过将状态相关的代码封装到单独的状态类中,可以在不修改原有代码的情况下增加新的状态。
缺点:
可能会引入大量的类:每个状态都需要对应一个状态类,如果状态比较多,则会导致类的数量剧增,降低代码的可读性和可维护性;
可能会增加系统的复杂度:状态模式需要引入多个类之间的交互,可能会增加系统的复杂度。
适用场景:
对象具有多个状态,且在不同状态下可以采取不同的行动方案;
对象的状态转换比较复杂,或者存在大量的条件语句;
需要在运行时根据对象的状态来改变其行为;
需要将状态相关的代码封装到单独的 ...
结构型模式
定义:
结构模式(Structural Pattern)是设计模式的一种,它主要关注如何将对象和类组合成更大的结构,并通过简化对象间的通信来实现更高级别的功能。
类结构模式
适配器模式
桥接模式
装饰模式
对象结构模式
组合模式
享元模式
代理模式
EDA事件驱动架构
定义事件驱动架构 EDA (Event-Driven Architecture) 是一种基于事件的设计模式,它通过事件的方式来实现系统中各个组件之间的解耦合。在这种架构模式下,每个组件都可以被看做是一个事件源,当某个组件触发了事件后,其他组件可以接收到这个事件并作出相应的处理。
核心思想事件驱动架构的核心思想是将业务逻辑和底层实现分离开来,从而提高代码的可维护性、扩展性和灵活性。通过使用事件机制,可以将系统的各个模块解耦合,避免了紧密的依赖关系,使得系统更加容易扩展和修改。
内容事件驱动架构中通常包括以下几个组件:
事件源(Event Source):产生事件的对象,比如按钮点击、鼠标移动等。
事件(Event):描述事件源状态变化的数据结构,包含事件源的信息及其状态。
事件处理器(Event Handler):负责处理特定类型的事件,每个事件处理器通常只处理一种类型的事件。
事件总线(Event Bus):用于传递事件的管道,事件总线负责将事件源和事件处理器连接起来,将事件源产生的事件传递给对应的事件处理器进行处理。
优点
解耦合:通过事件机制,各个组件之间可以松散地耦合在一起 ...
MVC架构
模型-视图-控制器 MVC组成
模型(Model):模型代表应用程序中的数据和业务逻辑。在MVC中,模型通常是一个类或一组类,用于存储应用程序数据和提供执行业务逻辑所需的方法。
视图(View):视图就是用户界面,它负责显示模型数据,并向用户展示数据。在MVC中,视图通常是一组类,用于渲染HTML页面、WinForm或WPF窗体等用户界面。
控制器(Controller):控制器响应用户事件(如用户点击按钮或提交表单),并根据需要更新模型或视图。在MVC中,控制器通常是一组类,用于处理用户请求、调用模型方法以获取数据和更新视图。
使用场景MVC适用于大多数Web应用程序和桌面应用程序,尤其是那些需要长期维护的应用程序。以下是一些使用MVC的最佳实践:
处理复杂的业务逻辑:如果您的应用程序需要大量的业务逻辑或数据处理,那么MVC可以帮助您更好地组织代码,使其更易于维护。
长期维护:如果您的应用程序需要长期维护,那么MVC可以帮助您更好地组织代码,并使其更易于扩展和修改。
团队开发:如果多个开发人员同时开发同一应用程序,MVC可以帮助您更好地分配任务并管理代码。每个开发人员可以负责不同 ...
设计模式-六大原则
单一职责原则定义: 对一个类而言,应该仅有一个引起它变化的原因。 如果存在多于一个动机去改变一个类,那么这个类就具有多于一个的职责,就应该把多余的职责分离出去,再去创建一些类来完成每一个职责。
理解:
一个人身兼数职,而这些事情相关性不大,甚至有冲突,那他就无法很好的解决这些问题职责,应该分到不同的人身上去做。
开闭原则定义: 一个软件实体如类、模块和函数应该对扩展开放,对修改关闭。目的就是保证程序的扩展性好,易于维护和升级。
理解:
软件对扩展应该是开放的,对修改是封闭的,通俗来说就是,开发一个软件时,应该对其进行功能扩展,而在进行这些扩展时,不需要对原来的程序进行修改。
里氏替换原则定义:如果将一个父类对象替换成它的子类对象后,该程序不会发生异常。
理解:
子类可以扩展父类的功能,但是不能改变父类原有的功能。
子类可以实现父类的抽象方法,但不能覆盖父类的非抽象方法,父类中凡是已经实现好的方法(相对于抽象方法而言),实际上是在设定一系列的规范和契约,虽然它不强制要求所有的子类必须遵从这些契约,但是如果子类对这些非抽象方法任意修改,就会对整个继承体系造成破坏。
保证了父类的复 ...
游戏开发常用架构模式
EDA (Event-Driven Architecture) 模式事件驱动架构是一种基于事件的设计模式,它通过事件的方式来实现系统中各个组件之间的解耦合。在这种架构模式下,每个组件都可以被看做是一个事件源,当某个组件触发了事件后,其他组件可以接收到这个事件并作出相应的处理。
ECS(Entity-Component-System)模式实体组件系统架构模式是一种基于数据驱动的架构模式,将游戏中的实体(Entity)看做是所有组件(Component)的容器,通过不断添加或删除组件来改变实体的行为。这种架构方式可以有效地解决游戏对象的复杂关系和频繁变化的问题。
MVC(Model-View-Controller)模式模型视图控制器模式,这种模式可以帮助游戏开发人员将游戏逻辑和界面展示进行分离,使代码更加清晰和易于维护。在游戏中,视图层主要负责渲染游戏画面,控制器层负责响应用户输入和处理游戏逻辑,模型层则负责存储游戏数据。
SM(State Machine)模式状态机是一种经典的设计模式,它可以帮助游戏开发人员管理游戏对象的各种状态和转换。通过使用状态机模式,游戏开发人员可以更好地组织代码 ...
Lua细节
Lua中 .和:的区别
使用:定义的函数只能用:调用,会隐含的将调用者引用传过来,也就是self
使用 .定义的函数
如果使用.调用那么第一个参数为正常参数
如果使用 : 调用,那么第一个参数即为调用者的引用,第二个才是正常参数
_G表存储所有lua脚本的全局变量,即没有使用 local 的
Lua迭代器
pairs原理:无序输出 字母类型key 或者 数字类型key 的键值,遇到nil不输出,但不会停止遍历;
特点:
pairs会输出所有的数据,不带key 的值按顺序输出,带key 的值无序输出;
pairs遇到nil不会停止输出;
适用于:表
ipairs原理:从第一个数字key开始,依次输出所有的 key+1 的键值,遇到 字母下标 并不会结束遍历,只是不输出而已,如果遇到nil则退出;
特点:
ipairs会跳过 字符串的key,按 顺序输出 数字型key的值;
ipairs遇到nil会停止输出;
适用于:数组
总结:会略过 数组非正数索引,以及其他字典索引,从数组的[1]索引开始迭代(对应index=0),顺序迭代直到 某个索引不存在 或 **其对应的值为空 **时结束
总pairs 和 ipairs均优先输出没有key的value;
Lua模块
定义:Lua 的模块是由变量、函数等已知元素组成的 table。可以把一些公用的代码放在一个文件里,以 API 接口的形式在其他地方调用,有利于代码的重用和降低代码耦合度。
模块使用示例:
123456789101112131415161718192021-- 文件名为 module.lua-- 定义一个名为 module 的模块module = {} -- 定义一个常量module.constant = "这是一个常量" -- 定义一个函数function module.func1() io.write("这是一个公有函数!\n")end local function func2() print("这是一个私有函数!")end function module.func3() func2()end return module
require 函数Lua提供了一个名为require的函数用来加载模块。要加载一个模块,只需要简单地调用就可以了。
1require("<模块名& ...