Login
Templates, Tools and Utilities
for Clarion Developers
Templates, Tools and Utilities
|
||
|
|
|
Add a comment to an Icetips ArticlePlease add your comments to this article.
Please note that you must provide both a name and a valid email address in order
for us to publish your comment. Comments are moderated and are not visible until they have been approved. Spam is never approved!
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 November 23, 2024, 2:09 am This article has been viewed 35426 times. Google search has resulted in 27 hits on this article since January 25, 2004.
|
|