这是「从函数式角度看设计模式」的第五篇。 装饰器，按照定义，是一种「通过将对象放入包含行为的特殊封装对象中来为原对象绑定新的行为」的设计模式。一般来说，是在「基类无法被继承或者不想继承基类的情况下复用并扩展基类」的方法。大体上也是使用了组合的概念。 一个典型的OOP写法大概如下： 12345678910111213141516171819202122232425262728293031323334

上次提到了Quarkus和Spring里面的依赖注入是通过注解来实现的，这次也就再讨论一下依赖注入的事情吧。 从字面角度理解的话，依赖注入（DI），也就是在上下文外面构建一个变量，然后把变量「注入」进上下文里面。 用Java来举例的话，假设有A和B类型，A类型里面需要转发一些操作到B类型上，一种办法是在A类型里面直接创建B的变量然后操作，例如这样： 12345678class A {

在软件工程里面，经常会看到设计模式这个词。对大部分工程师来说，尤其是Java背景的，大概从本科开始就在学习设计模式吧。四人帮，23套设计模式，更是从考卷到面试再到博客上经久不息的话题。 不过「设计模式」这个概念本身想表达什么，似乎多少有点模糊了呢。 这里有一些「官方」的定义： 在软件工程中，设计模式是对软件设计中普遍存在（反复出现）的各种问题，所提出的解决方案。 设计模式并不直接用来完成代码的编

不知不觉，接触代码也有一段时间了。虽然进学校正式地学编程也就是最近四五年的事情，不过写的第一行代码倒是在这之前。 大概是因为认识的朋友许多都在写代码或者打竞赛所以也就对代码感兴趣了，也跟过一些C或者Python的题，不过都半途而废了。倒是想起来，那时候写的第一个程序，似乎在现在看来也是有趣的呢。 大概是这样的代码： 1234567891011121314# include <stdio.h&

在Kotlin里面，经常会用到Scope函数，在一个值上面创建一个临时的作用域来进行各种操作。更具体的说，这是一类定义在任意类型上的扩展函数，接受一个以这个类型作为参数的lambda回调，这样的话，这个值就可以被「注入」进作用域，来实现更简洁的声明式写法了。 Scope函数一般来说有这么几种主要的使用场合： 和可空类型还有nullable调用链结合，去掉繁琐的precondition 比如说命令

和朋友讨论自己小服务器的一些规划，因为我有想要在cocricot外增加miniaturia并且同时使用两者的打算，想起了之前也想自行添加更多的玻璃方块，聊天话题就转到了mod的设计上。 大体上，这个mod该怎么设计呢？ 我的想法，大概还是基于「如果已有的mod可以实现，尽量不添加」吧，一个原因是因为添加mod对于一个mc服务器来说大概是不可逆的——至少不能保证删掉mod后服务器还能正常运行。 所以

写了差不多一个月的Quarkus，对这套写法也差不多熟悉了。不过我还是想说很不喜欢这种写法。当然Quarkus大约比Spring还是好点，没有字符串硬写的切面了，最多也只是@Inject这样的依赖注入语法。 一般来说，依赖注入的实现不外乎两种思路，通过constructor传参，或者在类型里面添加setter后在外部调用。注解的实现机制，Spring的autowire也好，Quarkus的ArC也

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

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

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