自由学习记录（20）

PureMVC

把 LoginView 视图组件赋给 viewComponent，然后用它来监听用户事件，更新显示状态。

command

将请求（例如方法调用）封装成一个对象，从而使得用户可以通过该对象来调用相应的操作。

Command（命令）：封装一个请求的对象，包含执行的操作和调用的具体方法。

Invoker（调用者）：负责调用命令对象，实际上并不知道命令的具体实现。

命令队列：可以将命令存储在队列中，按顺序执行。

Character player = new Character();

ICommand move = new MoveCommand(player);

ICommand attack = new AttackCommand(player);

GameController controller = new GameController(move, attack);

controller.OnMovePressed(); // 执行移动

controller.OnAttackPressed(); // 执行攻击

MoveCommand 和 AttackCommand 是具体的命令对象，封装了角色的移动和攻击操作。

GameController 是调用者，它只知道如何调用命令，而不需要关心命令的具体实现。

Character 是接收者，实际执行操作。

Button moveButton = new Button();

moveButton.SetCommand(new MoveCommand(player));

Button attackButton = new Button();

attackButton.SetCommand(new AttackCommand(player));

Facade 是一个英语单词，原意是指建筑物的“外立面”或“正面”，通常用于描述建筑的外观或外部装饰部分。然而，在计算机科学和软件工程中，Facade 被用作一个设计模式的术语，表示 外观模式。

作为设计模式的 Facade 意义：

在软件设计中，Facade 模式是一种结构性设计模式，它通过提供一个简化的接口来隐藏系统复杂的子系统或多个接口。Facade 模式的目的是让客户程序能够更容易地与复杂的系统交互，通过封装复杂的子系统，客户只需要调用一个简单的接口来完成复杂操作，而无需直接处理系统的各个部分。

举个例子：

假设你有一个非常复杂的图形编辑应用程序，里面有多个模块来处理图形、颜色、渲染等。如果没有 Facade 模式，使用者需要直接与每个模块交互，这会非常繁琐。而使用 Facade 模式后，提供一个简化的接口，用户只需要通过这个接口就能完成操作，不用关心内部复杂的实现细节。

public class HomeTheaterFacade {private Amplifier amplifier;private Tuner tuner;private StreamingPlayer player;public HomeTheaterFacade(Amplifier amp, Tuner tun, StreamingPlayer play) {this.amplifier = amp;this.tuner = tun;this.player = play;}public void watchMovie(String movie) {System.out.println("Get ready to watch a movie...");amplifier.turnOn();tuner.setInputChannel();player.play(movie);}public void endMovie() {System.out.println("Shutting down...");amplifier.turnOff();player.stop();}
}

在这个例子中，HomeTheaterFacade 提供了一个简化的接口，用户只需要通过 watchMovie 或 endMovie 方法来控制整个家庭影院系统，而不必分别控制每个子系统（如音响、播放器等）。

需要高度模块化和解耦的项目

那确实挺可以的，mediator和proxy用notification来连接关系，的确专业

hello算法学习

不得不说，算法这东西是重要，但是，，总是到要用的时候才觉得重要，平时麻感觉就是瞎几把学，刷题，感觉提炼的问题都好没有用，

这种情况真的是逃不掉，我都不清楚我在干什么，就一个劲的刷，我的心理感受不舒服也是要成本的啊，何况刷算法题真的让我觉得有点“做题家”的感觉，很别扭

真正忙起来的话，不写算法真的是第一选择，算法更重要的是说明一种对世界规律的规划能力，结果到这成了写不出题就坐牢的感觉，

我是不否认前者对世界规律状态数据化的能力，甚至我觉得这样的能力确实是很强，但算法题真的是不给活路，你想到总结方法的时候，会报错，让自己自我怀疑

这种成本真的值得吗

我直到现在还是不认同，大厂什么的算法题考核，要求真的有那么极端吗，那我是不是应该点到为止放弃一些想法呢，个人的分析能力的确是可以锻炼，，，，

真的又说不出刷算法题有什么不好的，在冷静分析之后，真的是爱恨纠缠

/* 双向链表节点结构体 */
struct ListNode {int val;         // 节点值ListNode *next;  // 指向后继节点的指针ListNode *prev;  // 指向前驱节点的指针ListNode(int x) : val(x), next(nullptr), prev(nullptr) {}  // 构造函数
};

节点，与其他节点建立联系

/* 拼接两个列表 */
vector<int> nums1 = { 6, 8, 7, 10, 9 };
// 将列表 nums1 拼接到 nums 之后
nums.insert(nums.end(), nums1.begin(), nums1.end());

列表的拼接，不管是节点的存还是数组的存都可以拼接，这两个都归类到列表

/* 列表类 */
class MyList {private:int *arr;             // 数组（存储列表元素）int arrCapacity = 10; // 列表容量int arrSize = 0;      // 列表长度（当前元素数量）int extendRatio = 2;   // 每次列表扩容的倍数public:/* 构造方法 */MyList() {arr = new int[arrCapacity];}/* 析构方法 */~MyList() {delete[] arr;}/* 获取列表长度（当前元素数量）*/int size() {return arrSize;}/* 获取列表容量 */int capacity() {return arrCapacity;}/* 访问元素 */int get(int index) {// 索引如果越界，则抛出异常，下同if (index < 0 || index >= size())throw out_of_range("索引越界");return arr[index];}/* 更新元素 */void set(int index, int num) {if (index < 0 || index >= size())throw out_of_range("索引越界");arr[index] = num;}/* 在尾部添加元素 */void add(int num) {// 元素数量超出容量时，触发扩容机制if (size() == capacity())extendCapacity();arr[size()] = num;// 更新元素数量arrSize++;}/* 在中间插入元素 */void insert(int index, int num) {if (index < 0 || index >= size())throw out_of_range("索引越界");// 元素数量超出容量时，触发扩容机制if (size() == capacity())extendCapacity();// 将索引 index 以及之后的元素都向后移动一位for (int j = size() - 1; j >= index; j--) {arr[j + 1] = arr[j];}arr[index] = num;// 更新元素数量arrSize++;}/* 删除元素 */int remove(int index) {if (index < 0 || index >= size())throw out_of_range("索引越界");int num = arr[index];// 将索引 index 之后的元素都向前移动一位for (int j = index; j < size() - 1; j++) {arr[j] = arr[j + 1];}// 更新元素数量arrSize--;// 返回被删除的元素return num;}/* 列表扩容 */void extendCapacity() {// 新建一个长度为原数组 extendRatio 倍的新数组int newCapacity = capacity() * extendRatio;int *tmp = arr;arr = new int[newCapacity];// 将原数组中的所有元素复制到新数组for (int i = 0; i < size(); i++) {arr[i] = tmp[i];}// 释放内存delete[] tmp;arrCapacity = newCapacity;}/* 将列表转换为 Vector 用于打印 */vector<int> toVector() {// 仅转换有效长度范围内的列表元素vector<int> vec(size());for (int i = 0; i < size(); i++) {vec[i] = arr[i];}return vec;}
};

MVVM

不建议使用mvvm，因为还要用别的奇奇怪怪的别人写好的框架，到时候出什么事也把握不住

MVC学习

mvc和mvp的区别，主持人做很多活v只是装控件引用，主持人通过传来的model，写一个函数去修改装控件的引用，v是轻便了，主持人就苦了，存在对控件的引用，

如果有问题会怎么办，想想看，首先，如果控件没引用上，报null，控件引用错也大概率会报错，主持人界面呢，会接受model，拿model里的数据，修改v的引用，如果数据没有对口赋值，那就是主持人会出问题，那分工还算明确

相对于mvc，v更有v的感觉，控制者变成完全主持，本来只需要管引用的v的显隐，变mvp后，则还要有对v的修改，现在v就是纯显示器

目前觉得好像mvp更好一点，一个脚本只有组件引用，真的是可以把它当显示器来，这种情况适合组件超多的感觉，省的总觉得显示器有点不明不白

也只是目前觉得，遇到实际情况可能还是要转换策略

view都是差不多的，只要写一个各个数据的更新方法就可以，而传入的参数，则是可以专业对口的，比如这个面板只接受玩家数据model，这样也有了规范，想修改只允许传入哪个家伙的model，

然后按照这个model，有自我选择的从里面的数据里挑出相关然后再更新面板上的数据，也就是传入的数据都是有可挑选的，model可以尽管庞大，最后传过来的model类里，由该面板完成挑选的操作

ps:model里面的数据设置成只读也是为了强调model里面的数据和view脚本无关，view只管传入model类，然后在此时此刻把view的面板显示更新了

一个脚本处理了所有逻辑，看上去的确是最简单方便的，但没有分离对应的逻辑，里面一旦出问题了，一个小小的错误，你一下没理解清楚，你可以从它怎么出生的看到它怎么在养老院养老的

这样是极度划不来的，有些数据的空引用问题，在这种单脚本里，非常常见，因为数据这个东西，一旦什么数据删了，你找这个数据在哪，是麻烦的，现在的你当然可以说，肯定在这个大脚本里啊

一旦别的游戏对象上的脚本，想调用你这个面板上的数值呢，这个时候你的面板又死了，那是不是很狼狈？

所以把数据和游戏物体的显示分开，变优雅了不说，这样对游戏的可拓展性也是一种提升

因为数据更贴近一般逻辑，更能让一般人参与交流，游戏的逻辑实现才能更灵活

力扣的股票III

硬要讲清楚，还是比较难，虽然目前可以部分的接受官方在这题上的题解，但要解释出来还是很困难

这四种状态的影响层度是叠加的，第二层会叠在昨天买了的情况，第三层又会叠在昨天已经完成一笔交易的情况，最后一层同理

而的确是可以叠加状态，但是结合前一天的状态，要做什么呢，想赚更多的钱？

那有必要每个状态下都是想最大牟利吗

这样的话我只管最后一个sell2不就好了？

问题就在这，每天都是在知道前一天的最省钱或赚钱的结算情况下，再决定要不要进行任何一种状态的改变的

因为目的很纯粹，就是要尽可能的增加收入，所以每天的是买还是卖就是通过max和昨天判断

这样的话就会出现一个问题，就是如果想最后的sell2 是最赚钱的状态，就要确保昨天的buy2是最省钱的状态，如果没有就继续观望

而昨天的buy2想要确保最省钱的状态（因为昨天的buy2是在昨天的昨天已经通过sell1观望决定了最佳省钱做法的结算状态了），就要确保昨天的昨天的sell1是最省的观望结算状态

这样的话这个昨天的昨天的sell1又会看昨天的昨天的昨天的buy1，是不是最省（你可能会担心，为什么这么昨啊，那最开始的话怎么开始，不是左边就没了吗，但这样思考是忽略了你第一天的观望结算，会产生一个结算结果，第二天用第一天的结算状态的时候，因为有观望的选择，当然可以选择不用一直往昨天的昨天的昨天那样一直找根，因为最开始是0，找到这样的根之后就已经没必要再继续昨昨昨了

另外，这一点正是动态规划巧妙的一点，后面的状态看似对前面的每一天的状态的知晓情况都要求很苛刻，但实际上，初始给出的第一天，可以囊括后面的“昨昨昨”需求）

class Solution {
public:int maxProfit(vector<int>& prices) {int n = prices.size();// 四种和收入相关的状态的int buy=-prices[0],sell1 = 0,MIDbuy = -prices[0], sell2 = 0;// 第一天int yestbuy1 = -prices[0], yestsell1 = 0;int yestbuy2 = -prices[0], yestsell2 = 0;// 从第二天开始，一天一天的结算for (int i = 1; i < n; ++i) {yestbuy1=buy=max(buy,-prices[i]);yestsell1 = sell1 = max(sell1, yestbuy1 + prices[i]);yestbuy2 = MIDbuy = max(MIDbuy, yestsell1 - prices[i]);yestsell2 = sell2 = max(sell2, yestbuy2 + prices[i]);}return sell2;}
};

shift+alt+s选中的区域代码注释

输入：prices = [3,3,5,0,0,3,1,4]
输出：6
解释：在第 4 天（股票价格 = 0）的时候买入，在第 6 天（股票价格 = 3）的时候卖出，这笔交易所能获得利润 = 3-0 = 3 。随后，在第 7 天（股票价格 = 1）的时候买入，在第 8 天 （股票价格 = 4）的时候卖出，这笔交易所能获得利润 = 4-1 = 3 。

答案有且只有一个目的，尽可能的让收入最大化

每一天结束的经理的状态，有且仅存在下面的五种状态

1 未进行过任何操作；没有盈利机会，这个的每天的状态的变化则忽略

2 今天结束之后，只进行过一次买操作；buy1变量记录

3 今天结束之后，一次买和一次卖；sell1记录这种状态下的收入情况

一次买，一次卖，

有且只有2种情况，

今天买又今天卖（收入为0，对于增加收入没好处）

昨天的结算状态为“一次买”，今天只卖

因为每次单个i的循环都是独立的一天，这里的sell则base在昨天已经买了的结算情况

4 今天结束之后，一次买，一次卖，再第二次买；buy2记录

5 今天的结算为，一次买，一次卖，又有买一次，又卖一次（交易结束了）sell2

这个buy在这只是为了提供今天的前一天的结算情况下，买一次是什么状况

这个动态规划规划的是这四个状态，并驾齐驱的

然后在这几个赚钱的状态里找最赚钱的那个

马丁，被拷打的忘记怎么做游戏了，这动态规划，可能我是缺少系统的学算法了

但也许学算法对我现在的阶段并不合适，只是我觉得我现在缺乏了很多研究算法的条件资源，

优先利用可见效果的资源还是会更合适一点

先管游戏方向的东西，再去管什么刷算法题了，做这个股票题可能有点冲昏我头脑了，本来是想着可不可以在游戏开发里面得到某些成长

但这样有点因小失大，脑力消耗这么多，反馈并不多，可以说在潜意识，但反馈太少不会是好事，对算法不应该抱着太模糊的界限

每天30分钟在算法上，可以是了解相关知识，可以是想想有什么用，可以是准备，但留30分钟大脑给算法，这个东西太弱应该不会是什么好事，时间和英语背单词时间差不多，真的不能太多，主要方向和需要的应聘能力都没得到多少，花太多时间在资源不足的算法上，不合算

探讨：为什么在游戏开发中不使用MVC？

探讨：为什么在游戏开发中不使用MVC？ - 知乎

Save和Load就是正常一对一的存

单例方法，玩家数据，用static来

MVC简单概括

好像没有我想象的那么hifi...我的天，我今天肯定是醉了，感觉有点嬉皮

1. Model（数据层）：

PlayerModel.cs — 管理玩家数据。

public class PlayerModel
{public int health;public int score;public PlayerModel(int health, int score){this.health = health;this.score = score;}// 更新玩家数据public void UpdateHealth(int amount){health += amount;}public void UpdateScore(int amount){score += amount;}
}

2. View（视图层）：

PlayerView.cs — 控制玩家数据的显示。

using UnityEngine;
using UnityEngine.UI;public class PlayerView : MonoBehaviour
{public Text healthText;public Text scoreText;// 更新UI显示public void UpdateHealthDisplay(int health){healthText.text = "Health: " + health.ToString();}public void UpdateScoreDisplay(int score){scoreText.text = "Score: " + score.ToString();}
}

3. Controller（控制层）：

PlayerController.cs — 控制游戏逻辑并通过视图显示。

using UnityEngine;public class PlayerController : MonoBehaviour
{public PlayerModel model;public PlayerView view;// 初始化模型和视图void Start(){model = new PlayerModel(100, 0); // 初始玩家血量100，分数0view.UpdateHealthDisplay(model.health);view.UpdateScoreDisplay(model.score);}// 更新玩家状态void Update(){if (Input.GetKeyDown(KeyCode.H)) // 按H键减少血量{model.UpdateHealth(-10);view.UpdateHealthDisplay(model.health);}if (Input.GetKeyDown(KeyCode.S)) // 按S键增加分数{model.UpdateScore(10);view.UpdateScoreDisplay(model.score);}}
}

Model：PlayerModel.cs 负责保存和管理玩家的数据，比如血量和分数。它不关心如何显示这些数据，只负责数据本身的变化。
View：PlayerView.cs 负责显示玩家的数据。它接受来自 Controller 的指示，更新 UI 上的血量和分数。
Controller：PlayerController.cs 负责逻辑处理，捕捉用户输入，并通知 Model 和 View 做出响应。当玩家按下 H 键减少血量，按下 S 键增加分数时，Controller 会更新 Model 中的数据，并通知 View 更新界面。