[Translator's Note] The evaluation of Eric Raymond is translated in front of how many major development languages.
A warm discussion of netizens caught netizens. Among them, Eric raymond's batch of OO
Comment on, causing everyone's dispute. For this reason, I translate his related text, please
Everyone reading thinking.
Modularity - Keep It Clean, Keep It Simple programmers have become increasing, and the method of dividing the code also has a natural development process. At first, the software is just a large machine code. The earliest processes have brought the concept of "divided according to subroutines", and we will invented the library to provide public services for different programs. Then we have invented the independent address space and inter-process communication. Today, we have been usually distributed on the interconnected interconnects that are separated from each other. Early developers of UNIX also are the pioneer of software modular thinking. Before they, the modularity is only the idea of computer science, is not the practice of engineering. Its Gong is: to develop the unique way to develop complex software that can work correctly, use a well-defined interface to connect many simple modules to form the entire system. Only in this way, most of the local problems may be corrected or optimized on topically, not to destroy the whole. Today all programmers are educated to modularize at the level of the subroutine. Some luckyers have mastered the modularity of the Abstract Data Type (ADT), which has been considered a good designer. Today's design mode is hoping to increase this level and find out the successful design of a good organization that helps a large structure of the program. The first important qualities of the encapsulation and best module volume module code are packaged. A good package is never exposed to each other. They do not peek the implementation of other modules, and share global data without causing, but communicate with each other through the API. The API between the modules has a double identity. In the realization level, the connection point between the API function leads the module, prevents internal information leakage. At the design level, the API actually defines your system architecture. The more detailed the module, the smaller the module, the more important the definition of the API. The overall complexity, the possibility of errors also decreases. However, if the decomposition is excessive, it will be unexpected. The following figure is from Hatton 1997 statistics. It can be seen that the graph is U-shaped. Hatton's data is a widely resolved morality in different languages and different platforms, so they are credible. It can be seen that the module effect between the volume of 200 to 400 logic is the best. Compactness and orthogonal code is not the only software element with so-called "best single volume". Language and APIs are also subject to Hatton's U curves by the limitations of human awareness. Therefore, UNIX programmers have found two elements of modularity in designing APIS, command sets, protocols, and other things: tightness and orthogonality. Compact compactness means that the design is "easy to understand and accept" for human brain. Compact software tools have many advantages as the daily manual tools. It makes people use it, it is convenient to naturally improve your efficiency, and it is safe and reliable, unlike those complex tools, you can't hurt you. Compact does not mean function weak, if a design building is easy to understand, then it can be very powerful and flexible, while maintaining compact. Compact, it doesn't mean it is easy to learn. You may have to understand the exquisite concept model of abstraction, and you can feel easy. Software is very absolutely compact, but many software is relatively compact, and they have a compact work set, a functional subset that meets the daily needs of 80% or more expert users. For example, UNIX system calls the API is compact, and the C standard library is not. Make (1) is compact in the UNIX tool, and AutoConf (1) and Automake (1) are not. In the markup language, HTML is compact, and DocBook is not. MAN (7) is compact, troff (1) is not.
In a generic language, C and Python are compact, Perl, Java, Emacs Lisp and Shell are not. C is "anti-compact" - the designer of the language recognizes that he doesn't expect someone to fully understand C . However, it is not a compact design is evil or bad. Some problems are too complex, and the compact design cannot be implemented. Here is the compactness, the purpose is not to hope that the reader will see it as an absolute requirement, but like UNIX programmers, reasonably treat, try to practice, and never give up easily. Orthogonal orthogonality helps you put compact design, at this point, it is very prominent. In purely integrated design, there is no side effects, and every action only changes one thing, does not affect other things. For each attribute in the system, there is only one way to change it. Computer monitors are a good example of orthogonality, you can assign dark and do not affect saturation, and color balance control is independent of each other. If not, imagine how much trouble you will meet! There are too many non-orthogonal design in the software. For example, the author of the format conversion function often does not think about the path name of a source file as a parameter, but the input is often from an open file handle. If it is designed to be orthogonal, the function should not have "open file" Side effects, this function will handle data streams from various source. Doug Mciloy's famous saying "only one thing" is often considered to be a rumor about the simplicity, in fact, this sentence is at least equivalent to the emphasis on orthogonality. The main problem with non-orthogonality is that side effects disturb the professional thinking models of programmers and users, and often forgotten, with different degrees of disaster. The Unix API is a good orthogonal design example. Because of this, the C library on other platforms is trying to imitate it. So even if you are not a UNIX programmer, it is also worth studying it. Spot rules The Pragmatic Programmer book points out a particularly important orthogonality, "Don't review yourself" rule: any knowledge point should be unique, no disambiguous, in the system to determine undoubted ways . In this book, I follow Brain Kernighan's recommendations and call this rule as Single Point of Truth, or SPOT law. Repeat causing inconsistency, which constitutes a potential harm to the code. Because if you want to change one of the repetition, you must remember to change all of it. This reflects that you have not organized your code at all. Software is a multi-level broadly said that when you design a function or an object hierarchy (hierarch ", there are two directions available, and your choice will have a significant impact on the layering of the code. Since the top, the bottom is from bottom to bottom, and from the problem domain, the specific operation will be used to start up - from the specific to abstraction. For example, if you want to develop a firmware for a disk drive, there may be some operating original words such as "magnetic head move to a physical block", "Read Physical Fast", "Switching" LED ", etc. The other direction is from top to bottom, from abstraction to specific, from the topmost program or logic overall description to the individual operations. For example, someone designs a massive memory controller that controls different media, which can be started from abstract operations, such as "Address Logic Block", "Read Logic Block", "Write Logic Block", "Switch Indicator".
This is very different from the hardware level of the hardware, a large example is a web browser. Self-designed design starts from a specification - can accept which URL types, which images can be displayed, how to support Java and JavaScript, and so on. The implementation layer corresponding to this top-down view is the main event loop of the application. At the same time, the web browser must call a large number of dedicated meta operations (Primitives). For example, establish a network connection, send data, accept responsive, such as GUI-related operations, such as HTML parsing operations. From which end, this is concerned, because your starting point is likely to constitute a restriction on your endpoint. If you are completely top-top, you may be embarrassed to find that the logically needed to actually implement it. If you are completely low, you will find something you have nothing to do with the procedure. Since the 1960s, primary programmers have been taught that writing procedures should "top down, gradually subdivided". It is a good experience in the top three conditions: a. You can confirm the needs of the program in advance, b. This specification is not likely to change in the implementation process, c. In the bottom You have a full freedom to choose the way you work. The higher the program level, the easier it is to be satisfied. However, even in the highest level of application development, these conditions are often not established. Take self-protection, programmers try to make two programs. On the one hand, the abstract specification is expressed in the top-down application logic, and on the other hand, it can be reused when the function and the library are summarized. UNIX programmers mainly do system programming, which tends to be upstairs development methods. In general, the development of the bottom up is more attractive, which makes you develop in a way of exploration, give you a relatively abundant time to refine the vague norm, and more in line with the lazy lazy time of the programmer - once an error The scrapped code is usually much less. However, the actual code is typically binding from the top downward and upstart. Both are often used in one project, which directly leads to the emergence of glue layers. The glue layer is usually confusing when it hits the top of the top and the upstairs. The top-level application logic and the underlying meta operation must be blocked by a glue layer. For decades, UNIX programmers understand a truth, the glue layer is something that is disgusting, the less the bonding layer is, this is the big thing of life! The glue layer should be used to stick things together, rather than being used to cover conflict between layers and layers. An example of the browser is taken, the bonding layer includes: the document object parsed by HTML should be set to the bitmap in the display buffer. This part of the code is difficult to write, the wrong is wrong. HTML analysis and the errors and defects of the GUI library will be expressed in this layer. The browser's plywood must not only act as an intermediaries in the norms and meta, but also act as an intermediaries - HTTP network protocol behavior, HTML document structure, different graphics and multimedia formats in the middle of several different external specifications. User behavior from GUI. A layer of plywood is very prone to error, but this is not the worst. If a designer realizes the presence of the glue layer, and trying to tissue this glue layer into an intermediate layer with its own set of data structures, then the result will be more than two glue layers - one in that one On the middle layer, one is under. Programmers smart but lack of experience are often actively jumped to this trap.
