Recently changed the next engine code (for its own components), found that some of the interface is only a specific class and its internal functions to access, but do not use the form of friend declaration to do the data interview-of course, the use of ordinary non-virtual form that means not to recommend overloading.
Therefore:
1. It is recommended that the declaration of the derived class (or consent) overload be a virtual function that is the virtual type.
2. The declaration of a forced derived class implementation is pure virtual function
3, the function that does not want the derived class to overload or overwrite is the ordinary class, suppose that the group of visitors has limited scope or the scope is less. The ability to consider the way to add friend +protected to access control, so as to achieve effective design information transmission. But sometimes we can't guarantee that friends we might need to visit, or that other classes are not designed by us. There will be a phenomenon mentioned at the beginning. In view of this, I think C + + should add an injection mechanism that allows other classes to access the protected function of another class during compilation, rather than just inheriting. Perhaps friends are enough, but the limits of friends are too obvious.
The mechanism implements details such as the following:
Regable class A
{
Protected
void visit;
Something else
};
Class B:reg A
{
A * p;
void Visit ()
{
P->visit ();
}
}
4, if an operation agreed to rewrite, it is best to use the form of virtual, even if the loss of a small part of the performance, but still can be the original diversification of operations. This produces a strong contrast with 3, which reduces the coherence of the Code design and reduces the thought coupling
The following paragraph is a very good code:
/** * Sets the arrival order when this node had a same ZOrder with other children. * * A node which called AddChild subsequently would take A larger arrival order, * If The children has the same Z Order, the child with larger arrival order would be drawn later. * * @warning This method was used internally for Localzorder sorting, and don ' t change this manually * * @param ord Erofarrival the arrival order. * /void setorderofarrival (int orderofarrival);
When I see this gaze. I immediately determine if I need to deal with the interface change.
Multi-package, less open. It is strongly recommended that the C + + standard add an injection mechanism between class