Ten principles of Object Oriented Software development (turn one)
It is useful for developers to look back at the application. Consider whether the application has achieved the intended purpose? Did you follow the best scenario? Is there a better way to achieve the goal? Knowing new, you may find new ideas in retrospect.
This paper presents 10 state-of-the-art object-oriented programming techniques to help you evaluate your applications, and I hope you can use these 10 state-of-the-art technologies to derive maximum benefit from object-oriented programming.
1. Re-examine the declaration operation of the object
How you declare an object variable can have a significant impact on the use and performance of an object. You should use this syntax:
Private M_ocust as CCustomer
Note that you must use the correct range. In most cases, you want the object variable to be private. If you only need this object in a particular program, you can use dim to declare that it belongs to that program. If you need it throughout a class or form module, you should declare it in the top of that class or form with private. By custom, variables declared at the module layer are prefixed with a prefix of "m_" to represent the module layer or member variable. If you need to use an object variable from outside the class, do not set the variable to public, rather define a Property Get program to use the object variable, which prevents other code from using the variable in ways you do not want.
In the declaration, the class name is always used instead of "as object" because using "as Object" makes the object variable a late bundle (Late-bound). This means that before running time, Visual Basic does not know what type of object you will be using, so it does not provide you with an automatic list component (the Drop-down list of object properties and methods). More importantly, there is a noticeable performance impact on early bundle (Early-bound) objects at run time.
Finally, do not use the keyword "New" in the declaration. When you use the keyword "New", objects are automatically created at any time that references it, which can have a slight effect on performance because each object's properties and method calls must be validated to determine whether the object was created. Using the keyword "New" also has nightmares about debugging, because after the object is corrupted, the application automatically recreate the object if you inadvertently refer to it again. When you're ready to transplant. NET, it is more important to understand this, because there is a different meaning to the keyword "New" there. In. NET, the keyword "new" allows you to create an object when you declare it, such as the following statement creates a new customer object:
Private Mo_cust as New CCustomer ()
2. Focus on object cleanup behavior
When you no longer need object variables, be sure to release them, and then VB will break the object associated with the variable, freeing up memory in the application. Use the following code to release an object:
Set x = Nothing
3. The major role of encapsulation
Encapsulate (encapsulation) is literally put in an envelope or "put in a shell". From the point of view of object-oriented programming (OOP), this means that all the data and processing associated with an object are placed in its class.
Encapsulation sometimes refers to information hiding, because you hide the object's data inside the class. If other classes need to use data, you can expose the data by using property programs (property declarations in. NET). This behavior provides control over the class, which controls how users can view or refresh data and prevent other objects from misusing data.
Encapsulation makes the interaction between objects simpler. An object can use this object without knowing the entire data of another object or how its data is managed. For example, a customer object might have name and address attributes as well as phone numbers, credit histories, and other related fields. If a invoice object wants to use a Customer object, it can request a name and address for the invoice without knowing where the customer gets that data or what other data elements are.
For solutions that encapsulate the Document Object Model (DOM) in a wrapper class for Extensible Markup Language (XML), refer to this article, which makes it easier for you to interact with an XML file without having to know the details of the DOM.
4. Status Monitoring Issues
Good component-based development techniques frequently require stateless objects. Stateless objects do not have persisted attributes, only methods. You can access a stateless component, execute the method, and then do the processing without needing to get any data between the method calls.
Some OOP articles suggest that objects without attributes are not objects. But now that we're ignoring this semantic problem, you can create classes that have methods without attributes. This is often necessary when you are engaged in COM + or Web development. An ASP page can execute a method on a component to perform a special processing and then release the component without bothering to manage the object state.
5. Scalability of transfer parameters
Parameters provide a way to pass information between methods of a class. You need to use parameters to pass any necessary data to the method, especially if you need a stateless object.
For example, the PlaceOrder method of a stateless object customer requires that the customer's information be passed to it as a parameter, and then the PlaceOrder method uses this information to complete the necessary processing.
