实践管理元编程的复杂性（AOP /反射/宏）技术

Question

方面，宏，反射和其他精巧的细节 - 好的部分

我注意到，“元编程”招数（以clojure世界中，函数具有元数据，在oo世界中，我们有反射，AOP等概念...）可以成为解除和扩展现有代码功能的好方法，无需对其进行编辑。这些技巧使我们能够拦截，重定向和打包代码的功能，以便能够以高度动态的方式进行扩展。

害怕的

然而，正如许多人声称 - 宏的过度使用可以使代码难以理解。如果我们不仔细管理这些代理程序的创建，那么“黑板”软件体系结构模式（其中多个代理程序修改或编辑公共资源）可能很危险。最后，我会非正式地注意到，C++和java的长期受欢迎程度至少部分归因于它们是“没有意外”的语言 - 代码是清晰，明确和程序化的。**

问题：动态代码注入技术用于减少锅炉板和去耦功能集的承诺需要对文档，类设计和软件工程进行“新”思考？

我的问题

难道我们的文件/的方式部署正常码，管理源代码软件包，整合图书馆需要不同的或新的技术时，我们与更传统的面向对象方法的结合开始包容的元编程方法？

例如，我们是否应该考虑使用元编程作为其他更常规的OO编程技术的替代方法？

是否有一套由元编程引入的已知的红旗？我们如何避免它们？

使用方面，反射和其他动态软件技术的最佳用例是什么？

Answer 1

我发现AOP是需要在软件项目中非常小心地使用的东西，并且具有明确的目的。我发现它对于事务划分，安全性和日志记录等一些锅炉过程非常有用，但它很容易让AOP陷入困境，并且它可能成为意外复杂性的主要来源。

Answer 2

“这取决于:) :) ...这可能是所有主观编程世界中的问题的最佳答案。

我会建议在开始使用AOP或DI之类的技术之前，请给出一个非常严肃的问题，但是您是否真的需要它。我们作为程序员往往会被这些新的技巧和技巧所吸引，这些技巧和技术让我们看到代码中的美（表面）。我们应该追求的代码真正的美妙之处在于简单，没有别的。记住每个添加到系统中的新技巧/技术/框架都会增加系统的复杂性（可能呈指数级增长）。

我个人的想法是：构建程序而不是应用程序，构建库而不是构架。

Answer 3

下面是（SICP），可能是相关的讨论帖：

“这是毫不夸张地认为这是在编程中最根本的想法： 的评估，它决定的意义在程序设计语言中，表达式只是另一个程序 为了感谢这一点，我们将自己的图像作为程序员来改变，我们认为自己是语言的设计者，而不是仅仅由其他人设计的语言的用户。