11 principles of Object-Oriented Design

What is object-oriented design? What content does it contain? What are the benefits it brings? What do you need to pay for it? In today's time, it seems silly to ask these questions, because almost every software developer knows how to use a certain object-oriented Programming Language . However, this issue is very important, because in my opinion, the vast majority of people do not know why when using these languages, and do not know how to fully use them.

In all the revolutions that have taken place in the software industry, two factions were once so widely rooted in the hearts of the people, structured programming and object-oriented programming. All mainstream modern programming languages are fiercely influenced by both of them. In fact, if you don't want to write it like structured and object-oriented programmingProgramIt is a hard task. None of our mainstream programming languages are Goto, so they are subject to the most important prohibitions in structured programming. Most of our mainstream programming languages are class-based and do not support defining functions or variables outside of the class. This also avoids the most vulnerable traps in object-oriented programming.

Programs written in these programming languages may look structured or object-oriented, but "looks" can fool people. Today's programming languages often ignore the basic principles of the factional programming language they belong. I will discuss the principles of structured programming in another blog. In this article, I want to talk about the basic principles of object-oriented programming.

In, I wrote an articleArticleAnd published on Comp. object. It was my first article on the good principle. Since then, I have written a lot of untidy articles. You can see them in my PPP book (2), which is also included in many articles on Object mentor, which has a well-known outline (which will be translated into Chinese in the near future, please note ).

These principles focus on the dependency management in Ood, while downplaying the abstract and modeling aspects. This does not mean that OO is not powerful enough in abstraction, or Oo is not suitable for building models. Of course, many people are using these oo components, but these principles focus on dependency management.

Dependency management is a problem that each of us has to face. Every time we open those tangled and disgusting pages in front of the screenCodeAnd we will suffer from negative dependency management. Poor dependency management makes code difficult to change and can be easily destroyed and cannot be reused. In fact, I have talked about many bad designs in my book PPP, all of which are related to dependency management. On the other hand, if dependency is well managed, the code can be flexible, robust, and reusable. Therefore, dependency management and related principles are the cornerstone of the programmer's desire to maintain a sound architecture of the software.

The first five principles are about class design. They are:

◆ SRP, single responsibility principle, one class should have only one reason for change.
◆ OCP: open and closed principle. You should be able to expand the behavior of a class without modifying the original class.
◆ LSP and liskov replacement principle. The derived class must be self-compatible with its base class.
◆ Dip: The dependency inversion principle depends on abstraction rather than implementation.
◆ ISP, interface isolation principle, customers only need to pay attention to the interfaces they need.

The other six items are about the package design principles. In this article, a package refers to a binary publishable file, such as A. jar file or DLL file, rather than a Java package or a C ++ namespace (3 ).

The first three package principles are about package cohesion. They will tell us what to divide into packages:

◆ Rep: Reuse publishing equivalence principle. The granularity of reuse is the publishing granularity.
◆ CCP: the principle of joint closure. All classes in the package should be closed together for changes to the same class nature.
◆ CRP: the principle of reuse together. All classes in a package should be reused together.

The last three principles are about the coupling principle between packages, and the criteria for judging whether the structure of the system package is good or not.

◆ Adp: the no-ring dependency principle. loops are not allowed in the package dependency graph.
◆ SDP, stable dependency principle, and dependency in a stable direction.
◆ SAP: the principle of stable abstraction should be consistent with the degree of abstraction of the package.
 
:

1. OOD, full name: Object Oriented Design, that is, object-oriented design.

2. PPP, Uncle Bob's book agile software development principles, models and practices, and related books, all of which have "principles, models, and practices", that is, priciples, patterns and practices are usually referred to as PPP.

3. namespace. The original namespace is also translated as namespace. It is a special scope. It contains all the identifiers in the scope and is also represented by a identifier, this makes it easy to organize a series of logically related identifiers with one identifier. For Java programming language, namespaces are expressed through Java packages, and all code belongs to one package. Code from other packages must reference a specific Identifier by specifying the package name. For example, the string class in the Java. lang package must be referenced in the form of Java. Lang. String. In C ++, namespaces are often used to avoid naming conflicts. Although the current C ++ language extends the namespace, in the past, C ++ code seldom used this function.

(From: http://soft6.com/tech/6/65017.html)