Deepen shallow OOD (1)
Writing / transparent
(This article is started from free electronic magazine "C View".)
There is Kundu, innate. Xiaoha! ! Independence, no change, can be heaven. I didn't know his name, the word said. I strongly, the name is big, the big arrogance, the dead, far away. Da Da, Tianda, Ground University, Wang Yizhang.
- "Morality", Chapter 25
Software is not soft
Software crisis from the 1960s, to today's traditional software engineering approach, there is a problem: Software is Hard [Martin, 95]. To be honest, the software is a hard bone, and people who truly develop software will have this feel. An app always contains countless intricate details, and software developers organize all of these details to form a procedure that can run normally, this is not a simple matter.
Why is this this? For example, the user can easily say "I want a word processing software". He thinks that "word processing software" is clear, it is clear, do not need more descriptions at all; and truly develop one Word processing software is a difficult thing - how people who have seen development word processing software have been defeated. Why is it easy to express a concept, and it is difficult to achieve a concept? Because people are too good at abstraction, they are too good to peel off the details.
Software is not soft, the crux is here: the user is easily abstract to express your needs, and this abstraction is difficult to translate into program code. Software is not soft, because very simple ideas require a lot of time to implement; software is not soft, because the needs and expectations of users are too difficult; software is not soft, because software is too easy to make users with fantasy.
On the other hand, computer hardware technology is developing rapidly. From a mysterious homonym, a mobile chip carrying it will be carried by now with a mobile chip that is running in each second. When software developers are still looking for "silver bombs" [Brooks, 95] that enhance software development and productivity, hardware development has already increased hundreds of times. Why is that?
Hardware engineers can be so efficient because they are very lazy. They will always abide by the ancient training of "Don't go to reinvent the wheel", they try to take advantage of others. Do you see hardware engineers design a dial switch? Do you see hardware engineers design low-pass filtering circuits? Do you see hardware engineers design timers? They have a very good packaging technology that they can package the circuit in a plug-in and only expose the interface. When others want to use, only the interface is used in accordance with the interface, and it is not necessary to fade the implementation inside the cardiac connector.
What about software engineers? Before STL became a C standard (even after), each C programmer wrote its own sort algorithm and linked list, and thought it was better than others ... it is a sad.
OOD can make the software "soft"
The software is not soft, but OOD can help it "soft" a little. OOD provides us with tools that encapsulate features and complexity on a level. Using OOD, we can create a blackbox software module that hides a lot of complicated things behind a simple interface. The software engineers can then use standard software technology to combine these blackboxes to form the applications they want.
Grady Booch refers to these blackboxes as class category, and now we usually call them "Component". Class belongings are composed of entities called class (Class), and the classes are combined between the class and classes. A class can hide a lot of details, only a simple interface, which is in line with people like abstract psychology. So, this is a great concept because it gives us the foundation for packaging and reuse, allowing us to see questions from the perspective of the problem, not from the perspective of the machine. The software is initially started from the function library and class library. These two multiplexed forms are actually white boxes. By the 1990s, some people began to develop and sold the real black box software module: Framework and Control. Framers and controls are often limited by platforms and languages. Now the new trend of software technology is a Web Service using SOAP as a transmission medium, which allows the software module to detach from the binding of the platform and language to achieve higher degrees. But thinking about it, in fact, Web Service is also object-oriented, but it is intended to describe the association between classes and classes [li, 02]. In the past decade, object-oriented technology has played greatly in the software industry. In the future, it will still be the main technology of software design - at least I can't see what technology can replace it.
Above, I introduced some background knowledge to the reader, and I also introduced the benefits of OOD. Below, I will answer a few common questions, I hope to make readers to see the outline of OOD.
What is OOD?
Object-oriented Design, OOD is a software design method and is an engineering specification. There is no doubt about this. According to Bjarne Stroustrup, object-oriented programming paradigm (paradigm) is [Stroustrup, 97]:
l Determine the class you want;
l Provide a complete set of operations for each class;
l Explicitly use inheritance to express common.
From this definition, we can see that OOD is "The process of deciding the desired class, class operation, and class between the class."
The goal of OOD is to manage interdependence of each part of the program. In order to achieve this goal, the OOD requires the program into a block, and the size of each block should be small to the level of management, and then hide each block behind the interface, allowing them to communicate with each other through the interface. For example, if you use an OOD method to design a server-client-server application, you should not have direct dependence between the server and the client, but should let the server interface and the client interface interdependence.
This conversion of this dependency makes the part of the system have a reusable. Still taking the above example, the client does not have to rely on a specific server, so you can reuse in other environments. If you want to multiplex a block, just implement a must-have interface.
OOD is a design paradigm (Paradigm), an abstract paradigm. Using OOD This design paradigm, we can use the object (Object) to express the entity of the problem, each object has the corresponding status and behavior. We just said: OOD is an abstract paradigm. Abstractions can be divided into many levels, from very summary to very special, and objects may be at any abstraction level. In addition, the objects that are different but interposed therefrom can be shared together: as long as there is similarity between these objects, they can be processed as the objects of the same class. Where is OOD?
Many people think that: OOD is an extension of structured design (SD), in fact, this is wrong. OOD software design concept and SD are completely different. The SD focuses on the process of data structure and processing data structure. In the OOD, the processes and data structures are hidden by objects, both almost unrelated to each other. However, trace the source, OOD and SD have a very deep origin.
Around 1967, the concept of OOD and SD was almost born at the same time, and they showed data structures and algorithms in different ways. At that time, many scientists wrote a lot of papers around these two concepts. Among them, some papers written by Dijkstra and Hoare have talked about the topic of "appropriate program control structure", claiming that the GOTO statement is harmful, and should be used in sequence, cycle, and branch to form the entire program process. These concepts have constitute a structural programming method; other papers written by OLE-Johan DAHL mainly discuss the unit division in the programming language, one of which is class, which already has an object-oriented program design. The main feature.
These two concepts immediately brought together. In the historical manager of structured, everyone is very familiar: NATO session adopts Dijkstra's idea, and the entire software industry agrees that the GOTO statement is indeed harmful, structured method, and the waterfall model began in the 1970s. At the same time, countless scientists and software engineers also help structured methods continue to develop, and there are many names that are enough to make us oscillated, such as Constantine, Yourdon, Demarco, and Dijkstra. Have a long time, the whole world believes that the structured method is to save the "silver bomb" of the software industry. Of course, the time finally proved everything.
At this point, object-oriented is slowly developed in research and education. Structured programming is almost over any programming language, while object-oriented programming requires language support [1], which also hinders the development of object-oriented technology. In fact, in the late 1960s, the language-oriented characteristic language is only SIMULA-67. By the 1970s, the Alan Key et al. In the Schlesparo Alto Research Center (PARC) has also invented another language-oriented method, that is, a famous SmallTalk. However, until the mid-1980s, SmallTalk and other object-oriented languages are still only stayed in the laboratory.
By the 1990s, OOD suddenly became popular throughout the software industry, which is definitely a revolution in the history of software development. However, it is possible to look far, and new things are always on the basis of old things. The design methods in the 1970s and 1980s revealed many valuable concepts, no one can also ignore them, OOD is the same.
What is the difference between OOD and traditional methods?
Remember structured design methods? The program is divided into many modules that are organized into a tree structure. The root of this tree is the main module, and the leaves are tool modules and lowest function modules. At the same time, this tree also means calling structure: Each module calls its own direct subordinate module and is called by its own direct superior module. So, which module is responsible for collecting the most important strategies of applications? Of course, the top of the top. Those modules under the bottom only take the smallest detail, the top modules care about the largest problem. Therefore, in this architecture, the higher the concept of the abstraction, the closer the problem; the lower the position in the architecture, the more close to the details, the less related to the problem, and the solution The more relationships in the field.
However, since the above modules need to call the following modules, these modules above depend on the details below. In other words, abstraction related to the problem area is dependent on the details of the problem! This means that when the details change, the abstraction will be affected. Moreover, if we want to reuse an abstract, you must drag it with the details of it.
In OOD, we hope to reverse this dependency: The abstraction we created does not depend on any details, while the details are highly dependent on the abstraction above. This dependency is inversely the fundamental difference between OOD and traditional technology, and is the essence of OOD thinking.
What can ood bring to me?
Ask the person, the brain is usually thinking "OOD can solve all design problems?" No silver bomb. OOD is not solving all design problems, avoiding software crises, defending the world's peace ... OOD is just a technology. However, it is an excellent technology that can solve the current most software design issues - of course, this requires that the designer has sufficient ability.
OOD may make you headache, because you have to learn it, master it is very difficult; OOD will even disappoint you, because it is not mature, is not perfect. OOD will also bring you delight, it allows you to focus on design, don't have to worry about those fine branches; OOD will make you a better designer, it can provide you very good tool, let you develop Software that is more robust, more secure, and more reused.
C is a "real" object-oriented programming language?
The last question and our topic today are not big, but this is a long-awaited issue, and it will not have a suitable opportunity to explain this problem in the future, so I will answer today.
Many people think that C lacks some of the "true" object-oriented language, such as garbage collection, multiple-dispatch. However, the lack of these features does not affect developers with C to implement object-oriented design ideas.
In my opinion, any language, as long as it directly supports the implementation of object-oriented design, it is "true" object-oriented language. Use this standard to evaluate, C is fully compliant: it directly supports inheritance, polymorphism, packaging, and abstraction, which is the most important thing for object-oriented. The language of VB and C cannot be directly supported (although it can be implemented with special skills), it is not "real" object-oriented language.
bibliography
L [Brooks, 95] Frederick Brooks, The Mythical Man-Month, Addison-Wesley, 1995.
L [Li, 02] Li Wei, "Delphi 6 / Kylix 2 SOAP / Web Service Programming", Machinery Industry Press, 2002. l [Martin, 95] Robert Martin, Designing Object-Oriented C Applications Using The Booch Method, Prentice-Hall, 1995.
L [Stroustrup, 97] Bjarne Stroustrup, The C Programming Language (Special Edition), Addison-Wesley, 1997.
[1] I heard someone saying "I can use C language to be object-oriented", but I hope you will not say "I also like this." Obviously, if there is no support for the language characteristics, the object-oriented method will be difficult. In fact, structured design is also the same, but almost all programming languages provide support for three basic process structures, so it will not encounter this problem.
