Window class, OO

Design of Window Management in Wndows
Is very in line with OO ideas.

First, the definition of each Window is defined by the WNDCLASS structure. In WNDCLASS, we need to provide
Window class name, Window class style, and Wndow Procedure, WNDCLASS also provide application
Extra class bytes and extra window byte. The two spaces can be analogous to class static fields and
Object fields. Like the general class definition, the WNDCLASS structure defines the State and behavior of the Window object.
In this way, the same WNDCLASS can be used for a similar Window regardless of its position, size, and Window attribute.
For Windows with different behaviors, we can use Sub-classing to change some of the messages.
In fact, this method is equivalent to override virtual method. Of course, there is also the super-classing statement.
Before using WNDCLASS, you must register it in the Win32 User Module. Then, you can use CreateWindow to create a Window instance, it is worth noting that in CreateWindow, we do not get the WNDCLASS structure pointer to describe the WNDCLASS used, but use the Window class name, if you rewrite these APIs in C #, you can see a very familiar design.
Class WindowManager
{
Public static void RegisterWindowClass (WindowClass wc );
Public static IWindow CreateWindow (string windowClassName, CreateWindowParameters params );
//...
}
That's right, Factory method. In fact, we reuse Common Controls in this way.
Here I write the returned HWND as an IWindow interface, because I think hwnd is like this pointer for a series of Window functions for member methods. Hwnd should be considered as the this pointer in the C function, rather than the private data member of the Window object. In fact, the Data encapsulation of the Window object is very effective and no internal data structure is exposed.
The idea is broken, and I will write it later...