Object-oriented topics C and C + + (4)--solving encapsulation, avoiding interfaces

List of articles in this column

First, what is object-oriented

Second, C language can also achieve object-oriented

Third, the non-elegant features in C + +

Iv. solve the package and avoid the interface

V. Rational use of templates to avoid code redundancy

VI, C + + can also reflect

Vii. single-Case pattern solving the construction order puzzle of static member objects and global objects

Viii. more advanced preprocessor PHP

Iv. solve the package and avoid the interface

Well, today we're going to talk about how to design, solve the non-elegant features in C + +, improve the structure of the project, and improve the speed of compilation.

The last time we mentioned that if a class is not packaged well and is prone to inconvenience, how can design avoid this phenomenon?

class test {public:    voidprint() {        printf("Hello\n");    }    void print2() {        printf("K : %d\n", k);    }private:    int k;};

A brief improvement to move the implementation of the function into the CPP implementation file

The simplest idea is to separate the implementation from the Declaration, which is also advocated by C + +, so that although the file will increase, the speed of compilation and the clarity of the code will increase.

/* test.h */class test {public:    voidprint();    void print2();private:    int k;};

/* test.cpp */#include"test.h"void test::print() {    printf("Hello\n");}void test::print2() {    printf("K : %d\n", k);}

Obviously, so we change the CPP file, the. h file will not be affected, but if my private method increases, then I still need to change the. h file, which will affect all references to my part, in order to avoid this situation, what is the best way to design?

Using interfaces to reduce code coupling

A standard design pattern is the use of interfaces, which are often used in the design of many libraries, and the core idea is to avoid the exposure of internal methods by means of polymorphic calls.

An interface is typically a C + + polymorphic class:

/* Itest.h */class Itest {public:    virtualvoidprint0;    virtualvoid0;};extern// 类似工厂的方式为你构建类

/* Itest.cpp */#include "test.h"ITest* createItest() {    returnnew test();}

Let test inherit from this interface:

/* test.h */public Itest {public:    virtualvoidprint();    virtualvoid print2();private:    int k;};

Such benefits of course is very obvious, the class into the form of an interface, you can easily modify the following implementation class, regardless of how the implementation of the class changes, are within the scope of the module, the interface is unchanged.
However, the disadvantage of this is also obvious, if C + + in a large number of ways to achieve internal encapsulation, then in many cases inefficient, and the complexity of the code comes up, you need to add a lot of interface classes.

Lightweight Member-Class encapsulation

Here's a simple way to implement class encapsulation, first or the test class, and we'll show it as Test2:

/* test2.h */class test2 {public:    voidprint();    void print2();private:    int k;};

The k here actually does not need to be written here, what we need is to encapsulate the private part of the whole into a class:

/* test2.h */class test2_private;class test2 {public:    test2();    test2(int);    ~test2();    void print();    void print2();protected:    test2_private* that;};

/* test2.cpp */#include "test2.h"class test2_private {public:    int k;};test2::test2() {    new test2_private();    0;}test2::test2(int k) {    new test2_private();    that->k = k;}test2::~test2() {    delete that;}

At this point, we found that this kind of encapsulation can be very effective to solve the problem of the interface of the class, and because only use the class pointer, so we do not need to declare the private class forward, so this class can be easily modified, so as to avoid the interface and the problem of polymorphic calls.

This design also has a purpose, if you have another code generator generated code, need and existing classes embedded use, then recommend this way, QT is doing this:

 #ifndef mainwindow_h  Span class= "Hljs-preprocessor" >#define  mainwindow_h   #include <qmainwindow>  namespace Ui {class MainWindow;} Class MainWindow: public  qmainwindow{q_objectpublic< /span>: explicit  mainwindow  (qwidget *parent =    Span class= "Hljs-number" >0 ); ~mainwindow (); private : Ui::mainwindow *ui;}; #endif //mainwindow_h   

#include "mainwindow.h"#include "ui_mainwindow.h"MainWindow::MainWindow(QWidget *parent) :    QMainWindow(parent),    ui(new Ui::MainWindow){    ui->setupUi(this);}MainWindow::~MainWindow(){    delete ui;}

We found a magic code here.

Ui {class MainWindow;}

In fact, this is just another class, and this class does not have the same name, Ui::mainwindow is the QT designer to help generate the class, used to annotate the UI interface generated some code, in order to let the code very well and our own class unified, they used this way.

Object-oriented topics C and C + + (4)--solving encapsulation, avoiding interfaces