Seven Conjecture of AOP

1. Conjecture can be seen everywhere.
In the future software development process, AOP will appear in the form of a basic programming capability, develop together with OOP, and become an integral part of the mainstream development environment. Currently, AOP is only used as a development tool or Runtime Code And exist. At that time, no product may claim "I used AOP" because no product has 2. Language-level conjecture.
The true implementation of AOP is based on a specific language. For example, a few years later, humans began to use k language (k is the last letter of J), and K language itself can be woven and cross-cutting. At this time, AOP is truly mature, because Program When writing code, you may not know whether you used oo or now. You only need to know how to use AOP, just as no product currently uses oop. Even if your Source code Not applied Programming Language You may also call the basic library of a certain application of AOP. In fact, kiczares, father of AOP, believes that AOP may first have a certain scale of applications on the operating system.

Knowledge about the construction and implementation of K-language virtual machines. However, it may be because of the inherent way of thinking that AOP will not be more used than Oop, or even it may still be the 15% solution mentioned by kiczares! However, Implementing AOP from a language perspective may bring huge changes to human programming concepts, just as oo brings.

3. There is an AOD/AOA conjecture.
Oop has far less impact on humans than its two younger brothers OOA/ood. The latter two have brought a profound revolution to the entire software development industry, it expands the number of development teams around the world by at least 10 times, the complexity of development tools and platforms is increased by 10 times, and the cost of completing some simple requirements of customers is reduced by 90%, the only pity is that the efficiency of software development has almost never changed by an order of magnitude (based on "no silver bullet"). Since AOP exists, we guess there will also be AOD/AOA. For example, there will be aspect-oriented reconstruction methods, Aspect-Oriented Design Patterns, Aspect-Oriented best practices, and Aspect-oriented process management, in future versions of UML, we can see specific improvements for the orientation, and even add a new UML diagram type. When all these things were produced, AOP was truly developed into its heyday.

4. Executable case conjecture.
AOP is a new technology that is widely used and full of imagination. However, at present, the research of AOP is too narrow, most open-source projects that claim to be studying AOP actually use AOP as an auxiliary tool. A considerable part of these projects are containers in the enterprise development environment, they did not develop the AOP itself. In fact, according to jacbson, AOP directly leads to two forms of Software Development: module development and case development. The current use case is only a drawing, it must be converted to OO code before execution. However, with AOP, AOP can directly connect multiple different modules (possibly from different development units) based on the case definition, in terms of formation, the aspect itself can be executed (Language-level conjecture), so the use case is no longer a drawing but can be executed. This is an excellent signal for modern software processes with UML as the core.

5. Standardization conjecture.
Oo's successful experience tells us that to achieve the final victory, we need to unify the internal concepts, and the rest of the debate is about implementation. I personally think that most OOP languages are conceptually consistent. This concept is called semantics by linguistics. Most OOP semantics come from early adopters of smalltalk and C ++, A few commercial products emerged from the maturity of Java technology. Currently, AOP still faces this problem. There are two conjecture about the standardization process of AOP in the industry. One is that aspectj is the leader. All major AOP implementations use the semantics of aspectj as the basic term for research. The design and implementation follow the current ideas; another conjecture is that an authoritative organization (open-source, commercial, or global research organization), such as Eclipse, IBM, and oopsla, provides a unified AOP semantic kernel, all AOP projects are developed based on this kernel. Java virtual machine is a success case of the previous approach, which is represented by XML.

6. All static knitting conjecture.
Next we will discuss a practical technical issue. Most AOP projects currently adopt two types of Knitting Technology: static weaving and dynamic weaving. The former refers to pre-compilation (pre-compilation), compilation, and post-compilation weaving, and the latter refers to knitting at runtime. Kiczares believes that although there are no obvious technical defects, dynamic knitting may face some development prospects, which he calls "Software Evolution problems ". I don't know if my understanding of the master's point of view is accurate. I think that since the compiled code is in change (Development), we always hope that this change will have the least impact on the weaving itself, at this time, the most common problem facing static knitting is recompilation, and dynamic knitting may not be that simple. In addition, full static knitting can lead to another advantage-which sounds a little strange-that is, it is weak because full static knitting inherits the constraints of the OO language, such as Java constraints and. net, CLR constraints, and so on, which is of great benefit for more standardized use of development tools. "We should be careful with every new tool that humans are preparing for large-scale applications ."

7. The idea of the birth of AOP.
Prior to the research and development of AOP, Mr. kiczares has also been engaged in other improvements to OOP, including reflection and metadata technology. In fact, to put it bluntly, both the flexibility and flexibility of the latter are above the former. However, as a result, linguistics believe that these technologies cannot effectively improve the disadvantages of OOP, it may even lead to a new "wolf problem ". Later, when kiczares discovered AOP, he realized that this was what people really needed. He thought they had caught the throat of the problem. So far, the Implementation Technology of AOP has been in a variety of different ways, and everyone is fighting for it. However, the ideas at the beginning of AOP are gradually forgotten in this competition, now the idea of using reflection, object meta technology, and various double-edged sword technologies to implement AOP has become the same as competing for market recognition as competing for a seat in the institution. Is this the development of things or the ideal backend? When can AOP return to its original source? We will wait and see what the fate was last day.

Recently, several of my friends and I are organizing a group of open-source fighters to write AOP. net. This is an open-source software. I can see some news about this project on the blog. However, for various reasons, we have not yet reached a consensus on some basic questions. This article comes from my consistent views on AOP and is also a concentrated answer to many questions in the community.

From: http://briansun.cnblogs.com/archive/2005/08/31/227048.html