It was not clear that I had seen this problem last night. has been used in Java and Android development, the recent maintenance of an old project, is developed with VB, code more than 10 years, contact for a period of time. The process-oriented and object-oriented aspects are involved, here this summary (some are collected online)
Own understanding of:
Process-oriented is an event-centric programming idea, function (behavior)-oriented, modular design, is to analyze the steps required to solve this problem, and then use the function of these steps step by step implementation, when the implementation of a call in turn can be
Object-oriented is a matter-centric programming idea that takes data (attributes) as a guide, abstracts objects with the same or multiple attributes as "classes", wraps them up, and with these data (attributes), we consider their behavior (how these properties are manipulated), is to break down the things that make up the problem into objects, and the object is not to complete a step, but to describe the behavior of a thing in the whole process of solving the problem. Object-oriented technology is an object-based program design technique that drives objects to run with events or messages. It is encapsulated, inherited, and polymorphic in nature.
Know the Netizen Rlei;
object-oriented programming emphasizes "encapsulation", "Inheritance" and "polymorphism". Dataand data-relatedOperationare packaged as objects (strictly referred to as "classes"), and each object is relatively complete and independent. Object can have a derived type, the derived type cancover(oroverloaded) The original existingOperation. All of this is to achieve a better CohesionThat an object does one thing (or a class of related things), the inner details of the object are not cared for or seen in the outside world;couplingThe interdependence of different kinds of objects is minimized. And all of this helps to achieve a lofty goal, which is reusability. What other people write out, you can simply use, but also to develop, this is not a very good world?
Explaining
The process is to analyze the steps required to solve this problem, and then use the function to implement these steps step by step, using a one-time call in turn. Object-oriented is the decomposition of a problem transaction into individual objects, the purpose of which is not to complete a step, but to describe the behavior of something in the whole process of solving the problem.
Process oriented
process-oriented programming is a top-down design approach, and the designer uses a main function to summarize what the application needs to do, and the main function consists of calls to a series of sub-functions. For each sub-function in main, it can be further refined into smaller functions. By repeating this process, a process-style design can be completed. Its characteristic is to function as the center, use function as the basic unit of dividing program, the data is in the subordinate position in the process design.
The advantage of process-oriented design is that it is easy to understand and grasp, so the design method of the gradual refinement problem is closer to the way of thinking of most people.
however, over-programming is often inadequate when it comes to complex problems, or when demand changes in development. This is because the design of the process is top-down, which requires the designer to have a certain understanding of the problems that need to be solved at the beginning. When the problem is more complex, it is more difficult to do so, and when demand changes in development, the understanding of the problem may become no longer applicable. In fact, the process of developing a system is often an ongoing process of understanding and learning about the system, while the process-style design approach ignores this.
in a process-oriented language, it is common to have elements that define data, such as the structure in C, and the elements that define operations, such as functions in the C language. The result is that data and operations are separated, easy leads to the operation of a data distribution throughout the entire program, and an operation may also use a very large number of data, in such cases, the data and the operation of any part of the changes will become very difficult.
In the process-oriented design, the main () function is in a very important position. The designer is in the main () function, the whole system to a general description of the narrative, and then as a starting point, gradually refine the entire application. However, one consequence of this is easy to confuse some of the more extended and variable logic (for example, user interaction) with the core logic of the program. If we write a graphical interface of the calculator program and a command line interface of the calculator program, can imagine the two version number of the main () function will be very large differences, the resulting program is very likely to be very different, and these two version number of the program should have a very large part of the can be shared.
process-oriented design Another problem is the dependency of its program architecture. A typical procedural procedure is often seen in Figure 1:
Figure 1
the arrows in the graph represent the call relationships between functions, as well as the dependencies between functions. As you can see, the main () function relies on its sub-functions, which are dependent on smaller sub-functions, while in the program, the smaller the function is often the details of the implementation, these detailed implementation, and often change. The result is that the core logic of the program depends on the details of the extension, the program should be a relatively stable core logic, but also because of dependence on the volatile parts, and become unstable, a small change in detail, it is possible to trigger a series of changes in the dependency relationship. It can be said that this kind of dependency is one of the reasons why the process design can not be changed very well, and a reasonable dependency should be reversed, which depends on the core logic for the detail realization.
Object-oriented design
Object-oriented is a bottom-up program design method. Unlike programming, you start by outlining the entire program with main, and object-oriented design tends to start with a part of the problem and build the entire program at 1.1 points. Object-oriented design takes data as the center, and class as the tool of performance data, is the basic unit of dividing program. And the function becomes the interface of the class in object-oriented design.
Object-oriented design is a bottom-up feature, and it is agreed that developers start from the local problem and deepen their understanding of the system during the development process. These new understandings, as well as the changes in demand that are encountered in development, will again work in the system development itself, creating a spiral development approach. (In this way of development, for the existing code, it is often necessary to use refactoring technology to do code refactoring to reflect the changes in the system.) )
compared to functions, data should be a more stable part of the program, for example, an online shopping program, no matter how it changes, will probably deal with goods, customers these data objects. Just here, only from an abstract point of view, the data is stable, assuming that the detailed implementation of these data objects, they are even more than the function is not stable, because in a data object to increase or decrease the field in the development of the program is the norm. Thus, at the same time as data-centric construction, we need a means to describe the narrative data in an abstract way, using functions. In object-oriented design, the class encapsulates the data, and the member function of the class as its external interface, and describes the class in an abstract way. Using classes to combine data with functions that manipulate these data can be said to be the essence of an object-oriented design approach.
There are two types of relationships between classes in object-oriented design: the customer (client) relationship and the Inheritance (inheritance) relationship. Customer relationship as seen in Figure 2, indicates that a class (client) is used to have a class (Server). The client class in such a relationship is generally referred to as the Client,server class calledServer.
Figure 2
The inheritance relationship, as seen in Figure 3, represents the inheritance of one class (child) to another class (Parent). The parent class in such a relationship is generally referred to as the parental class, and the child class is called a subclass.
Figure 3
The process of object-oriented design is to combine each class with the above two relationships, both of which are easy to combine but can provide a powerful design capability. The following describes how to use these two relationships to divide the different modules of the program.
in very many applications, we need to have dataStoreto the database. A common solution is to use a layered approach that divides the program into application layers andStorelayer, Figure 4 is a less mature design for this method:
Figure 4
application represents the logic of the application layer, and DB represents the logic of database access, in which application directly invokes the DB service to store the data in the database. The disadvantage of this is that application has a dependency on the DB, and once the DB has any changes, the application is likely to be affected by its effects and needs to be modified. Of course, assuming that there are only two classes, such a dependency is not a problem at all, however, we have reason to believe that both the application layer and the storage layer will be composed of not only one class, and all have a certain degree of complexity, then the relationship between them will cause a headache. As the modules of the program become more and more, assuming that the links between them are not limited, the dependencies between the modules, the complexity of the program, and the difficulty of developing maintenance will all rise exponentially.
Fortunately, with the introduction of object-oriented inheritance relationships, we can solve this problem, as Figure 5 sees:
Figure 5
persistence is an interface that includes the services that the application store needs. DB implements this interface, application calls the service in persistence to store the data, both of which rely solely on persistence. Thus, the application-to-db dependency is cut off by the persistence interface. The content of the persistence interface is very easy because the interface includes only services, that is, the declaration of the member function, not the implementation of whatever data and functions. In the case of persistence, the two modules of application and DB are free to change without affecting each other. In this way, by inserting the interface in the middle of the method, the module of the program is divided, and the dependency relationship becomes easy to manage more.
assuming that the design in Figure 4 is from a point of view, the application layer is the core of the program, and the storage layer can be seen as the implementation details, and the design makes the same mistake as the procedural design, where the core logic relies on detailed implementation details, so that when the details change, The core logic is also affected: if we need to change the data to a file or folder service, the design application module in Figure 4 will inevitably be affected. In the design of Figure 5, there is no problem: here we can think of application and persistence as the core logic of the program, and the implementation of the Persistence interface (DB) can be seen as the implementation of the details of the program, its dependency is the detail depends on the core, When the details change, the core will not be affected, which is a stable dependency. Following this design, we are able to add or change the storage type for the program without affecting the core of the program, as seen in Figure 6:
Figure 6
It is noteworthy here that persistence and application are divided together, because the services in persistence are based on the needs of application, The relationship between persistence and application is closer than it is to its subclasses. It is a common practice to put an interface and its callers into a module, and of course, it is possible to separate the interface into a single module, which is usually done only when there are multiple different invocation modules that depend on the interface, or when there is a need for a clearer separation between the different modules.
Object-oriented programming and process-oriented programming analysis
