管理元编程（AOP/反射/宏）技术复杂性的实践
方面、宏、反射和其他细节 - 好的部分
我注意到“元编程”技巧（在 clojure 世界中，函数具有元数据，在 oo 世界中，我们有这样的概念反射、AOP 等...）可以是解耦和扩展现有代码功能的好方法，而无需对其进行编辑。这些技巧使我们能够拦截、重定向和包装代码的功能部分，以便以高度动态的方式扩展它。
可怕的部分
然而，正如许多人声称的那样 - 过度使用宏会使代码难以理解。如果我们不仔细管理这些代理的创建，“黑板”软件架构模式（其中多个代理修改或编辑公共资源）可能会很危险。最后，我想非正式地指出，C++ 和 Java 的长期流行至少部分是因为它们是“毫无意外”的语言 - 代码清晰、明确且程序化。**
问题：动态代码注入技术减少样板文件和解耦功能集的承诺需要一种“新”的方式来思考文档、类设计和软件工程？
我的问题 我们记录/部署正常的方式当我们开始将元编程方法与更传统的 OO 方法结合起来时，代码、管理源代码包、集成库需要不同的或新技术？
例如，我们是否应该考虑使用元编程作为其他更传统的 OO 编程技术的替代方案？
元编程是否引入了一组通用的已知危险信号——我们如何避免它们？
使用方面、反射和其他动态软件技术的最佳用例是什么？
Aspects, Macros, Reflection, and other niceties - the good parts
I've noticed that "meta programming" tricks (in the clojure world, functions have meta data, in the oo world, we have concepts like reflection, AOP, etc...) can be a good way to decouple and extend functionality of existing code, without editing it. Such tricks allow us to intercept, redirect, and wrap functional peices of our code so it can be extended in a highly dynamic way.
The scary part
However, as many have claimed - overuse of macros can make code difficult to understand. The "blackboard" software architecture pattern, where several agents modify or edit a common resource can be dangerous if we dont manage the creation of those agents carefully. Finally, I would informally note that the long standing popularity of C++ and java is, at least partially due to the fact that they are "no-surprises" languages - where code is clear, explicit, and procedural.**
The problem : The promise of dynamic code injection techniques for reducing boiler plate and decoupling feature sets requires a "new" way of thinking about documentation, class design, and software engineering ?
My Questions
Does the way we document/deploy normal code, manage source packages, integrate libraries requires different or new techniques when we begin accomodating meta-programming methods in conjunction with our more traditional OO methodologies ?
For example, Should we consider the use of meta programming as an alternative to other, more conventional OO programming techniques ?
Are there a general set of known, red flags introduced by meta-programming -- and how can we avoid them ?
What are best use cases for the use of aspects, reflection, and other dynamic software techniques ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我发现 AOP 在软件项目中需要非常小心地使用，并且有明确的目的。我发现它对于一些样板流程（例如事务划分、安全性和日志记录）很有用，但 AOP 确实很容易让您陷入麻烦，并且它可能成为意外复杂性的主要来源。
I find that AOP is something that need to be used very carefully in a software project and have a well defined purpose. I find it is useful for some boiler plate processes like transaction demarcation, security and logging but it is really easy to get yourself in trouble with AOP and it can become a major source of accidental complexity.
“这取决于”:) ...这可能是编程世界中所有主观问题的最佳答案。
我建议在使用 AOP 或 DI 等任何技术之前，请认真考虑一下您是否真的需要它。作为程序员，我们往往对这些新技巧和技术非常着迷，它们使我们看到代码中的美（表面的）。我们应该追求的代码真正的美在于简单，除此之外别无其他。
请记住，您添加到系统中的每一个新技巧/技术/框架都会增加系统的复杂性（可能呈指数级增长）。
我个人的想法是：构建程序而不是应用程序，构建库而不是框架。
"It depends" :) ... That's what is probably the best answer for all subjective questions in programming world.
I would suggest that before going to use any of the technique like AOP or DI, please give it a very serious though in respect to whether you really really need it. We as programmers tends to gets very fascinated by these new tricks and techniques which makes us see beauty (superficial) in code. The real beauty of code that we should strive for is simplicity and nothing else.
Remember every new trick/technique/framework you add to a system will increase the complexity of the system (probably exponentially).
I personally go by the idea of: Build Programs not Applications, Build libraries not frameworks.
以下是 (SICP) 中可能与讨论相关的引用：
Here's a quote in (SICP) that might be relevant to the discussion: