1, the object-oriented system of the three most basic characteristics
Encapsulation, polymorphism, reusability.
2, COM characteristics of the overview
The encapsulation characteristics of COM objects are very thorough, all object state information must be accessible through an interface, while COM polymorphism is fully represented by the interface, and COM is embodied polymorphism on three levels: interface member function, single interface, a set of interfaces (object class i.e. implemented category). The reusability of COM is relatively complex.
3. Reuse Sex
Reusability is when a program unit can provide functional services to other program units, as much as possible reuse of the original program unit code, can be reused at the source code level, can also be reused at the level of executable code.
The reusability of the C + + language is at the source level, and a class can be inherited from another class, thereby reusing the functions of the parent class. However, the situation is different for COM components, because COM is a standard based on binary code, so its reusability is necessarily based on the binary code level.
COM reusability refers to how a COM object reuses the functionality of an existing COM object, rather than reusing old functionality services. According to COM standards, there are two ways to achieve this reusability: containment and aggregation.
4. Inclusion and Aggregation
Object B calls the corresponding member function of object A to implement the ISomeInterface interface. Therefore, Object B's ISomeInterface interface provides functionality that can exceed the interface functionality of object A, and the results can be inconsistent. Even the interface of object B is not necessarily the same as the interface of object A. In general, the lifetime of object A is contained within the lifetime of object B.
In the aggregation model, the aggregated object a provides functional services directly to the client program of object B, but its lifetime is still controlled by object B, and some other behaviors are controlled by object B, including internal state initialization,
In order for the aggregation to be implemented smoothly, object A must be able to adapt to special processing in the case of aggregation, especially the QueryInterface member function of the interface, which, when aggregated, must give control to the external object when the client requests an interface or Iuknown interface that it does not support. The client's request results are determined by an external object.
Aggregation involves aggregation of objects and the collaboration of the objects being aggregated, not every object can support the aggregation attribute, but aggregation embodies the real meaning of the component software reuse. The reusability of containment is based on the relativity of the client/server model, which is actually the nesting relationship between the client program and the component program. This is the difference between containment and aggregation.
5, commissioned IUnknown and non-commissioned IUnknown
The second parameter of the object creation function CoCreateInstance Punknownouter is used to solve the problem of IUnknown interfaces in the aggregation. Used when it is null for normal use, not NULL. The internal object implements two IUnknown, respectively, of the delegate IUnknown and the non-delegate IUnknown (delegating unknown and nondelgating unknown).
IUnknown that are implemented in the usual way are IUnknown, and the delegate IUnknown has different behaviors in different situations: when the object is used normally, the delegate IUnknown passes the call to the delegate IUnknown of the object, and when the object is aggregated for use, The delegate IUnknown passes the call to the IUnknown interface of the external object, which is the Punkownouter parameter passed in when the object is created, and the external object controls the internal object through a non-delegate IUnknown. The delegate IUnknown itself is not doing anything.
Because the C + + class does not support both IUnknown, both the delegate IUnknown and the non-delegate IUnknown cannot all use the IUnknown class, but we can define a new class. Because COM does not recognize interfaces through class names, it calls interface member functions through vtable.
6. Process transparency of COM interface invocation
A client program creates a COM object that has process-transparent attributes, whether in-process or out-of-process, and where the client can create COM objects using a consistent method. For an in-process component, whether the creation process, or the client program calls the interface function, you can understand the interaction between the component and the customer according to the process of the common process internal function call, but for the out-of-process component, the actual situation is much more complicated, because the component program user program has different process space, Therefore, all the interactions between them involve the process of communication between processes. However, when the COM client creates an Out-of-process component program, it obtains an interface pointer to the component object that indirectly invokes the member function of the Component object, just as the function in this process is called, which is what COM expects to achieve.