I see object-oriented programming in Delphi
Object-oriented programming techniques are also brought about some years. When developing large software, an object-oriented programming technique can shorten the development cycle of the program, improve program readability, easy to adjust, and improve procedures accordingly Maintainability, while maintaining the maintenanceability is an extremely important indicator for ensuring its vitality. I don't know that you have noticed that there is no, the programming language with high visualization is difficult to handle in an object-oriented programming technology. For example, VB, 4.0 basically does not support object-oriented programming, 5.0 good, but Microsoft only dares to say more than 5.0 more than 4.0 on object-oriented programming, but not say 5.0 support full-oriented programming (6.0 I I haven't used it, I don't know if I can support it, it is also the gospel of VB enthusiasts). This is probably one of the important reasons why people often do not need VB to do large programs. I don't know if Delphi starts from what version begins to provide object-oriented programming, but I am from VB 5.0 to Delphi 4.0, which is the most important reason except for project requirements. Since Delphi supports object-oriented programming, it also supports the general-oriented programming, and because of its visualization technology, many people (including me) are easily deviated from the object-oriented direction. In fact, I think I have to implement it. Object-oriented programming is also difficult, because Delphi gives you all the objects, you just pay attention to your code when you are programming. Below is some experience of using object-oriented technology in Delphi:
1. Don't use global variables, even if you want to use, use global objects to replace it. It is used to programming programmers to make mistakes in this point, and this is relatively difficult to master. In fact, global variables are also a large defect for process programming technology, difficult to track, difficult to debug, and difficult to maintain. Why use objects instead of variables? Objects can package the operation of the variable, any operation of the variable must be completed by calling the object, we can set the breakpoint to debug in the method of operating the variable, which solves the three mentioned above. Difficulties (difficult to track, difficult to debug, difficult to maintain). For a common example (maybe not to maximize this problem): Let you make an IE, for Internet option, how do you intend to deal with? According to the above discussion, my idea is to write a TDEFAULTINI class, which is responsible for the saving and reading of the settings in Option. Option window and other need to operate the objects in which settings are processed by this class. This enables the package. You can define an instance of a TDEFaultIni class as a global object, of course, because these settings are saved to read in the memory, you can also create a TDEFault object only when needed to complete your feature.
2. Exchange data between objects, use the attributes as possible instead of variables why is it necessary to use attributes instead of variables? The operation of the data can be encapsulated by the method of the attribute. Once the data structure inside the object is changed, the impact of the part of the procedure can be reduced as long as the attribute interface we provide is constant. For example, the data is swapped through an attribute between the FORM. In the future, because of a reason you have to change the original use of the array to use the linked list, as long as your attribute interface is still an array, it has little effect on other objects.
3. The reasonable way to arrange objects, I will directly illustrate this problem. For example, when connecting the database, you set up the AliasName and Params in TDATAMODULE in the primary form, and then use DATAMODULE.DATABASE.OPEN to connect, or write A TDATAMODULE.CONNECTTODATABASE method, uses AliasName and Params as the property of TDataModule, and call this method in the primary form to connect? In theory, both methods are object-oriented. Perhaps many people can't experience the superiority of the latter approach, imagine that if the database changes, only SQL Server, now you need to consider Oracle. The latter approach will make your response easier, especially when you have a few places in the master form, you need to connect the database. 4. Reasonable Arrange your object a question This has several objects to solve, what features do every object, what is the connection between them? This problem is an eternal issue for object-oriented programming, how is this problem in Delphi? Here I discussed it with Form and everyone discussed it, first put an example: Write a program that puts the favorites in IE into the database, how to arrange your object? This problem is not complicated, an form can solve the problem, maybe for the database management, plus a DATAMODULE, Form is responsible for reading the favorites, displayed in TreeView, the user can select the TreeView node (ie Collection Get into the database. Maybe your program is just doing well, the boss requires the same function to Netscape Bookmark, how is your change? If you used two objects to complete the functionality of the FORM discussed above, an object is responsible for importing the data of the favorites into the TreeView, and the Form only completes the operation of TreeView, you will find that your change is very relaxing. From this, my suggestion is that FORM completes only the operation of the interface, and for the specific data structure, it is done by the object we write.
5. Don't exchange data between the two classics FORMs is easy to commit this mistake in Delphi, which is very dangerous, because it is very likely that the form that exists is closed or simply did not open, and then To do the biggest disadvantage is difficult to understand. One of the solutions is that the data can be exchanged by their parent Form, such as the attribute value of the A sub-Form in the parent Form, and set the attribute value of the B sub-Form according to these values. Object-oriented programming technology is never applied to the development of large software, in fact, small programs use object-oriented technology development for future expansion and transplantation (ie, just partial functions) is very helpful. I hope that this article can play a role of throwing bricks, welcome everyone to discuss, my email: l940801@yahoo.com.
