Login
Templates, Tools and Utilities
for Clarion Developers
Templates, Tools and Utilities
|
||
|
|
|
Icetips Article
Back to article list
Search Articles
Add Comment
Printer friendly
Direct link
OOP: Better OOP part 1 2003-04-12 -- 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
These days there is a self perpetuating cycle with computer software,
especially database programs. Business and government gets more complex and
demanding, requiring more data and different ways of presenting and
analyzing data. As programming programming tools and computers become more
powerful and prevalent, businesses and governments become more demanding
because of their perception that their demands are easily met. When the
demands increase, the software becomes more powerful again. An so on. It
is a challenge to keep up.
One solution is to keep hammering out the code. By brute force you can
simply keep writing those reports as they become necessary. But at some
point you start to realize that there has to be a better way to do this,
because you notice that you are coding the same logic, in a different
format, over and over. Once you have three reports that present the same
data in different ways, you have a bad situation developing. If there is an
enhancement to be made to your database, now you may have three report
procedures to change. Miss something, and you've got some reports working,
and some broken. To do it right, you have to modify each report procedure
to accommodate the new data structure. So again you are working on three
different sections of code.
That is the old way of doing things. But there is a better way, with object
oriented programming.
Clarion is rich with OOP opportunities, but unfortunately the extent of a
typical Clarion programmers OOP experience is selecting "ABC" rather than
"Clarion" when starting a new application. OOP is mysterious, and it
requires the dreaded "hand coding" that many Clarion programmers try to
avoid. But let's face it. If you are a programmer, you are going to have
to write some code when it is called for. Otherwise, you are just a
template user.
I remember when Clarion4 appeared. It was difficult for me to understand
what all this OOP stuff was about. But when I did understand it, it was
like a light coming on, and I begain writing my own custom classes that had
nothing to do with ABC, but made the job of programming and keeping up to
date with customer demands easier. In fact, my first significant OOP coding
was for a Clarion "legacy" application that didn't use ABC.
OOP is so prevalent today that Clarion programmers are in danger of being
left behind. Not because Clarion cannot handle OOP, but because Clarion
programmers don't use OOP in productive ways. Some advantages of OOP are:
1. Code is more modular. Little pieces of code work together in big ways,
but in ways that reduce the risk of one section of code intererring with
another section.
2. Code is reusable. And I'm not talking about cut and paste, or even
templates. I'm talking about code that is written once, and called from
multiple places, under different circumstances. When carefully designed,
OOP can allow you to expand functionality easily by making the enhancement
in one place, without having to go through all your program changing things.
This also implies that if you have a bug, that bug appears everywhere--but
when you fix the bug, the fix appears everywhere.
3. Data is reusable. Or to put it another way, objects can contain data,
and when the object is used by other parts of your program, the data is
immediately made available to the other parts, without further effort.
4. Team programming is made easier. Objects allow a programmer to do his
one task, without interfering with other team members' work. Objects also
make the one team member's work available to other team members in a safe
way, without the other team members having to know the internals of the
object.
5. Individual programming is made easier. The individual programmer at
times does act like a team. You get so deep into one task that you forget
what you have done in other places. OOP let's you concentrate on the task
at hand, with much less worry about whether you are going to break something
else in another part of your program.
6. After a while you don't know how your program works any more. "Umm,
Dan, that's a GOOD thing?" Yes, it's a good thing. You write little pieces
of code. Then you use them together in a way that creates medium size
functionality. Then you use those medium size things to create bigger
functionality. Soon you are no longer thinking about the nuts and bolts.
You are thinking of the big picture. (Note that this sequences is not often
the correct one--usually you should start with the big picture and work your
way down to the little pieces, but the result is the same. I think the way
I described it better illustrates the finished product, and is easier to
understand.) When your program is broken, you can fix the little piece.
But when using the little pieces together, you don't have the mental strain
of having to consider everything else at the same time. For example, if you
have an object that retrieves a list of customers, when you use that object
elsewhere, you don't have to worry again about how the customer data is
retrieved.
7. You begin to think in a different way. While every object has to have
procedural code to work, your thoughts are about objects, not code. For
example, in wirting a report to print an employee list, you might think of
an employee dataset object. If you already have one of those, you can use
the object in your report procedure, rather than repeating the process of
writing code to query the employee table yet again. And when that kind of
thinking gets to be routine, it occurs to you that you can also use that
employee dataset object to generate a spreadsheet file, a word processing
merge document, a web page, etc. Now you are really cooking!
Many discussions of OOP concern horses, ducks, cars, and airplanes. I
promise I won't do that. We don't program horses or cars. We write
database programs. Describing animals or machinery has never helped me
understand how to write OOP, and I suspect many others feel the same way.
Dan
Today is November 21, 2024, 3:47 am This article has been viewed 35399 times. Google search has resulted in 51 hits on this article since January 25, 2004.
|
|