` Better OOP part 8 (Dan Pressnell) - Icetips Article
Icetips - Templates, Tools & Utilities for Clarion Developers

Templates, Tools and Utilities
for Clarion Developers

Icetips Article

Back to article list   Search Articles     Add Comment     Printer friendly     Direct link  

OOP: Better OOP part 8
2003-04-26 -- Dan Pressnell
 
Newsgroups: comp.lang.clarion,topspeed.topic.oop March 5, 2006: Note that the code is now available at: http://www.icetips.com/downloadfile.php?FileID=59 Inheritance is having one class that starts out as a copy of another, and then optionally having additional or altered functionality in part of the class. Take these classes: ClassOne class Run procedure() PrintReport procedure() end ClassTwo class(ClassOne) end Those two classes will be identical, and will behave exactly the same way. But do this, instead... ClassOne class Run procedure() PrintReport procedure(), virtual end ClassTwo class(ClassOne) PrintReport procedure(), derived end .. and now you have different behavior, because you have derived a virtual method. Think of virtual methods like this. You have a report already written. Now you copy and paste that report, then change some behavior in the copy. Virtual methods allow you to create new classes like that, replacing or adding functionality to the derived class. The derived class gets all the functionality of the original, plus some. I've uploaded a new sample app to http://toolwares.com/oop_sample.ZIP. Download that and take a look at the PrintPlayers procedure in OOP.APP. The PrintPlayers procedure is designed to print teams and their players, in one of two formats. In the procedure, there is a local class (rClass) designed to print the report one way. Then there is also a local class (rClass_ByPlayer) that prints the report in a different way. It prints the report in the different way by deriving the virtual method PrintReport. For all other functionality in rClass_ByPlayer, the behavior comes from the parent class rClass. Report programming is so messy it cries out for object oriented programming. In the classes for PrintPlayers, there is much in common, such as opening the report, data retrieval, doing a preview, performing totaling, etc. That common functionality is handled in the base (parent) class, so it's available in both. The behavior that is different has been isolated and put in place with the derived method PrintReport. It's kind of like copy and paste, with the benefit that if you change something in the parent class, the derived class gets that changed behavior as well. The Run() method behaves the same in both classes. The difference is that what gets called inside the Run() method, with the PrintReport() call, is based on whether you are in the rClass or the rClass_ByPlayers. A virtual method that has been derived is kind of like typing something in an embed point in the embed editor. In fact, when you type something in an embed point in an ABC app, you are actually using a derived method and modifying a class's behavior. Notice the GetNext() method in rClass and how it is used. Those of you who have programmed in Clarion 2.1 (DOS) will recognize the technique. It is modified here and used in a class, but the concept is the same. And it works as well in Windows reports as it did in DOS reports. I only recently remembered this method of handling breaks, and it works great, giving you much flexibility over many other techniques. Sometimes it pays to teach a new dog old tricks. Inheritance in OOP programming can be a very complex thing. The example app's PrintTeams classes could have been done in one class. The structure of the classes could be different and still just as effective. It's just an example of a simple report to illustrate the concept. Read Clarion's help on CLASS, and read it again and again, until you understand it. Play around with your own classes and derived classes. My experience, though, is that in database programming, you are often involved with a specific task, and inheritance is not as common as it would be in other programming tasks. Don't go overboard. When you think about deriving classes, first ask yourself whether you really need to do that, or whether you are succumbing to the "gee whiz, look at what I can do" syndrome. Common sense still applies. If you have questions about inheritance and derived methods, please ask in the newsgroups, rather than privately to me. That way others can contribute their expertise, and others can learn. Dan


Today is April 19, 2024, 8:42 am
This article has been viewed 35117 times.
Google search has resulted in 27 hits on this article since January 25, 2004.



Back to article list   Search Articles   Add Comment   Printer friendly

Login

User Name:

Password: