Open 981377660LMT opened 3 months ago
作者：廖鑫炜 链接：https://www.zhihu.com/question/61169850/answer/185652605 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
设计模式的六大原则大部分仍值得遵循。基于 Java 实现的设计模式，未必适合其它语言和领域。想想 C# 的 event、delegate、lambda 可以简化或者消除多少种 GoF 的模式，再想想 Golang 的隐式接口。C++ 是游戏开发领域最主要的语言，可以 OOP 但并不那么 OO，比如缺少语言层面纯粹的 interface，也缺少 GC、反射等特性。照抄 Java 的设计模式未免有些东施尿频，而且难以实现 C++ 所推崇的零代价抽象。（template 笑而不语）局部使用 OOP 设计模式来实现模块，并暴露简单接口，是可以起到提升代码质量和逼格的效果。然而在架构层面滥用，往往只是把逻辑中的复杂度转移到架构复杂度上。滥用设计模式导致的复杂架构，并不对可读性和可维护性有帮助。比如原本 c style 只要一个文件顺序读下来就能了解清楚的模块，滥用设计模式的 OOP 实现，阅读代码时有可能需要在十几个文件中来回跳转，还需要人脑去正确保证阅读代码的上下文...过多的抽象导致过多的中间层次，却只是把耦合一层一层传递。直到最后结合反射 + IoC框架 + 数据驱动，才算有了靠谱的解决方案。然而一提到反射，C++表示我的蛋蛋有点疼。
作者：廖鑫炜 链接：https://www.zhihu.com/question/61169850/answer/185652605 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
设计模式的六大原则大部分仍值得遵循。基于 Java 实现的设计模式，未必适合其它语言和领域。想想 C# 的 event、delegate、lambda 可以简化或者消除多少种 GoF 的模式，再想想 Golang 的隐式接口。C++ 是游戏开发领域最主要的语言，可以 OOP 但并不那么 OO，比如缺少语言层面纯粹的 interface，也缺少 GC、反射等特性。照抄 Java 的设计模式未免有些东施尿频，而且难以实现 C++ 所推崇的零代价抽象。（template 笑而不语）局部使用 OOP 设计模式来实现模块，并暴露简单接口，是可以起到提升代码质量和逼格的效果。然而在架构层面滥用，往往只是把逻辑中的复杂度转移到架构复杂度上。滥用设计模式导致的复杂架构，并不对可读性和可维护性有帮助。比如原本 c style 只要一个文件顺序读下来就能了解清楚的模块，滥用设计模式的 OOP 实现，阅读代码时有可能需要在十几个文件中来回跳转，还需要人脑去正确保证阅读代码的上下文...过多的抽象导致过多的中间层次，却只是把耦合一层一层传递。直到最后结合反射 + IoC框架 + 数据驱动，才算有了靠谱的解决方案。然而一提到反射，C++表示我的蛋蛋有点疼。