这是「从函数式角度看设计模式」的第四篇。目的是从和OOP不同的角度重新审视设计模式。 今天讨论的是工厂模式。但是其实并没有一个叫工厂模式的设计模式，一般来说，有抽象工厂和工厂方法这两种模式。 抽象工厂「能创建一系列相关的对象， 而无需指定其具体类」。 工厂方法「在父类中提供一个创建对象的方法， 允许子类决定实例化对象的类型」。 两种模式都属于「创建型模式」，换句话说就是和程序里面值的创建有关。

虽然现在的实习已经不再使用Unity了，但是回过头看，至少在异步编程这方面，还是有了不少体会，也更好的理解了Unity的Coroutine的设计。 之前提到了使用UnityWebRequest来跟网关进行通信，因为是个典型的异步场景所以使用了Coroutine。在C#里面，一般都是用Task<T>来表达异步的语义，这一点和JavaScript类似，而且也可以很方便的用上async/aw

在做项目的时候和同学就「单文件的最大行数」产生了分歧。同学的说法是，「代码长就看不下去，因为干净架构需要简单、行数短的代码」。 但是在这个项目，或者说专门针对当时的情况，有这么几个理由吧： 这段代码是Flutter的，众所周知，Flutter是以嵌套括号和冗长的render函数而闻名的。 代码使用了MVVM的模式，因为是试验性的代码，所以就先把各种class和enum写在了同一个文件里，这样的话

今年学校课程里有一门课，大概要求选一门技术来介绍一下。考虑到我的编程偏好，我觉得介绍一下函数式编程的概念比一些很具体的厂商产品更有趣吧。所以就选了Monad。 想想也许适合水一篇文章，毕竟一般来说，接触函数式编程的人最终都要写一篇自己的Monad介绍文章（雾 这篇文章不是用来手把手教怎么入门Monad的，毕竟课程要求也不是这个，所以就是简单的「引子 - 正式介绍 - 用处和优势 - 案例 - 小结

这是「从函数式角度看设计模式」的第三篇。目的是从和OOP不同的角度重新审视设计模式。 实际上感觉都没什么好写的？ 这是「模版方法模式」的定义和实现方法： 模板方法模式是一种行为设计模式， 它在超类中定义了一个算法的框架， 允许子类在不修改结构的情况下重写算法的特定步骤。 模板方法模式建议将算法分解为一系列步骤， 然后将这些步骤改写为方法， 最后在 “模板方法” 中依次调用这些方法。 步骤可以

在这个实习里也用到了基于C++的私有框架。这个框架虽说是基于C++17的，但是错误处理用的是错误码和参数位置返回出去的做法。可能和框架需要接入gRPC有关。 自己这边需要用框架来做一些简易的操作，实现一个自己的proxy服务器，也就想到了用std::optional来重新处理一下这个错误流程的想法了。 大概的思路是，因为自己写的方法会被框架托管，所以自己实现的每个方法都返回一个optional的值

这是「从函数式角度看设计模式」的第二篇。目的是从和OOP不同的角度重新审视设计模式。 这里讨论的是观察者模式，和它在函数式语言里的等价品，模式匹配（Pattern Matching）。最后也会讨论到GADT（广义代数数据类型）。 Java的模式匹配 考虑一个可以容纳各种数据类型的列表，这里用的是Java语言。 123456public record Empty() {}var

最近在实习，主要的内容是Unity（WebGL），需求是能够从服务器（Proxy）获取数据后展示出来，应该是个蛮简单的任务吧。 Unity提供了一个叫UnityWebRequest的工具类，封装了常用的网络方法。按理来说使用Get方法就能够很容易得到结果了，但是官网没有怎么await长时间请求的案例，网上抄来的其他代码也不管用。 后来发现问题出在不应该用下载过程中的UnityWebRequest.

这是「从函数式角度看设计模式」的第一篇。目的是从和OOP不同的角度重新审视设计模式。 第一篇就从lambda说起了，因为这是函数式编程里面最常见的概念。在设计模式里，这个概念一般叫做「策略模式」。 按照定义，「策略模式是一种行为设计模式， 它能让你定义一系列算法， 并将每种算法分别放入独立的类中， 以使算法的对象能够相互替换」。简而言之，就是不把算法写死，而是在运行时可以按需切换。一般来说，OOP

在上次笔记后又过了一段时间，在 parser 方面并没有太多的进展。倒是在反复测试后发现或许 MonadError、MonadState 和 catchError 的办法能够提供我想要的组合子的语义。也为此做了一些简单的测试。 当然了，也有缺点：在有些语法分支上，是不得不使用 try 组合子的。而一旦启用了这个组合子，就又会不得不处理回溯的问题。 不过相比另一个问题，这个问题算是比较好解决的了。那