![]() |
![]() |
|
![]() |
Where to Put Code © 2002 Mike Prestwood Introduction One of the hardest aspects for beginning ObjectPAL programmers is deciding is deciding where to place code. Novice ObjectPAL programmers tend to place code everywhere. Rather than work with the default behavior, the event model, and the data model, beginners often tend to put code in the wrong place. Later, they add more code to try to fix an inelegant approach. Programmers who use DOS PAL and traditional procedural languages are used to writing a lot of code. In the Windows version of Paradox, they tend to overcode to get the results they want. Understanding the system can make the difference between inelegant and elegant code. Taking the time to understand the default behavior of objects, the event model, and the data model can save you much time. If you don't fully understand how an object works, you could end up working harder and accomplishing less. Much of this book deals with this issue. About Coding When new users to Paradox begin writing code in ObjectPAL, they often write tremendous amounts of code. The amount of code can become overwhelming if you don't understand the fundamentals of the product. Usually you follow certain steps whenever you develop an application. Before writing a single line of ObjectPAL code, you always should build the data model and arrange the form until it's similar to what you want. Then, run the form and work with it to see what it does and doesn't do. When you find something that you want to work differently, ask yourself, "What do I want to happen?" and "When do I want it to happen?" Try to do this for only one task or object at a time. In other words, develop in small steps. Go back and forth between Design mode and Run mode and test your work incrementally. When you're done coding and testing a single object, move to the next. By refining your application in steps, you end up with functioning code in bite-sized chunks. If you try to tackle in one step all the work that an application requires, you can easily end up frustrated, with messy code. Remember, program and test one task at a time. Watch Out for Spaghetti Code BASIC, early Pascal, and early C promoted spaghetti code--intertwined code with many repeated parts. These procedural languages required you to write line after line of code. Although modern languages don't lend themselves to spaghetti code, it's still possible to write it. During the development process, you might copy a routine from one spot to another and later find a bug in it. You would have two pieces of code to correct. This is fine if you are perfect and can remember to change both pieces of code. But this method of programming is hard on upkeep, and it makes reusing code nearly impossible. You would have to start every new project from scratch. Use an Object-Oriented Methodology Object-oriented programming involves compartmentalizing and reusing code. Your goal should be to avoid duplicating code by developing self-contained, reusable units. After a while, you will spend the majority of your developing time copying, pasting, and putting together previously developed units. When a bug in a certain unit turns up, you can debug that one unit, and every application from that point on that uses that unit is cleaned up or enhanced. In addition, when you enhance some code that many applications share, those applications are enhanced instantly. Keep in mind that you can still write spaghetti code in ObjectPAL. If you duplicate parts, you inevitably introduce bugs into your application. ObjectPAL, however, promotes good programming. If you follow the rules of object-oriented methodology, develop in compartments, and avoid duplicating code, your programs will be clean. Try to Localize Code Because you're programming in ObjectPAL (an object-based programming language), the code should be as local to the object as possible. For example, if you're trying to decide to put code on a button or the form, then choose the button. If the situation warrants moving up to the form level, it will become obvious. There are many benefits for coding as low as possible, including the ability to copy objects with code on them from one form to another and still have it work. Whenever you have a choice, try adding ObjectPAL code directly to the object to get the desired results. Do you ever want to not code locally? Yes--when you want to work with more than one of the same object. You can use a container above all the objects and put code on the object's container. Code as Low as Possible Put code on the lowest possible container. If you later need to use the same code elsewhere, move the code up the container path to the lowest container that both objects can see. If you follow this rule, your code will be compartmentalized and portable. By developing in compartments, you keep code segments apart. A bug introduced in one compartment is less likely to affect other parts of your application. If you are programming a button, put all the code, including variables, on the button. This makes the button a self-contained unit that is easily copied and pasted to other forms. If you later need that same code on another button, convert it to a custom method and move it up the container path to the button's container object. A container object is an object that completely surrounds and controls the behavior of all the objects within it. If you then decide you need to use the code with several pages within the form, then move the custom method to the form. If you need the same routine in several forms, consider putting it in a library. A library is an object that stores custom ObjectPAL code. Libraries are useful for storing and maintaining frequently used routines, and for sharing custom methods and variables among forms. Using this general rule of coding as low to the object as possible gives you maximum access to your code and saves you time. In addition, if you later find a problem with the routine, you need to correct it in only one spot; instantly, all code that uses the routine benefits from the improvement. Although you can write spaghetti code with an object-based language, ObjectPAL supports and promotes good object-oriented practices. By using contained objects and custom methods properly, you can keep your code clean. Develop in self-contained units whose code is protected from other objects. [Editor's note: This article can also be found on Mike's site at: http://www.prestwood.com/community/paradox/info/where2code.html.] Discussion of this article |
![]() Feedback | Paradox Day | Who Uses Paradox | I Use Paradox | Downloads ![]() |
|
![]() The information provided on this Web site is not in any way sponsored or endorsed by Corel Corporation. Paradox is a registered trademark of Corel Corporation. ![]() |
|
![]() Modified: 15 May 2003 Terms of Use / Legal Disclaimer ![]() |
![]() Copyright © 2001- 2003 Paradox Community. All rights reserved. Company and product names are trademarks or registered trademarks of their respective companies. Authors hold the copyrights to their own works. Please contact the author of any article for details. ![]() |
![]() |
|