装饰器和依赖注入等面向对象的模式使 TypeScript 开发过于复杂
该文批评 TypeScript 框架 NestJS 使用装饰器和依赖注入等模式，这些模式旨在解决面向对象编程的问题，但却妨碍了 TypeScript。
NestJS 是来自 Java 等其他语言的人们在没有 Java 提供的模式的情况下不知道如何开发的东西之一。
Java 开发人员会想：
1、“如果我不能使用装饰器，如何在不影响基类的情况下更改方法？”
错！ ...什么基类？你为什么要扩展任何东西？您的可重用方法不应该被困在继承链甚至类的范围内。
2、“如果没有依赖注入，你就无法测试具有依赖关系的类！”
这仍然是在继承类中思考的问题，而不是您应该在 TypeScript 中考虑的问题。
通过强制解决不存在的问题，NestJS 所创建的工作量和代码量是使用既定最佳实践执行相同操作所需的 3 到 5 倍。
看在上帝的份上，不要用像 NestJS 这样可怕的即时遗留垃圾来破坏 TypeScript 开发。
作者认为：
- NestJS 依赖于过时或质量较差的依赖项，例如类验证器和 TypeORM。
- NestJS 中的依赖注入在测试和模拟依赖项时会产生不必要的复杂性。
- 对这些模式的感知需求源于对如何在没有继承或基类的情况下使用 TypeScript 正确设计应用程序的误解。
- NestJS 强制解决不存在的问题，与已建立的 TypeScript 最佳实践相比，大大增加了所需的工作量。
网友观点：
- NestJS 过度设计了面向对象编程，并使 OOP 超出了其极限。
- TypeORM 因不是强类型以及简单 CRUD 之外的查询性能不佳而受到批评。
- 装饰器是一种高阶类，并且依赖注入不是标准的 OOP。