Multi-state and object-oriented (below)
Two weeks later, the compartment next to Andy became my territory. My job, my study, and my lunch break, all here.
"Andy, is this a few OS base classes of Rhapsody? They are not as difficult as the imagination."
Rhapsody is a tool we are using a set of intensive models and code that generates functions in one. It has a very prominent feature that supports many OS platforms. Hey, I mean is not just like Java. It has the skills of "Write Once, Run Anywhere". In fact, you can choose different target platforms in Rhapsody, which will select the corresponding compiler, the connector to output The binary you want.
From the code level, Rhapsody provides a group of OS abstract base classes, which is the so-called OSAl (Os Abstract Layer), such as Omosthread means a thread, OmosMessageQueue means a message queue, Omosmutex means a mutex. RHAPSODY's application framework is to achieve the purpose of communicating with OS by manipulating pointers of these abstract base classes.
For each specific target platform, Rhapsody needs to deliver a set of specific classes from this group of abstractions, and achieve each interface declared in the base class in the corresponding platform API. Of course, if rhapsody does not support the OS platform you want, and your app is asked to run on it, it is clear that the code is to do.
Maybe you will be like me, think it's really this. However, please listen to this loud sound:
"Yes? Young people, please stay calm." Don't say, this is Andy!
It seems that there is another mystery. My eyes immediately started searching in a file called OS.h because all OS abstract base classes are defined here. Suddenly I found out that there is a class called OmosFactory!
"Factory? What are you studying the operating system, how do teachers don't tell this thing?" I started to speak for themselves.
"What? Even you don't know ..." Andy explored his head, and his face was suspected.
This is clearly a general, I know that he wants to train me as soon as soon as possible, but it can also be used to use it. Continue to see, I found that OmosFactory is as follows:
Class OmosFactory {
PUBLIC:
Static OmosFactory * Instance ();
Virtual OmosMessageQueue * CreateomosMessageQueue (Omboolean ShouldGrow = true, constling messagequence = omosthread :: defaultMessageQueueSize) = 0;
Virtual Omosthread * Createomosthread (Void TFUNC (Void *), Void * Param,
Const char * const threadname = null,
Const long stacksize = omosthread :: defaultstacksize) = 0;
Virtual omoscutex * createomosmutex () = 0;
// Declaration of other member functions
......
}
It turned out to be a veritable object factory, that is, all OS objects in the future will be created! Since it is an abstract class, it is clear that it needs to be derived, and is created by the true OS object by specific derived classes. However, I suddenly felt that some are not right.
"Since it is a base class, why didn't it declare a destructor for Virtual?" I said. "Why are you always so much? Is I just see the ability of you?" Andy didn't forget to give me some stimulation.
"Unless the designer of this class determines that it will not be able to delete a DeriveD Object through a Pointer-to-Base."
"In this case, how do you talk about how customers use this class?" Andy chased.
Yes, this is an abstract class, which means that any object cannot be defined for it. But now I can't dynamically create a derived class object, and assign its address to a pointer to OmosFactory *. What should I do?
Suddenly, I found Static OmosFactory * Instance (); this sentence, I immediately thought about see the definition of this function. I found it in the file vxos.cpp:
OmosFactory * OmosFactory :: instance ()
{
Static vxosFactory thefactory;
Return & thefactory;
}
Similarly, it also has it in the file ntos.cpp:
OmosFactory * OmosFactory :: instance () {
Static ntosfactory thefactory;
Return & thefactory;
}
True big white! Needless to say, VXOSFACTORY and NTOSFACTORY are derived from OmosFactory. In fact, the definition and implementation of the OS classes and factories for VxWorks is in two files of vxos.h and vxos.cpp; and the definition and implementation of the OS classes and factories for Win32 platforms are in NTOS.H and NTOS. Two files in .cpp. Obviously, when the customer wrote
OmosFactory :: instance ();
When he will get a pointer to OMOSFACTORY *, this pointer points to a specific derived class object; and because this object is declared as static, this indicates how many times have been written during the program, regardless of the above sentence. There is only one factory object being generated. Whenever, when the customer wants to get a mutex, he only needs to write:
OmosFactory :: Instance () -> CREATEMOSMUTEX ();
And don't worry about his procedure to run on which OS platform.
"It's a good idea!" I sent a sincere sigh.
"In fact, OmosFactory implemented a design pattern called Singleton." I don't know when Andy actually appeared behind me, and my face seems to have a smile. "When you guarantee that there is only one instance of a class, and Provide a global access point access to it. You can use this mode. "
"Yes, you are right. But I always feel that the power of polymorphism is really playing here."
"In fact, there is also a design pattern called Abstract Factory, perhaps this can give you some revelations." Said, Andy didn't know where to take a small picture [1]:
"You see, whether it is an OS object, or a factory for these objects, customers only need to deal with their abstract base classes. And to properly use these two modes, customers should also use pointers of these base classes. In fact, In the face of this such a Singleton, don't choose this, "Andy smiled and turned away.
December 2002
Reference book:
1. STANLEY B.LIPPMAN. Depth Exploration C Object Model 2. Scott Meyers. Effective C
3. Gang of four. Design mode
[1] This picture comes from famous "Design Patterns, Elements of Reusable Object-Oriented Software".
