面向对象和MFC

I joined a company last year where most programmers use C as their primary programming language. After some communication with them, I find that it is really very different between C and C++, although it is a well-known fact.As we know, C++ is object-oriented while C is process-oriented.But does we really know what is object-oriented? Can we design and program from the object-oriented perspective? And did we take advantage of the three most important attributes of C++?

Normally, do we keep the object-oriented in mind? It doesn't mean that we just use the class.In general, we develop a program to handle some stuff,for example,calculate.If you design that in a object-oriented manner, you may consider that you produce "a person" who can calculate. That "person" can also save the result for you if you want and you can update him when you want to do more complex calculation. You can only see that person and retrieve the result, but you can't see the details about the process.That's encapsulation. You can produce another person who can be born with the first guy's ability. That's inheritance. Besides, you can let the different people inherited from the original guy behave differently while you all use them to add in fact. That's polymorphism. On the other hand, you produce a abacus in the process-oriented way.You use the beads on the abacus each time you want to calculate.When you finish calculating, this process ends and you have to put back the beads. It is nearly the same as one C function does.

In my first one or two years when I start to learn to program with C++, I used the wizard to produce a frame, and added functions to it.Although I used the class, what I do was to add as many functions as I can. Its direct result was that the code was hard to be updated and it looked disordered at last.

Now, I begin to program after designing.There are many questions to answer first.What is the program intended to do? How about the environment? How about the potential update appeal?How to abstract the solution in result of several objects? Are those objects' responsibilities clearly? How is the relationship between them? Are the details encapsulated well? And so on. It's also very important to have deep knowledge of design patterns.

MFC is a good example of using C++ capabilities to encapsulate the Win32 API, though it is not perfect. MFC shortens development time indeed. But I think some points should be noted ,otherwise we will make some mistakes when we are not familiar with the MFC's mechanism. The MFC makes use of the encapsulation that it encapsulate the win32 API, so the MFC functions often have one parameter less than the win32 functions. A MFC class often has a member variable which is corresponding to the Windows structures.For example, MFC supplies class CWnd to encapsulate the HWND handle of a window. The CWnd object is a C++ window object, distinct from the HWND that represents a Windows window but containing it. You must make it clear that closing the window doesn't mean that the object doesn't exist either.

And The MFC also supplies classes that encapsulate Windows common controls. You use a class like that in two steps:call the constructor and then call the member function Create to create the control and attach it to that object.So you can't use it if you only construct the object. The window's functions and structures are in charge of the real operation. It's unusable to only have a C++ object without evaluation of its member variable.

Although the wizard can help us set up a frame quickly, it's still very important to know the code that is automatically created for us and the responsibility and the relationship of the classes generated, such as, the InitInstance function of the class app which create the dlg or combine the view and document class. Once, I downloaded an example of splitter view. It creates two objects for the same view object. One is created by CreateView, the other is created by new. Although it has no problems at first, it can't add content to the view when you want to add something.

Well, there are many virtual functions in the MFC classes. If you want to take advantage of MFC at most, it's very important to know the exact time when those functions are called. I have modified a program which saving and loading its content hasn't used serialization. As a result, some behaviors are a little different from the normal program, for example, there is no prompt when closing the program. I overrode some virtual functions,such as OnSaveDocument, DoFileSave. Finally, it has the same behaviors.