Assembly objects and object lifecycle management

Recently, we have studied Huawei's econference and have contact with clients.Source codeIt has been a week since. I think deeply about two issues.

C ++, as an OOP language, is exposed to the source of a new application.CodeHow can we interpret the application. This problem prompted me to think about how to build an application.

When can c ++ objects use reference data? It is found that some classes have the reference counting function derived from a root class and define such a rule, so they cannot be deleted at the application layer!

 

The first problem is that from the perspective of the client application, the encapsulation is quite hierarchical. Of course, at first glance, it is a bit confusing. What is encapsulated so deeply? In vain, it makes reading tired. An application or a component (an independent executable code is generated here) will inevitably come up with a globally defined object, and this object will be able to implement some object instances that encapsulate other classes, or pointer member. To read the code, we need to analyze and understand it layer by layer. In this process, we need to understand the inheritance level of the class and the encapsulation level of the class, here we can generalize to the term representation of the composition and Inheritance of classes. It is often necessary to reference other class instances outside the layer in a class. At this time, you can see pointer members or references in the class. As a globally defined object, it is clear that the singleton mode can enhance the comprehensibility of applications. Because a lot of classes developed by a project are just to assemble the most final global application object.

In the composition and Inheritance of classes, we learned about combination and generalization in understanding the UML relationship. One class may use one pointer to associate another object, this object can be related to its own life cycle, that is, the life cycle of the object that maintains the pointer member in the composite class. However, the difference between C ++ and Java is that a combined class can combine an instance of another class as a member. This kind of composition relationship has some survival and maintenance significance to the inheritance relationship, because you will know that when you destroy the combination class object, after you execute a delete operation, the members are destructed and released. If you use pointer members, the delete operation is performed more than once. This is how pointer members are combined. In fact, the inheritance relationship is a special combination, because C ++ supports multiple inheritance, it is easy to express this combination.

The two terminologies often mentioned in the design patterns book are combination and inheritance. The following is a combination class or a derived class (combined and generalized in engineering ). In conclusion, we can get two different combinations: one is the composition of the Instance Object and the other is the composition of the pointer reference.

 

The second problem is the usefulness of reference counting. I think object lifetime management will be used only during multi-thread asynchronous interaction. At this time, I think it is necessary to hide the Destructor and only use the counting method to manage the object life cycle. In addition, if the reference counting method is used, I think the object construction should not be made public, an instance-like production interface should be provided separately, so that we will not be depressed when we see a bunch of new operations, but delete is handed over to a special place. Resource Management should be responsible for resource application and recovery, rather than separating the delete operations of the new operation.

 

Conclusion For dr. f.