尽管ECS模式和装饰器模式都允许动态改变对象的行为，但它们的实现方式和目标是不同的。而在装饰器模式中，对象的基本行为是由其类定义的，装饰器只是添加或修改这些行为。此外，ECS模式中的实体并不需要实现与其组件一致的接口，这是它与装饰器模式的另一个主要区别。它通过将对象封装在装饰器对象中来实现这一点，装饰器对象实现了与原对象相同的接口，并在调用原对象的方法之前或之后添加新的行为。：这是所有装饰器类的基

在全局访问点gameInstance中设置了设置了当前唯一的游戏game:DemoGame，以及系统种需用到的存储单例，时间单例，及事件单例等等。有一些类会自带单例模式，有些采用统一的单例去管理。因为我们是设计一个游戏框架所以这里采用了统一的方式。方便认识整个系统中那些系统使用了单例。模式意图：保证一个类仅有一个实例，并提供一个访问它的全局访问点。意图：保证一个全局唯一的单例，并提供一个访问它的全

前面在访问者模式中，我们简单设计了一个伤害系统，但是每次创建伤害访问者时都需要new一个，比如一次单体普通攻击：new MonomerAttackVisitor(100)，但伤害事件在游戏中是大量存在，每次都new一个肯定是不友好的。享元模式和对象池模式有点像，但是有差别，对象池模式在我们前面提到的抽象工厂中，有提到部分代码，对象池模式一般有回收这个动作，回收对象一般会通过reset方法进行重置。

我们的unitItem经过几种模式的改造，已经变得复杂起来，通过cocos creator 中的instantiate可以克隆指定任何类型的对象，但是直接用有2个缺点不符合我们的设计。4、当一个类的实例只能有几个不同状态组合中的一种时。建立相应数目的原型并克隆它们，可能比每次用合适的状态手工实例化该类更方便一些。意图：用原型实例指定创建对象的种类，并且通过复制(clone)创建新的对象。模式意图：

联机开发就不一样了，一般情况下我们的命令需要到服务器端走一下，和其他玩家的命令一起排个队再回来。联机：本地指令发送--->上报服务器--->服务指令接受--->本地指令执行。单机：本地指令发送--->中介者发送(指令来自本地)--->本地指令接受执行。1、本地指令发送--->中介者发送(指令来自本地)--->服务端指令接受执行。2、服务指令发送--->中介者发送(指令来自服务)--->本地指令接受

将一次请技能释放求通过一串责任(命令)链接起来，不同责任(命令)做出不同的技能释放命令。有小于10个大于5个敌对单位时，ai单位释放中技能，有10个以上敌对单位时，ai单位释放大技能。意图：使多个对象(命令)都有机会处理(技能释放)请求，从而避免(技能释放)请求的发送者和接收者之间的耦合关系。将这些对象(命令)连成一条链，并沿着这条链传递该(技能释放)请求，直到有一个对象(命令)处理它为止。模式意

游戏中也经常用到数据与视图的绑定，比如玩家的金币，在数据层player.money = 200时，我们希望页面上的所有显示金币数量的地方，都自动自动刷新视图显示为200，且如果数值不变时，你们你触发n多次player.money = 200，都不会触发刷新视图的事件。代理的玩法有很多，在游戏框架中我们如何使用代理模式，应该也有很多玩法，这里我只介绍其中一种。：也称为大使，这是最常见的类型，在分布式

完成一个游戏开发后，我们想稍微修改下配置，修改下ui，调整一下玩法变成一个新的游戏，结合设计模式的意图，我们修改一下我们的意图。意图：将一个复杂（游戏）对象的构建与表示(小游戏玩法)分离，使得同样的构建过程可以创建不同的表示(小游戏玩法)。模式意图：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。有了构建器，下次再分离出一个消除类玩法，只需要new 一个新的构建器就可以了

1、在线先将mgg转成ogg。2、在线将ogg转mp3。

人工智能已经推出了快2年了，各种模型和插件，有渐渐变成熟的趋势，打造一个类似 hao123网站的人工智能模型入口，也变得有需求了。用户会去比较多个ai给出的答案，作为程序员想拥有一台自己的GPU服务器来为自己服务。但是，通过 curlhttp://127.0.0.1:11434可以得到Ollama is running 的反馈。如果像我一样 ollama是安装在本机的，而lobe-chat是doc