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 Printed November 23, 2024, 8:11 pm This article has been viewed/printed 35402 times. Google search has resulted in 51 hits on this article since January 25, 2004. |