Comparison between object-oriented and service-oriented

Metaphor: bridge to the unknown.-object thinking

As stated in the object thinking book, "metaphor: bridge to the unknown" can also be used as a metaphor when learning new technologies and terms, for the purpose of understanding. Why can it help us? That's because people are always familiar with things. By analogy and comparison, establishing a fast connection between new things and old things can help us understand the characteristics of new things.

 

Well, the readers in this article don't need much technical skills. They only need to use OOD for system design. Of course, if you have some knowledge about Oop, OOA, and Web Service, that's even better. If you already know so, you don't have to read it.

 

We are always changing our world, and so are our systems. So when so appears in our world, we will ask, "Is Oo obsolete ?", "So can solve the problem that OO cannot solve ?"

 

If the answer to the first question is yes and the answer to the second question is no, there is no need for so to exist. In other words, I will not introduce it to you here.

 

Okay, "Is Oo obsolete ?" First, let's look at a figure.

This figure clearly shows the features of system development using OO. That is to say, our system is formed by referencing different objects.

Okay. Let's look at another figure.

 

 

Some people will say that so is just an extension of OO, right?

If the system is truth, then Oo and so are different models of the system in the design world, because we all know that truth is three-dimensional and has different ways of presentation, each of us can see different aspects of it.

It seems that so far, I have not made any positive answers to the above questions. In fact, the answer already exists, that is, "No". OO has not been eliminated, we only take a further step towards the perception of the system, and we see the other side of the system. So is not an extension of OO, because it is like the relationship between macro-economics and micro-economics. You cannot say that the former is an abstraction of the latter, while the latter is an extension of the former.

Different people may have different opinions and impressions when they look at the same thing. For an implemented system, programmers simply see their own code as some labeled C # classes, so they insist that this is Oo; the architect will say that what I designed is in line with all the characteristics of SOA, So I insist that this is so. This is why so's cognition is so vague.

 

Through these two figures, we can clearly understand that so and OO are both a reflection of the system in software model design. Therefore, there is no problem of who will be eliminated, and they can coexist, in our system, there are both the existence of objects and services. What design and programming are oriented is a question of the philosophy of analysis and implementers.

 

Well, we know that OO will not be eliminated and the consequences will not be serious. We are very pleased.

 

So can we solve the problem that OO cannot solve ?"

For this question, let's take a look at the basic principles of so, which are boundary mandatory, self-made, contractual, and policy-based compatibility. Next we will explain it one by one.

 

Boundary mandatory

In the service world, the boundaries between each service are clear and mandatory. For a system, you can see exactly how many services are there. In addition, the service boundary is connected through messages. We can regard messages as water, services as fish, and systems as fish tanks. Each fish exists independently and is combined into a fish tank through water.

In the so system, calling across the boundaries of each service is costly and we will be very clear; but in the OO distributed system, we can treat a remote object as a local object, which may lead to excessive use of the remote object. This is like listing a shopping list at a supermarket to avoid exceeding the budget. In a general convenience store, you don't have to worry about this problem.

 

Self-made

Each service is self-made internally. That is to say, the deployment, upgrade, and modification of a service in the system will not affect the re-establishment of the entire system.

In a distributed system built by Oo, we can know that an object library is often deployed, upgraded, and modified at an atomic level. Therefore, due to high coupling, in addition, there is no clear boundary for calling between object libraries, which will lead to the re-establishment of the entire system.

How many times do you think it is difficult to maintain an existing system or write the same system?

 

Contractual

Services are delivered through an agreed outline, and data is customized through contracts. What about the OO world? It is passed through types and classes.

When a Service exchanges external information, it only tells other services, "What can I do", and "I can only do what I have already declared". That is to say, services expose data and contracts based on their own capabilities.

OO requires that the entire system type be the same, and this process is constant by type and class.

 

Policy-based compatibility

What does the policy do? It is abstracted. (Remember a classic sentence in the C ++ meditation, that is, the true power of OO lies in abstraction .) So what does it abstract? It abstracts the constraints between services and interactions. Hard to understand? For example, Why can a service interact with a traditional Web service? This is because everyone is based on the same policy.

 

So what are the advantages of so?

The biggest benefit is the loose coupling of the system, which enables elasticity and adaptability. We can think of so as a huge architecture model. It has some rules that combine the original pattern used repeatedly, let us make full use of the architecture system based on an accurate premise and a set of simple rules.

 

Now we can answer this question. So can solve the problem that OO cannot solve. From a macro perspective, we all know that so gives simpler rules to the architecture system, simplicity means less error-prone, and OO gives us an excessively free scale, which is also the reason why most existing systems are bad and messy. In a micro perspective, so is even more free of design than oo. We can put all the existing technologies and infrastructure into our solutions, you don't have to pay attention to the implementation details of the technology and infrastructure.