Object-oriented design has a point that everyone has basically formed a consensus, that is, interface programming, I think most people on this is nothing to suspect.
The question is how we embody it in the actual project development. Does it mean that every implementation provides an interface. Conversely, you sometimes feel that the interface is superfluous. Or, you just think that a framework like spring is already used to having interfaces that way, of course.
In the design pattern parsing, several viewpoints are mentioned in object-oriented design, one is the concept layer, the other is the protocol layer and the other is the implementation layer. If I'm not mistaken, in fact most of our eyes have been staring at the implementation layer, and that's what object-oriented design is trying to avoid--you don't have to focus on these details from the start, you're looking at the protocol.
For actual project development, if we divide the process of implementation into several stages, we might as well division, the first phase, according to the needs of the client side to design our statute (interface), at this stage any implementation is not, all tasks is to define the responsibilities of the interface, As well as some of the po,vo needed; the second phase, the implementation of the previously defined statute.
How I used to do it. I am a cross, that is, a dummy template definition of an interface (in fact, I think this thing has fart), then define a method, and then immediately to implement this method, and then I define a method, continue to implement, I now finally figured out, so tired, inefficient, most importantly, This does not belong to the real design.
Now, how do I do that? Like a list.jsp need to query, list, then look at the details, then add the information, I will first step in the interface defined (this process will have the overall design consciousness), do not care about the underlying implementation (database, transaction), my goal is "I want this function, I want that function", As to how that function can be achieved in the first stage I don't think it's my business (though it's ultimately up to me). What is the nature of the process and the previous process? Is that the concept of layering is more obvious, your work is more level, each time there is a first design and implementation of the steps, and the previous process is easy to let you unknowingly into a pure realization of the trap.
what is interface-oriented programming。
In an object-oriented system, the various functions of the system are performed by many different objects. In this case, how to achieve within each object is not so important to the system designers, and the collaboration between the objects is the key to the system design. Small to different classes of communication, large to the interaction between the modules, at the beginning of the system design are to be considered, this is the main work of the system design. Interface-oriented programming I think is to follow the idea of programming it. In fact, in the daily work, you have been programmed according to the interface, but if you do not have this awareness, then you are only in the passive realization of this idea; the frequent complaining that the other person changed the code affected you (the interface is not designed to), Changes in one module result in large-scale adjustments of other modules (module interfaces are not well designed) and so on.
Mr. Booch, speaking of interaction Designer that day, refers to people who do this kind of design, but at a higher level. I think at present in our software design team, this kind of person is one of the most lacking talents.
non-interface programming. is the process-oriented programming idea.
1. Understanding of Interfaces
Interface from a deeper level of understanding, should be defined (norms, constraints) and implementation (the principle of separation of the principles).
When we implement a system in general, the definition and implementation are usually integrated, without separation, I think the most understood system design specification should be the separation of all definitions and implementations, although this may be a bit annoying in some cases of the system.
The interface itself reflects the system designer's abstract understanding of the system.
Interfaces should have two classes:
The first class is an abstraction of a body, which corresponds to an abstract body (abstract class);
The second type is the abstraction of one aspect of a body, i.e. the formation of an abstract plane (interface);
It is possible for a body to have multiple abstract faces.
There is a difference between an abstract body and an abstract surface.
2. Another important factor in designing interfaces is the environment in which interfaces are (context,environment), and the view of the system theory: the environment is the sum of the space and the external influence factors of the system elements. Any interface is generated in a certain environment. Therefore, the definition of the environment and the impact of the environment on the interface can not be ignored, from the original environment, all the interface will lose its original meaning.
3. According to the module development model (3C), the three of them complement each other, each division, seamless, indispensable.
Object-oriented means that when we consider a problem, we consider its attributes and methods in the object unit.
Process oriented refers to the implementation of a specific process (transaction process) that we consider when considering a problem.
interface design and non-interface design are for reuse technology, and object oriented (process) is not a problem
I think: the interface in UML is another way of saying the agreement. does not refer to COM's Interface,corba Interface,java Interface,delphi interface, Man-machine interface interface or NIC interface.
In the concrete implementation, it is possible to realize the interface of UML as the interface of language, the interface of distributed object environment or other interface, but in terms of understanding the interface of UML, it refers to the realization and implementation of each part of the system. Work together through the agreements established by interface.
So I think, oriented to interface programming, the intention is to refer to the abstract protocol programming, the implementation of the implementation should be strictly in accordance with the agreement to do. That is what Comrade Billjoy said, while turning to the RfC, while writing the meaning of the code. Object-oriented programming refers to abstraction and representational. Abstract and representational are contradictory unity, which cannot be only abstract without a representational. People who are generally aware of abstractions understand this truth. But some people only know the image but do not know what the abstract thing.
So only interface is not implemented, or only implemented without interface is useless, anti-oo.
So it's still an honest object-oriented programming, protocol-oriented programming, or anything that is not oriented, honest programming.
But I hate to discuss such terminology, so let's talk about what is called leadership-oriented programming. User-oriented programming. Leaders and users are sometimes very BT, we are oriented to BT programming.
choose Java Interface or abstract class。
Many people have the question of why some places have to use interfaces rather than abstract classes, while in others they must use abstract classes instead of interfaces. Or, when considering the generalization of Java classes, many people hesitate between interfaces and abstract classes, or even pick one.
In fact, the choice of interfaces and abstract classes is not arbitrary. Two concepts are important to understand the selection principles of interfaces and abstract classes: the behavior of objects and the implementation of objects. If an entity can have multiple implementations, the goal is to design the description of the entity behavior in such a way that when you use an entity, you do not need to be aware of how the entity behavior is implemented. In other words, the object's behavior and the object's implementation are separated. Since both Java interfaces and abstract classes can define methods that do not provide a specific implementation, should the interface or abstract class be used when detaching the object's behavior and the object's implementation?
In the choice of interfaces and abstract classes, one principle must be observed: The behavior model should always be defined through interfaces rather than abstract classes. To illustrate the reason, try building a behavioral model from an abstract class to see what happens.
Suppose you want to design a software for the sales department that contains an "engine" (motor) entity. It is clear that there is no detailed description of the engine in the engine object, but only some of the features that are important to the current software. As to which features of the engine are important, it is necessary to communicate with the user (Sales department) to determine.
The sales department requires each engine to have a parameter called horsepower. For them, this is the only argument worth caring about. Based on this judgment, the behavior of the engine can be defined as the following behavior.
Action 1: Check the horsepower of the engine, the engine will return an integer indicating horsepower.
Although it is not clear how the engine gets the horsepower parameter, it is certain that the engine must support this behavior, and that this is the only behavioral trait that all engines deserve to be concerned about. This behavior feature can be defined either by an interface or by an abstract class. To illustrate possible problems with an abstract class definition, use the abstract class to build the engine's behavior model, and describe behavior 1 in Java, with the following code:
Code
Public abstract motor{
Abstract public int gethorsepower ();
}
On the basis of the motor abstract class to build a variety of concrete implementation, such as a-type engine, B-type engine, and other parts of the system, the final 1.0 version of the software and delivery. It's been a while now to design the 2.0 version of the software. In assessing the requirements of version 2.0 software, a small number of engines were found to be battery-powered while batteries required a certain charge time. People in the sales department want to be able to check the charging time through the computer. Define a new behavior based on this requirement, as shown in Figure 1.
Action 2: Inquire the charging time of the electric drive engine, the engine will return an integer indicating the charging time.
Use the Java method to describe this behavior, the code is as follows:
Code
Public abstract Batterypoweredmotor extends motor{
Abstract public int gettimetorecharge ();
}
In the sales department's software, electric drive engines are also implemented as classes, but these classes derive from Batterypoweredmotor rather than by motor. The sales department was satisfied with the changes added to the version 2.0 software. With the continuous development of the business, the light-driven engine appeared soon thereafter. The sales department requires that light-driven engines need a certain amount of energy to operate, and that energy is measured in lumen (Lumen). This information is important to customers because some light-driven engines may not function in rainy or cloudy weather. The sales department requires that the software increase support for the light drive engine, so define a new behavior.
Action 3: Query the minimum lumen required for the light-driven engine to function properly, and the engine returns an integer.
To define an abstract class and convert behavior 3 to a Java method, the code is as follows:
Code
Public abstract Solarpoweredmotor extends motor{
Abstract public int getlumenstooperate ();
}
As shown in Figure 1, both Solarpoweredmotor and batterypoweredmotor derive from the motor abstract class. Throughout the software, more than 90% of the code treats all engines in the same way. Occasionally need to check whether the engine is light drive or electric drive, using instanceof implementation, the code is as follows:
Code
if (instanceof Solarpoweredmotor) {...}
if (instanceof Batterypoweredmotor) {...}
Regardless of the engine, the horsepower parameter is important, so the Gethorsepower () method works in all derived abstract classes (Solarpoweredmotor and Batterypoweredmotor).
Now the sales department has a new engine, which is a dual-drive engine with both electric and light drives. There is no change in the behavior of the light and electric drive, but the new engine supports both behaviors. When considering how to define a new photoelectric-driven engine, the difference between the interface and the abstract class begins to show. The new goal is to change the code as little as possible while adding new engines. Because the code related to the light drive engine and the electric drive engine has been thoroughly tested, there are no known bugs. In order to increase the photoelectric drive engine, a new solarbatterypowered abstract class is defined. If solarbatterypowered is derived from the motor abstract class, solarbatterypowered will not support instanceof operations for light-driven and electrically driven engines. That is, if a photoelectric-driven engine is driven by light or electrically driven, the answer is: none.
If you let solarbatterypowered derive from Solarpoweredmotor (or batterypoweredmotor) abstract classes, similar problems can occur, Solarbatterypowered will not support instanceof operations for Batterypoweredmotor (or solarpoweredmotor). From a behavioral perspective, the photovoltaic engine must be derived from two abstract classes at the same time, but the Java language does not allow multiple inheritance. The fundamental reason for this problem is that using an abstract class means not only defining a specific behavior, but also defining the pattern of implementation. That is, you should define a model of how an engine obtains behavior, not just a statement that the engine has a certain behavior.
If you use interfaces to establish behavioral models, you can avoid implicitly setting the implementation pattern. For example, the preceding few behaviors are defined as follows by using interfaces.
Behavior 1:
Code
public interface Motor () {
public int gethorsepower ();
}
Behavior 2:
Code
Public interface Batterypoweredmotor extends Motor () {
public int gettimetorecharge ();
}
Behavior 3:
Code
Public interface Solarpoweredmotor extends motor{
Abstract public int getlumenstooperate ();
}
Now the photoelectric-driven engine can be described as:
Code
Public Dualpoweredmotor implements Solarpoweredmotor, batterypoweredmotor{}
Dualpoweredmotor only inherits the behavior definition, not the implementation pattern of the behavior, as shown in Figure 2.
An abstract class can still be used while using an interface, but the function of an abstract class is to implement the behavior rather than define the behavior. As long as the class that implements the behavior complies with the interface definition, even if it changes the parent abstract class, it does not change the way other code interacts with it. Abstract classes have its advantages, especially for common implementation code. Abstract classes can guarantee the hierarchical relationship of implementation and avoid code duplication. However, even in situations where abstract classes are used, the principle of defining behavior models through interfaces is not overlooked. From a practical point of view, if you rely on abstract classes to define behavior, often lead to overly complex inheritance relationships, and through interface definition behavior can be more effective separation of behavior and implementation, for the maintenance and modification of code to bring convenience.
Java interface features learning
When you see an interface in Java, the first thought might be multiple inheritance in C + + and another keyword abstract in java. Implementing multiple inheritance from another perspective is one of the functions of an interface that allows objects in Java to be transformed upwards into multiple base types, and as an abstract class prevents others from creating objects of that class because the interface does not allow the creation of objects.
The interface keyword is used to declare an interface, it can produce a completely abstract class, and does not provide any concrete implementations. The characteristics of the interface are as follows:
1. Methods in an interface can have parameter lists and return types, but not any method bodies.
2. An interface can contain fields, but it is implicitly declared static and final.
3. The fields in the interface are stored only in the static storage area of the interface, not within the interface.
4. Methods in an interface can be declared public or undeclared, but the results are handled according to the public type.
5. When implementing an interface, a defined method needs to be declared as a public type, otherwise the default access type is not allowed by the Java compiler.
6. If all the methods in the interface are not implemented, then the creation is still an interface.
7. Extending an interface to generate new interfaces should use keyword extends to implement an interface using implements.
Interface is similar in some places to abstract, but in which way it is declared that the class mainly refers to the following two points:
1. If you want to create a base class with no method definitions and member variables, you should select an interface instead of an abstract class.
2. If you know that a class should be a base class, the first choice should be to make it an interface, and you should select an abstract class only if you have to have method definitions and member variables. Because one or more implemented methods are allowed in an abstract class, the class is still an abstract class as long as the method is not fully implemented.
These are the basic features of the interface and the application of the domain, but the interface is not only so, in the Java syntax structure, the interface can be nested, can be nested by a class, can also be nested by the interface. This may not apply much in actual development, but it is also one of its characteristics. Note that when implementing an interface, you do not need to implement any interfaces that are nested within it, and a private interface cannot be implemented outside of the class that defines it.
Reprint: http://blog.chinaunix.net/u/25176/showart_429060.html
