[Turn]c++ object-oriented basis

From:here

　1. Key concepts of C + + object-oriented programming

There was a role in the early revolutionary film, he said: "I am the party, I represent the CPC, I am the party." Then he brought disaster to the comrades.

Will programmers with C + + know about object-oriented programming?

Programmers who do not use C + + must not understand object-oriented programming?

Both are not necessarily. Just like bad guys may not be good people after joining the party, good people do not necessarily become bad people.

I am not afraid to offend the outrage to say a big liar: "C + + no master, C language has a master." "After 8 years of programming in C and C + +, I deeply regret that I am not a master of C, and I am sorry that no one has asked me how to do object-oriented programming. Like many C + + programmers, I think I understand object-oriented programming when I enjoy the benefits of C + + syntax. Just like squeezing out toothpaste and selling toothpaste skins, that's throwaway.

People do not understand Pinyin can also speak Putonghua, if you know pinyin will speak Putonghua better. Do not understand object-oriented programming can also be used in C + + programming, if the understanding of object-oriented programming, C + + programs will be better compiled. This section covers three very basic concepts: classes and objects, inheritance and composition, virtual functions and polymorphism. Understanding these concepts can help to improve the quality of the process, especially in terms of "reusability" and "extensibility".

　　1.1 Classes and objects

Object is an instance of Class (Instance). If the object is likened to a house, then the class is the design drawing of the house. So the focus of object-oriented programming is the design of classes, not the design of objects. Classes can encapsulate data and functions, where functions represent the behavior (or service) of a class. The protected class provides the keyword public, the private, and private to declare which data and functions are publicly, protected, or proprietary.

This can achieve the purpose of information hiding, that is, to let the class only expose what must be known to the outside world, and hide everything else. We can not abuse the packaging function of the class, do not treat it as a hotpot, everything is thrown in.

Are the classes designed to be data-centric or behavior-centric?

Advocates of the "data-centric" faction are concerned with the internal data structures of the class, and they are accustomed to writing the private type of data in front, and writing functions of the public type behind, as shown in Table 8.1 (a).

The faction that advocates "behavior-centric" focuses on what services and interfaces the class should provide, and they are accustomed to writing functions of the public type to the front and writing the private type of data back, as shown in table 8.1 (b).

Many C + + textbooks advocate "data-centric" when designing classes. I insisted and suggested that the reader "behave as a center" when designing a class, that is, first consider what functions the class should provide. At the core of Microsoft's COM specification is the interface design, which is equivalent to the public function of the class [Rogerson 1999]. In terms of program design, let's not doubt the style of Microsoft Company.

Designing isolated classes is easier, and it is difficult to design the base class and its derived classes correctly. Because some programmers do not know the concepts of "inheritance" (inheritance), "combination" (composition), and "polymorphism" (polymorphism).

　　1.2 Inheritance and combination

If a is a base class and B is a derived class of a, then B inherits the data and functions of a. The sample program is as follows:

classA { Public:  voidFUNC1 (void); voidFUNC2 (void);  }; classD | PublicA { Public:  voidFUNC3 (void); voidFunc4 (void);  }; //ExampleintMain () {b b;//an object of BB.func1 ();//B inherits the function from a Func1B.FUNC2 ();//B inherits the function from a FUNC2b.func3 ();  B.func4 (); return 0; }  

"Too useful, too easy to use, to prevent the chaos of" inheritance. We are going to set some rules for the use of "inheritance":

If Class A and Class B are irrelevant, it is not possible to let B inherit the function of a in order to make B more functional.

Do not think "do not eat white do not eat", let a healthy young man to eat ginseng for no reason to fill the body.

Second, if Class B is necessary to use the function of a, there are two situations to consider:

(1) If logically B is a "one" (a kind of), B is allowed to inherit the function of a. If a man is a man (Human), a boy is a kind of man. Then the class man can derive from the class human, and the class boy can derive from the class man. The sample program is as follows:

C + + code

class Human  {  ...  };   class  Public Human  {  ...  };   class  Public Mans  {  ...  };  

(2) If logically A is a "part" of B, B is not allowed to inherit the function of a, but to combine B with a and other things. For example, the eye, Nose (Nose), Mouth (Mouth), ear (ear) are part of the head (heads), so the class head should be composed of class eyes, Nose, Mouth, ear, not derived. The sample program is as follows:

classEye { Public:  voidLook (void);  }; classNose { Public:  voidSmell (void);  }; classMouth { Public:  voidEat (void);  }; classEar { Public:  voidListen (void);  }; //The right design, the lengthy procedureclassHead { Public:  voidLook (void) {M_eye. Look (); }  voidSmell (void) {M_nose. Smell (); }  voidEat (void) {M_mouth. Eat (); }  voidListen (void) {m_ear. Listen (); }  Private: Eye M_eye;  Nose M_nose;  Mouth M_mouth;  Ear m_ear;  }; 

If you allow head to be derived from eye, Nose, Mouth, Ear, head will automatically have look, smell, Eat, and Listen features:

// the wrong design   class  Public  Public  Public  Public Ear  {  };  

The program is short and running correctly, but the design is wrong. Many programmers can't afford to "inherit" the temptation to make design mistakes.

A rooster is struggling to chase a hen that has just laid eggs, do you know why?

Because the hen lays eggs.

　　1.3 Virtual function and polymorphism

In addition to inheritance, another good feature of C + + is the support for polymorphism, which allows objects of derived classes to be used as objects of the base class. If a is a base class, B and C are derived classes of a, and the parameter of the Polymorphic function test is a pointer to a. Then the test function can refer to objects A, B, and C. The sample program is as follows:

classA { Public:  voidFUNC1 (void);  }; voidTest (A *a) {a-Func1 (); }  classD | PublicA {...}; classE | PublicA {...}; //ExampleintMain () {a A;  b b;  c C; Test (&a); Test (&b); Test (&c); return 0;  }; 

The above procedures do not see what the "polymorphic" value, coupled with virtual functions and abstract base classes, "Polymorphic" power is displayed.

C + + uses the keyword virtual to declare a function as a virtual function, and the virtual function of the derived class will be the function of the virtual function corresponding to the (override) base class. The sample program is as follows:

classA { Public:  Virtual voidFUNC1 (void) {cout<< "this isa::func1 \ n "}}; voidTest (A *a) {a-Func1 (); }  classD | PublicA { Public:  Virtual voidFUNC1 (void) {cout<< "this isb::func1 \ n "}}; classE | PublicA { Public:  Virtual voidFUNC1 (void) {cout<< "this isc::func1 \ n "}}; //ExampleintMain () {a A;  b b;  c C; Test (&AMP;A);//output This is a::func1Test (&AMP;B);//output This is b::func1Test (&AMP;C);//output This is c::func1return 0;  }; 

If the base class A is defined as follows:

class A  {  public:  virtualvoid Func1 (void) =0;  };  

Then the function Func1 is called the pure virtual function, and the class containing the pure virtual function is called the abstract base class. The abstract base class defines the form of a pure virtual function, and the specific function is implemented by the derived class.

The combination of "abstract base class" and "polymorphic" has the following outstanding advantages:

(1) The application does not have to write function calls for each derived class, only the abstract base class is processed. This one

Call "Status quo", can greatly improve the reusability of the program (this is the interface design reuse, rather than code implementation of reuse).

(2) The function of the derived class can be referenced by the base class pointer, which is called backward compatibility, which can improve the extensibility and maintainability of the program. It is not surprising that previously written programs can be called in the future, but programs written in the future can be called by previously written programs.

 

[Turn]c++ object-oriented basis