方面，宏，反思和其他细节 - 好的部分
我注意到“元编程”技巧（在clojure世界中，函数有元数据，在oo世界中，我们有像反射，AOP等概念......）可以是一个很好的解耦方法扩展现有代码的功能，无需编辑。这些技巧允许我们拦截，重定向和包装我们代码的功能，以便可以以高度动态的方式进行扩展。
可怕的部分
然而，正如许多人所声称的那样 - 过度使用宏会使代码难以理解。如果我们不仔细管理这些代理的创建，那么几个代理修改或编辑公共资源的“黑板”软件架构模式可能是危险的。最后，我会非正式地注意到C ++和java的长期流行，至少部分是因为它们是“无意外”的语言 - 代码清晰，明确，程序化。**
问题：用于减少锅炉板和解耦功能集的动态代码注入技术的前景需要一种“新”的方式来考虑文档，类设计和软件工程吗？
我的问题
当我们开始将元编程方法与更传统的OO方法结合起来时，我们记录/部署普通代码，管理源包，集成库的方式是否需要不同的或新的技术？
例如，我们是否应该考虑使用元编程作为其他更传统的OO编程技术的替代方案？
是否存在由元编程引入的一组已知的红色标志 - 我们如何避免它们？
使用方面，反射和其他动态软件技术的最佳用例是什么？
答案 0 :(得分：1)
我发现AOP需要在软件项目中非常谨慎地使用，并且具有明确的目的。我发现它对于某些锅炉板工艺很有用，比如事务划分，安全性和日志记录，但是很容易让自己陷入AOP的麻烦之中，它可能成为意外复杂性的主要来源。
答案 1 :(得分：1)
“这取决于”:) ...这可能是编程世界中所有主观问题的最佳答案。
我建议在使用AOP或DI之类的任何技术之前，请先说明一下你是否真的需要它。作为程序员，我们对这些新技巧和技巧非常着迷，这使我们在代码中看到了美（肤浅）。我们应该努力的代码的真正美妙之处在于简单而不是别的。
请记住，添加到系统中的每个新技巧/技术/框架都会增加系统的复杂性（可能是指数级的）。
我个人认为：构建程序而不是应用程序，构建库而不是框架。
答案 2 :(得分：1)
以下是（SICP）中可能与讨论相关的引用：
“将此视为编程中最基本的想法毫不夸张： 评估者确定编程语言中表达式的含义，只是另一个程序。 要理解这一点，就是要改变我们作为程序员的形象。我们将自己视为语言的设计者，而不仅仅是其他人设计的语言用户。“