In my previous article "Component/Service Oriented Software System Development Thinking", I will collectively refer to the Software modules including BinaryLevel and Source Code Level as Component. This classification method is not very consistent with the traditional general definition of Component. This article is to explain why I want to classify it. -In the traditional definition, it is generally considered that there is an essential difference between Component Oriented and Object Oriented. In o'reilly's Programming. net Component lists the main differences between the two and the basic original design principles of Component Oriented. Readers who haven't read it can download it and see that the link here only contains the first chapter of the book. Of course, the difference and design principles mentioned here are included in this chapter. Difference: 1. building Blocks Versus Monolithic Applications-Multi-assembly or single assembly 2. interfaces Versus Inheritance-black box or white box design principles: 1. separation of cnterface and implementation2. Binary compatibility3. Language idependency4. Location transparency5. Concurrency management6. Version Control7. Component-based security-
So why are there differences between the two originally? The difference does not seem to be a very small concept in a unified concept-"Component?Let's talk about the two main differences mentioned above. The author of the original book's main point is that components should always be language-independent Binary-level black box models, while OO is generally language-related source code-level white box models. Next, we also mentioned that the reuse of components is generally not concerned with its internal details, but is used by calling large particles of functions or class inheritance. OO can inherit from fine particles, in addition, it is convenient to use combinations of design patterns, intercept function calls, insert code, modify internal details, and so on. class inheritance can also be fine-grained. Therefore, there are essential differences between the two. From the perspective of the author's consideration of this issue and the definition of traditional components, the above arguments are certainly good. However,
The emergence of an idea or technology has largely broken the above BoundaryWhat technology is it? You may have reached your lips.
-- AOP. -I will not talk about the basic idea of AOP here. If you are not familiar with it, you can search for AOP on the blog site. Here I want to explain to you why the limitations and differences between CO and OO have been greatly reduced with the idea of AOP? Of course, I would like to mention it here. The aop I refer to here mainly refers to the AOP with binary-level weaving capability, such as one written by Teddy. the AOP tool AspectWeaver under. Net, not just like Castle. aspect # This kind of DynamicProxy-based AOP implementation. Because of the Binary-level weaving capability of AOP, it is more straightforward to say that AOP makes it as easy to operate binary components or assembly as to operate on source code-level modules, this allows you to use a binary Assembly just like a component with source code. It is also easy to break an assembly into multiple assembly at the binary level, or to process one assembly at a time. The difference between black box and white box does not make much sense. Now it can be regarded as a white box. As long as the source code can be compiled into a mutually compatible and identifiable binary assembly, We can reuse and transform the program module at the binary level. Of course, the basic principles of componentized design listed above are still applicable. At the same time, this binary-level detailed manipulation capability enables AOP not only to use all the tools and design ideas available in OO, but also to be a superset, which can achieve many functions that exceed OO restrictions, for example, Mixin, interface implementation, basic class change, static code interception, and so on/insert/Delete. If you are interested, you can view the relevant information. -
It is precisely because of this special capability of AOP that, to a large extent, breaks through the boundaries between binary components and OO components and brings about a huge revolution in software development ideas and reusable software design, and many possibilities that could not be achieved before have become a reality.I have already described the general style of such a change in my previous article "reinterpreting AOP", and I will discuss it further later in "Looking into Component. Coming soon!
