Along the way to "reuse"-Sa, Oo (DP), component, SOA, AO (zz)

since software development, eliminating duplicates and improving software reusability have always been an important goal we are pursuing. This article will focus on this topic, repeat the structure ( SA ), object-oriented ( oo ) and Design Pattern ( Design Pattern ), component ( component ), Aspect-Oriented ( AOP ) until the development of SOA . Let me reuse "" " from a simple or even one-sided this gives you a clear understanding of the terms that appear in many articles . Although structured, object-oriented, and even design patterns are well known, " " , " AOP " and " Soa " may not be understood yet, the background of their generation is even more unfamiliar. Why do I need a new technology? This is exactly what I was most concerned about before I went deep into it.

structured programming, i'm afraid almost no one in the garden has used it to develop a 1000 line code Program , I " have the honor to " in my freshman summer vacation (it is definitely big two short semesters) I went through a job. In a structured world, there is often one or another repetition, and similar code can be seen everywhere. Although it was still a good dish at that time, naturally, you will summarize some common functions into various modules by function, and continue to reuse them in future projects. Obviously, at this time, you will try to reduce the use of global variables, in this case, we are most afraid of a problem called "side effect" , that is, you modified the value of a variable in A , the result of B is accidentally affected. In this way, we will try to modularize the code so that the variables in one module will not be used by another module. Hmmm... Didn't you see the encapsulated shadow? Encapsulate variables into objects to prevent external modifications. Isn't that exactly one of the object-oriented features? In this case, the functional modules in the structure become classes in the object-oriented model, and the objects come from this. We know that Object-oriented has three important features: -- encapsulation, inheritance, and polymorphism. So how does inheritance and polymorphism contribute to reducing repeated code? Inheritance is quite easy to understand. Subclass inherits the parent class and naturally gets the features of the parent class. The code that implements the features of the parent class does not need to be repeated in the Child class, which naturally reduces the number of duplicates. Polymorphism is not as straightforward as inheritance. In fact, polymorphism is also a concept that many people do not understand or even know what it is used when learning object-oriented programming. Although the main purpose of this article is not to introduce polymorphism, but I really want to talk about the topic of " removing duplicates " , let's talk about my understanding of polymorphism.

In the old example of calculating wages, there are two types of employees: formal workers and hourly workers. Their wage calculation methods are different. Let's take a look at the implementation in the structure:

 
IntGetsalary (StringEmployeename)
 

 
{
 

 
IntBasesalary, bonus;
 

 
If(Isofficalemploree (employeename ))
 

 
{
 

 
Basesalary = 1000;
 

Bonus = 500 * getrate (employeename );
 

 
}
 

 
Else
 

 
{
 

 
Basesalary = 50 * gethours (employeename );
 

 
Bonus = 0;
 

 
}
 

ReturnBasesalary + bonus;
 

 
}
 

Now there are only two types of employees, and the method for calculating the salary is not complicated. You can see that"Repeated". We can resolve this type of problem as follows:

 
If(...)
 

 
{
 

 
A ();
 

 
B ();
 

 
C ();
 

 
}
 

If(...)
 

 
{
 

 
A ();
 

 
B ();
 

 
C ();
 

 
}
 

 
//...
 

Function processing steps are basically the same,A,B,CThere are different processing logics under different circumstances (that is, different types of object-oriented. We use the object-oriented method to rewrite the above example:

 
IntGetsalary (employee Employee)
 

{
 

 
IntBasesalary = employee. getbasesalary ();
 

 
IntBonus = employee. getbonus ();
 

 
ReturnBasesalary + bonus;
 

 
}
 

RepeatedA,B,CNo, isn't this exactly reducing repeated code? No matter what kind of employees,GetsalaryMethods can be reused.(The above example is only used to illustrate the problem of eliminating duplicates. Please do not elaborate on whether its design is appropriate.)

For this reason,Interfaces are widely used in object-oriented languages.

 
Public VoidUsequeue (imessagequeue q)
 

 
{
 

 
//...
 

 
Q. Send ("Hello reusable Method!");
 

//...
 

 
}
 

What does the above Code mean? UsedImessagequeueThis method achieves maximum reusability, regardless of the specificMessagequeueThis method can always be reused. (For more information, seeSeparate contract from implementationArticle)

Although structured languages can partially solve the reuse problem with the help of modularity, function pointers, and other technologies, they are already very limited. At this time, object-oriented languages are being used flexibly for encapsulation and inheritance, on the basis of polymorphism, we have solvedSource codeLevel of reuse. Note that a new term appears--Source code-Level Reuse. Since there is source code-Level Reuse, there will naturally be other levels of reuse. Obviously, we are not satisfied with code-Level Reuse. We hope to achieve more advanced reuse. In fact, when object-oriented technology came out, few people could really understand the technology and use its features flexibly to improve code reusability. Not long ago, calledGofFour of them made a book.--《Design Patterns. In this book, I deeply explain how to use object-oriented technology and the benefits we can get from it. It tells us how to write reusable code, and increased the Software Reuse Technology to another level.--Reuse of ideas. When designing software, we can look at how to reuse these patterns in software design at a higher level than code. Almost everyone 《Design PatternsHow many people have paid attention to the sub-titles of this book?--《Elements of reusable object-oriented software.

From code to thought, the design pattern has completed a great leap in reuse. Are there other forms of reuse? With the development of software development technology, higher reuse needs will follow.

Imagine what you need to do if you need a previously written function in a project? You have to copy all the previous code to the new project. After a while, you suddenly find that this section of code that is often reused by other projects hasBugYou need to make some small changes. Can you imagine the price you have to pay for it? Source code-Level Reuse does not have much problem in a single project, but faces higher level Reuse--Cross-Project reuse exposes its problems. How can this problem be solved? Pair. NetReaders who are very familiar with the technology must have come up with references.DLLComponent. Put the code to be reused into a separateDLLComponents, you only need to addDLL. When the code to be reused changes in the future, you only needDLLReplace the component with the new version. At this point, you have inadvertently used the construction technology (build, components representComponent). The construction technology enables us to achieve binary-Level Reuse, which solves the reuse problem between projects to a certain extent. In addition, in some component technologies, cross-language reuse is also realized. For exampleComAnd. NetWith technical support, we can useVBCallC ++Or components written in other languages. To achieve this, the self-description function of the component is fully dependent. That is to say, the component not only contains classes, but also contains types that describe these classes, methods, parameters, and so on. This information makes a new programming tool.--"Reflection (Reflection)".

InOo And Component With the help of technology, we have been able to easily reuse some software functions. However, such reuse is usually intended for small functions that are frequently used in one or more projects. With the development of software technology, the scale of software is getting bigger and more complex. At this time, it puts forward higher requirements for reuse technology. We hope to achieve reuse between two independent application systems. System A Some features are required, while the previous system B With these features, we are developing the system A In this case, all functions are developed by the user, so that the system implementation form is very uniform, and the function interaction methods and parameters can be completely controlled by the user. However, this is obviously a waste of resources. B This method can be considered if it is not very complex, but in most cases, rewrite the system B The cost is unacceptable. Another way is B Expose the interfaces of core functions, and then the system A Use these interfaces and Systems B Information interaction. B Reuse in another system. Such application systems are widely used within an enterprise and between enterprises. A typical example is reuse of legacy systems and external systems. In this case, the system A And System B They run in two independent processes, either on the same machine or on two different machines. To achieve functional interaction, we must inevitably use distributed object technology. Using the type metadata in the component, we can easily generate remote object interfaces on the client, and create a proxy object to access remote objects on the client. Remoting In Soapsuds.exe In . Net Is a tool for implementing such functions in a distributed system. Therefore, component technology also plays an important role in implementing the reuse between application systems.

Now let's look back at the changes in the application of object technology in this distributed environment. The first thing to note is that the systemBIt does not need to expose all its business objects to the system.AWe need to reuse the systemBAt this time, we usually useFacadeModeBCore functionsFacadeObjects, so the inheritance and polymorphism object-oriented features are basically not used in distributed objects. Second,FacadeThe methods in the object are coarse-grained. That is to say, one of the methods is usually to complete a complex function at a time. For example, you cannot use a remote object as follows:

 
Person P = remotegatway. getperson ("Idior");
 

 
P. Age = 24;
 

 
P. Sex = sex. Male;
 

 
//...
 

The following method should be adopted:

 
Person P = remotegatway. getperson ("Idior");
 

P = P. setbaseinfo (NewPersoninfo (24, sex. Male ,...));
 

The reason for doing so is to avoid too many network calls, while common objects are the opposite. In addition, to achieve performanceScalability(Scalability ),FacadeObjects are usually stateless (For details, referDistributed Application --- applying remoting & Enterprise Service). From this point of view, in order to achieve interaction between systems,FacadeObjects basically completely lose the features that an object should have. I call this object a service object. The concept of services is coming soon. However, these distributed objects are often limited to a special distributed technology, such. NetOfRemoting,CobraOrEJBIf the systemAAnd SystemBThe same technology is used, so there is no big problem. However, in actual applications, there are so many coincidences. If. NetThe ApplicationJavaApplication interaction makes it easy to imagine how difficult it is. In addition, in enterprise applications, we cannot ignore the security and transactional nature of the entire system. It is almost impossible to let two different distributed systems work together and ensure security and transactions. However, this type of reuse needs are so wide that we have finally ushered inSOA.

SOA One of the most critical features isLoosely Coupled(Loose coupling) . Now you should be able to understand why this is the most important. To achieve integration between heterogeneous systems, services can interact with each other only with the loose coupling feature. SOA The services mentioned earlierFacadeObject upgrade The metadata used to describe the service and the method used to call the service must be loosely coupled, that is, it does not depend on a specific platform. Compared with the component technology we mentioned earlier, it also provides metadata of service objects, but the description of these metadata is related to specific component technologies, the technology for calling objects in components also relies on a specific platform. To obtain the loose coupling feature, we use Web Services Technology SOA . Where WSDL Used to describe the metadata of the service, and Soap This defines how to call the service and return results. These specifications comply with specific standards, and manufacturers will also follow these standards. In fact Facade Object in Java Generally EJB In Session Bean In . Net You can use Servicedcomponent And can be easily upgraded Web Service. For example JBuilder You can use some menu items to easily Session Bean Publish as one Web service, While Com ++ 1.5 It also provides Soap services Function, you can use it to easily Servicedcomponent To Web Service .

From this, we can see thatSOAIt solves the reuse problem between application systems.SOAIs a system-integrated solution. The main difference between it and the traditional distributed object technology lies in its loose coupling..

Last but not leastAOPPreviously, the reuse we talked about is aimed at implementing a function. You may have thought about the reuse of calling a function. To use any function, you must call some methods in the corresponding object. But if this call code keeps appearing in your code, don't you think it is a repetition? For example, in order to record system behavior, we often need a log, and the method calls for recording logs are almost distributed in every corner of the system. We wish to be able to define the Call Code only once in one place to record all the logs.AOPIt may help you solve this problem. For details, refer to an article I wrote earlier.No buzzword AOP.

To sum up, we can find that the reuse of software continues to run through the development of software development technology. This article also gives a rough introduction to the complicated development technologies from this perspective, hoping to help you understand these concepts.

Recommended articles:

WS-coordinationIntroduction

WS-AddressingFrom theory to practice --- SOABasic specifications

Web Services SecuritySeries of articles

Distributed Application in. net

Postscript:

When I wrote this article, I found my foundation was too thin. I wanted to give up halfway and finally finished the stuttering. Now I think the article is getting harder and harder to write. I hope I can stick to it. I also found that most of my article readers are diving, and there is basically no interaction in comments.

Address: http://www.cnblogs.com/idior/articles/606938.html