interface-oriented design and programming--(object oriented, interface oriented, process oriented, implementation oriented)--reprint

Introduction-position in the design pattern where the interface is oriented.

In fact, I think one of the reasons java/c# is superior to C + + is that it supports interface-oriented programming. Don't misunderstand, not that C + + does not support interface-oriented programming, but that there is no such natural mechanism in C + + syntax.

Object oriented to process oriented, interface oriented to implementation oriented. But basically, interface-oriented and implementation-oriented are based on object-oriented patterns, which means that interface-oriented is not called a higher-object-oriented programming model. But in the object-oriented context of a more reasonable software design pattern, it enhances the class and class, module and module of the low coupling between the software system is easier to maintain, expand.

Whatever it is, it is a software design pattern that has little to do with the specific language.

As in the previous introduction of C language, not to say that the C language of the process-oriented language can not do object-oriented programming, but that the C language was originally designed not for the object-oriented software system style and design. Due to the popularity of the later object-oriented software design style, later language c++/java/c# have fully considered the support of object-oriented convenience in language design, so these languages are called object-oriented programming languages.

Based on the theory that there is no capacity between languages, C is capable of object-oriented programming (which is practical).

The above theory is also suitable for discussing--c++ programming for interfaces.

interface-oriented Software design is not available in Java or C # after the interface keyword appears. Or that sentence, it is a software design pattern, regardless of the specific language, C + + or C can and also use a lot of this programming mode. And just because of the advantages of this model, Java and C # are based on C + + and are designed to support interface-oriented programming (the concept of a language-level interface presented inside).

The concept of two kinds of interface

This requires understanding the interface at the language (java/c#) level, and interface at the software design level. It can be said that the existing software design of the interface concept, and then those "after" language, in order to fully support the software design (after all, the design eventually to be implemented in language), and added the "interface" the keyword and its related concepts. That is, even if java/c# does not use the interface technology that comes with their language, it can also be programming for interfaces (you might know-using abstract classes). So to speak, the two interfaces do not belong to the same level of things, should not be compared, but must be compared, it can be considered that the interface concept of software design than the language level of the interface concept is greater.

What is the meaning of interface-oriented (design) programming and what is the benefit of it?

(1) Speaking the text to solve the word

The word "oriented" is widely used in software design programming. But it seems that we do not quite understand what it means. As the "Object-oriented" word is in front of us, we also need to have a deep analysis of the word "interface oriented".

The difference between "object" and "data" is that "object is the carrier of information and method of processing information, and data is only the carrier of information", and the key meaning of the word "oriented" is that when we design a system and implement a system, we are based on, what design and programming goals. For process design and programming, designers and programmers are often confronted with and able to use only a few variables when designing and programming. and object-oriented, they are faced with some objects, can be said to be some living objects.

For example, you have to control a person programmatically.

For process programming, you are just a person's information body (struct), the information body contains a complete description of a person's various "static information" data, such as name, gender, age, weight, appearance and so on, if you want to control a person, let him say a word "How are you?" Then you need to design a function or a process to invoke the human body of the person, and then let him speak (in fact, it is equal to know if a person sends out that sentence). This is a very painful thing, and we want the programmer or this is the designer is facing a living person, this person is talking, it does not need us to call him how and talk, we have to let it speak only to the content of the word to him, and he will say it. This is the person's "dynamic message."

Object-oriented is to provide the programmer with a complete object that includes static information and dynamic information. The programmer does not have to spend time on the implementation of certain actions of the individual. Just like an animal breeder, different animals eat their own meals, and the animal keepers just need to give different animals the same food, provided that the animal is self-eating this action. This is the most basic concept of object-oriented-an object that is provided to a designer or programmer, a whole that contains information about the individual's static (data) and dynamic (methods of processing data).

With the above concept, we can first determine what the "face" is, in fact, his literal meaning, is that when the designer or programmer to work, they do face a what?

(2) explanation begins

Implementation-oriented, that is, when object-oriented programming, when we want to control the object of a class, then we will directly in the current program (itself Class), instantiate the class, and then call the corresponding method through the class. This is one of the most basic object-oriented programming patterns.

Some people say, is this a problem? Isn't this the object-oriented design approach we're accustomed to? To use an object, like instantiating it and then invoking it, this pattern also does a relatively good low-coupling. You call the object, and if the implementation has changed, you basically don't need to show what the repair

Change. But on one issue, it's hard to solve.

(3) Difficult to solve problems

Animal keepers feed three species of animals (chickens, ducks, geese) and only use the implementation-oriented method described above to instantiate the animals separately and then invoke the "eat" method of those animals. For those animals how many times these things, is their own, the breeder does not need to tube, so the breeder's program is basically stable, which is the object-oriented advantages. (The number of animals is not a problem, the key is that the breeder mastered three kinds of animal classes, instantiate them, call them just an iterative process).

However, if at this time, the zoo's new arrangement of an animal (dog), to feed the breeder, dog this animal class has been done, no keeper tube, anyway, this animal must be mouth food is (breeder may know how to breed). However, at this point, you need to modify the class of the Breeder's object, adding a way to instantiate the dog and call the dog to eat food.

This is a problem, and our ideal state is that the zoo Pity Dorado Things (to join the dogs) and then to the breeder, and this time because of the addition of some dogs, we need to retrain the breeder (update his code), which we do not want. This also shows that this mode design method does not achieve very good low coupling. This is also common object-oriented design and programming methods cannot be done.

(4) Analysis of problems

The way to solve the above problems requires us to rethink the problem-oriented. The idea that we are talking about implementing this concept for the moment is that, in the thought of the above design programming, the breeder, directly oriented, is the animals that it wants to breed (and treat different animals differently). In fact, the breeder basically does not need to be treated differently. Because all kinds of animals eat the details (to achieve) is not your control at all. So in this case, as a general experimenter, why should you treat different animals differently?

In other words, the better condition we want is that the keepers just know that they are animals and have the right to eat. If the breeder is trained according to that pattern, then the zoo randomly arranges new species, or falls off new species, and the code on the breeder's side is completely motionless, which makes it a low-coupling.

(5) Initial settlement (design)

So how do you achieve the above goal?

We know that the breeder was facing different kinds of animals, and now we just need to make him face the animals. What do you mean? A layer more abstract. So we need how to achieve, that is inheritance! In other words, we need to have them inherit the higher class of "animals" when designing each animal. And you have to use polymorphic techniques.

That is, according to the polymorphic view, if the breeder gets a pointer to a group of animals given to it by the zoo (the base-class pointer), the pointer may have multiple animals (derived class pointers) that the breeder can use to invoke the animal's eating action. This is also required that each animal must obey the inheritance from the base class and overwrite a virtual function, so that the breeder, through the animal pointer calls the eating function, will be dynamically bound to each animal up. And this breeder is completely unnecessary to know. When the zoo is programmed (managed) by the keeper, the thing passed to the keeper is only the hands of the animals. So as long as the animals that are added later are based on animals, the breeder does not have to update anything at all!

What do you think is the programming, or do you think, what this breeder is facing? Object? Yes, it is still, but it is a more abstract object (animal), and because it is more image-oriented, it leads to the fact that the outside world does not need to change his changes.

(This can also be similar to our study, if you are learning something too specific, when the new similar things appear, you have to learn that thing, if you learn the more abstract basic, general principle, when new similar things appear, you apply is, this is "a pass Wantong", The key is that the first pass is on the general principle, the back pass is pass in a variety of similar specific knowledge)

Why don't we call it "base-oriented programming"? Because the pattern described above, it seems, is to target more abstract base class programming. Yes, this is true, and the basic idea of this programming model is also spoken. However, when we need to solve another problem, this argument does not have a wide range of adaptability.

(6) Further questions:

Or the front of the zoo for the background. Now join the quarantine officer in this role (class). This class of objects need to quarantine zoo animals, different animals have different quarantine methods, but this specific action content, included in the various animals inside, that is, you can imagine that, when the quarantine, pick up an animal, the quarantine officer is in accordance with the animal information carried on the relevant quarantine information, quarantine. So, there is not much difference between this quarantine officer and the breeder, the key is that the breeder calls "eat" the operation, while the quarantine officer calls "quarantine" this action.

According to the previous programming model, "Animals" should include at least "eat" and "quarantine" two functions, (although both functions may not have actual content, but they have a lot of functions). As a result, the quarantine officer also achieves the low coupling in the system as the breeder.

However, you will find that the breeder is facing the "animal", the quarantine agent is also "animal", but not some problems? In fact, the quarantine and the keepers are concerned about the aspects of the animals are different (although they do not care about what animal), the keeper only cares about the animal "eat" this aspect, and the quarantine officer only cares about the animal "quarantine" this aspect.

(7) Further analysis of the problem

Someone would ask, is there a problem with this? Theoretically speaking, as long as the zoo strict management, to the keepers of strict training, is not much problem, but afraid of fear in, the keeper to the animal quarantine, quarantine officers to animal food. Why is that? Why do you keep the whole "animal" out of the way, that is to say, you do not discriminate between the two roles. Another bad question is, when programming to the quarantine, if the animal class is too complex (including too many methods and properties), it will be difficult to program, if, to the quarantine is only one it can focus on and need to call the animal part of the use, then programming is convenient. And will not let the inspectors call the "eat" This method, which is an "isolation", but also a security measure.

Maybe now some people are a little hazy. The previous thought that object-oriented (concrete object) programming is not good, think that the base class (abstract) programming can reduce the coupling, now seems to need to be specific. In fact, the two must not be contradictory. The former classify individual animals as "animals" and then break down "animals" into different aspects. The two are not contradictory at all.

(8) Problem solving

So how do we solve this problem?

(9) Base class and interface (lead depth)

This reminds us of two concepts in modern programming. base classes and interfaces. Their common feature is to allow derived classes to inherit or implement (which can be understood temporarily as a meaning). From a grammatical structure, the structure of the base class and interface is very similar, so what is the difference between them? The base class can only be single-inherited, and interfaces may be multi-implemented. Why is this rule?

This is what we want to understand in nature, which usually belongs to only one class. This means that chickens are animals and should not belong to other classes.

This practice and is unreasonable. Be aware that in the context of this practice, a class can inherit only one class.

Let's take a look at the different kinds of things that have the same attributes, whether we can classify them more with these attributes?

People and animals are not a class (although also), but people and animals have "eat" and "sleep" such attributes, then whether people and animals can be categorized as "eat", Can "sleep" it? That's right! It can be so divided, but it is fundamentally different from the usual distribution. Expression in addition to an "I ' m is ..." And the difference between "I have ...". In order to differentiate between the two, in the software design industry there are different concepts of class and interface, and in the "emerging" programming language Java and C #, but also on the display of both the distinction (syntactically defined).

Let's take a look at the animals in the zoo. They should all belong to a class of "animals" but they have a lot of things that are common, and these things are not unique to them, and people can have, for example, "eat", "Sleep", "quarantine" (although not usually said) and so on. More correct design method, and should let "eat", "sleep" These things belong to "animals", and for people, and new definition of similar concepts. This does not conform to the nature and characteristics. And should be, for these "eat", "sleep" what, should be defined independently, and then, the animal can inherit it, people can inherit it, but the animals and people are not the same (don't tangle, although they are similar). In this way you find that things in nature are not related to the tree structure that we had before, but rather to a different aspect of something that has many subordinate connections. So our ability to describe nature is richer. The difference between java/c# and C + + is that they differ strictly from the base class and interface that we introduced earlier. 、

Comparison of abstract classes and interfaces

So while we're usually comparing "interfaces" to "abstract classes", in fact they don't belong to the same level, so to speak, we have the concept of class, but we divide the class into "unique classes" and "interfaces" (which makes a difference in a backward language), and then, at first, C + + has only the concept of class , but this class concept contains the concepts of classes and interfaces later in Java. The initial meaning of the existence of abstract classes (classes with pure virtual functions) is that you do not want to instantiate a class that does not represent anything. In fact, in the process of C + + interface oriented, object-oriented programming, it is not possible to use the concept of abstract classes. interface because of a special class separated from the class, it is responsible for the method of inheriting its class, it is because of this special role of the interface, so that it does not semantically need to implement the method, this, in Java and C #, was nailed to death. In C + +, there is no such provision, but it is advisable to do so.

(10) Back to our zoo--a comprehensive solution to the problem

When we define, we should first define "eat" this class (C + + syntactic meaning of the class, in fact, is involved in the meaning of the interface, the inside of the eat, is defined as pure virtual function, or ordinary virtual functions are not indifferent, but must be virtual function, which is the advantage of Java, otherwise it can not appear polymorphic characteristics, The front is no more.) It is also necessary to define the category "Quarantine" accordingly. We now have to say that he is an interface (in C + +, only the interface in his design sense).

Then, define the "Animal" class, which contains the "animal" characteristics of information, but also to inherit the "eat" and "quarantine" two interfaces. Such a complete animal definition (relatively intact) appears.

We know that chickens, ducks, geese, and dogs are to inherit the category of "animals".

Now program The breeder:

Do we also use "animals" as something he faces? Naturally not, we use "eat" as his face, because whether it is C + +, or C#/java. They all guarantee the interface and the base class in this aspect of the characteristics, so, using "eat" as the object to achieve the polymorphism we want to achieve is syntactically feasible.

Similarly, when you program a quarantine officer, use "quarantine" as a face-oriented thing.

In doing so, it guarantees a low coupling between the breeder and the quarantine and the system, while also ensuring that their respective functions do what they do. It can be said to be almost perfect.

Summarize

Now we're looking at what design patterns we've used. Yes, interface-oriented, the experimenter and the quarantine agent when programming, is interface-oriented. So this is how interface-oriented programming comes in. The implementation of this approach is basically due to the fact that it is a relative programming method that appears after the interface has been oriented. It doesn't make much sense.

From what we call the zoo example, it seems that interface-oriented is a bit more than object-oriented, but it's just a little optimization under the actual pattern of object-oriented genius. Therefore, it cannot be said that interface-oriented is a more advanced design pattern than object-oriented.

The core meaning of interface-oriented is that when programming, it is not directly oriented to the object you want to control (ordinary object-oriented), but by leveraging the function of inheritance and polymorphism, and facing a more abstract thing. This reduces the coupling between the modules and improves code reuse. In this paper, the concept of "interface" is extracted in the near-step, and on this basis, the coupling degree of the module is reduced, and the module's uniqueness is improved. This is interface-oriented programming. (In fact, to understand its core, it can be called a base-oriented programming).

We found that the "animal" kind of eating action, is not what content, because the animal is an abstract thing, do not want chickens, ducks and so on, they eat the action can be specific. Therefore, the animal must eat the action to have, otherwise: from the management, you can not unify all the specific animals to eat the external interface; programming you also can't get the compiler to pass the breeder's program because it can't be referenced by the "animal" pointer.

So "eat" this action, in the "Animal" category, at most, there are some common content.

interface-oriented design and programming--(object oriented, interface oriented, process oriented, implementation oriented)--reprint