You've probably read some articles or heard people discussing the merits of object oriented programming and design for application development. While most of the arguments for OO are quite valid many FoxPro folks that I've talked to are not quite sure what to make of this new implementation of the FoxPro language and have many questions that have not been addressed vehemently. How is OO different than the procedural code that we've been writing for years? How can it help you be more productive and provide the tools to build more robust applications? How can you get there gradually, without throwing away your existing investment in FoxPro knowledge?
In this article and this month's user's group meeting I hope to answer these questions and more to get people excited about OO technology and the implementation in Visual FoxPro. I also want to provide you with some examples of how you can put the new tools and technology to work to provide you with some ideas to make you more productive.
Why change your Orientation?
Let me start of by stating that procedural code is not dead, just because VFP comes along and provides OO extensions! In fact, even when you use classes to implement applications or components you will end up writing a lot of procedural code as part of the actual implementation code of your class methods (or class specific functions). In that respect your existing knowledge of the FoxPro language is very important, as much of the guts and low level operational logic of an application is still put together with procedural code!
So what's all the excitement about then? The benefits of OO come on an abstract level. The biggest issues that software development faces nowadays are related to creating applications that are more maintainable and can be created quickly. OO techniques strongest point is that it can provide the functionality to let you create component based applications, with the ability to create the components in such a manner that they can be easily reused in the same application or future projects.
OO also provides an indirect benefit: It forces much closer focus on design than on implementation. Designing classes that are modular and reusable requires the design to be well defined before coding begins and often forces you to take a step back and look at how all the pieces of an application (and the classes libraries that it's comprised of) fit together. At first glance this doesn't sound like a benefit - after all additional design means more work. But the benefits of this approach are substantial: The object based design approach lets you efficiently break an application down into its components that can be built and implemented incrementally - the cornerstone of Rapid Application Development (RAD). Objects can be grouped together into higher level objects that provide enormous functionality with very little code. Furthermore, the emphasis on a clear design can provide you with a much more robust and maintainable solution to be supported after the initial app installation. Finally, reusability and extensibility of the business and library objects you create can save you an incredible amount of time in future applications.
All of the benefits of OO come at a price though. When getting started with OO there is a conceptual learning curve that has to be climbed. Thinking classes and objects requires a slightly different mindset than procedural code as well as more discipline for bullet proof coding practices. The entire idea of OO is based on the concept of black box code, and buggy code is not going to fit well into a resusable framework. Another slight hurdle is the terminology which turns many people off early on. Yes, there are a handful of terms that are essential to understanding how OO works, but they're nothing that you can't pick up in an evening with a beginning OO book or our next user's group meeting.
Keep in mind that using OO in your applications is likely not going to pay off on the first application you build! Building resusable tools and components requires additional time for design and experimentation the first time around. Many classes I've designed have gone through 3 full rewrites before getting them 'right'. It'll get easier once we've gone through the process a few times. The payoff for using OO techniques doesn't show until you are into the next project that can take advantage of the resusable components. When the payoff comes, though, it's usually quite dramatic!
Just like everything else, learning by doing is the best way to truly get a feeling for the power of OO. No textbook or lecture can convey the lightbulbs that go off in your head when you actually use OO techniques to accomplish a task and then turn around and reuse the tools, perhaps with a slight modification, writing only a minimal amount of code.
As I mentioned above there are a handful of words that are important to understand when talking about OO concepts. The following sections introduce some of these terms and concepts.
Classes and Objects
OO is based on the concept of classes and objects. Think of a class as a blueprint or design plan - a template that is used to build or create a live object that you actually use in your application. The class is the abstract piece that contains the template for the data structures (called properties) and the code (called methods) that makes up the functionality of the class. Properties are essentially variables that are scoped to the class and methods are functions that can be accessed only in conjunction with the object that defines them in its class definition. To put it in perspective take these real world class/object relationships: Cookie cutter (class) and a cookie (object instance - note you can have mulitple cookie instances), blueprint (class) and a house (object) …
The behavior of an object is always defined by its class definition. An object is an instance of a class, that is actually used in your application. When you use an object, you interact with its methods and properties which are defined by the class definition. Since an object is self contained it's possible to have multiple instances of a class running at the same time without name conflicts. When referencing object properties and methods you always preface the property or method with the name of the object.
For example:
oForm=CREATE("MyForm") oForm.top=10 oForm.left=10 oForm.Show()
If you take a close look at the VFP implemented built-in classes you'll find that many objects provide the same kinds of properties and methods. For example most data entry objects have Refresh, GetFocus() and LostFocus() methods, and top, left and value properties. It's a matter of consistency and name association that makes it much easier to incrementally learn object syntax. You'll find that after a while of working with objects you'll always design logical properties and names into your classes to make them easier to use.
Encapsulate your Code
Classes allow you to encapsulate functionality much more cleanly than you ever could before using plain procedural code. In the past function libraries have been the mainstay of modular programming techniques. The problem with this approach is that there is no direct relation between the functions in your libraries. In order for functions to communicate with each other, klunky interfaces of long parameter lists or global variables are often necessary to make the pieces work together, creating dependencies which are difficult to debug when something goes wrong.
Classes on the other hand allow you to keep data and code together so that all methods of a class have access to the common, class-internal data. Since the data is scoped to the class and can be made completely private (called Protected properties and methods) to the class it's also possible to create multiple instances of the same class without running into variable name conflicts.
Classes also provide a mechanism of initialization and cleanup using special methods that are called when an object instance is created or released. These Constructor and Destructor methods (in VFP these methods are named Init and Destroy) allow your objects to clean up properly after themselves even in unexpected exit situations like an error.
This self-containment and cleanup concept is one of the most important in OO and is known as Encapsulation. To me this is probably the most exciting aspect of OO, because for the first time it's possible to build complex library objects in FoxPro that can have an easy to use, logical programming interface, along with a reliable method of cleanup even in unexpected code situations.
Extend and Enhance with Inheritance
Another all important aspect of OO is Inheritance. As the name suggests inheritance allows your classes to inherit data (properties) and code (methods) using a concept known as subclassing. Subclassing allows you to create a new class based on an existing class (both built-in or user defined) by extending or changing the behavior of the original. Where encapsulation provides the means to build fully self-contained classes, inheritance provides the ability to extend the existing capabilities of a class without touching the code in the original.
When a class is subclassed it inherits all the methods and properties of the original. Subclasses can extend the functionality of its superclass (the class that it's based on - this is also know as a parent class) by adding new properties and methods. In addition, superclass methods can be overridden simply by creating a new method with the same name in the subclass. When calling the method from an object derived from the subclass only the overridden method will be executed unless you explicitly call the superclass method.
In order for inheritance to work best, it's extremely important to design class methods in small, modular fashion so that you can override very specific functionality without having to re-invent the wheel or cutting and pasting loads of code.
The concept of Inheritance is all-important to creating class hierarchies that branch out from the most common functionality to the most specific functionality. Take a simple example of a textbox class. You could start with a very basic textbox class that provides all of Visual FoxPro's basic functionality plus a couple of preset properties like the font size, borderstyle or color. You could then build a subclass that provides a date field textbox, which could provide automatic popup of a calendar or shortcut keys like those in Quicken to quickly change dates. Another subclass of the textbox might be a numeric version of the textbox that pops up a calculator. You could further specialize the date and numeric textbox classes by creating a bound data class which might provide automatic creation for the text labels based on the data dictionary definition… I'm sure you can think of more specialized instances of a textbox class.
Making a programmatic change at the lower level of the hierarchy automatically changes the behavior of related classes further up the hierarchy (remember the class layout is from most simple to most specific behavior). For example, if you all of a sudden you decide all your input fields need to override the ENTER key so it doesn't close the active form, you could do so with the Keypress method of the textbox class defined at the bottom of the hierarchy and have it ripple through all objects that you have derived from any class in textbox hierarchy! Code is changed in only one place, but it affects every object derived from this class or one of its subclasses! Can you see the implication on maintainence here?
Once specialized subclasses have been created you can use them as if they were regular Visual FoxPro interface objects simply by dragging and dropping them onto a form as you would with Visual FoxPro internal (or base class) controls. But inheritance goes far beyond interface objects of course. You can also create custom classes that define a business process or classes that map to a real world programming interface. In all cases you can extend existing classes by subclassing and adding properties and methods and overriding existing methods by simply creating new versions in the subclassed definitions. Very powerful stuff!
What's next?
It's important to understand that moving to OO from a procedural background is not something that will happen overnight. But neither is it a very difficult step as long as you keep an open mind to new concepts and the idea of having to spend a little more time prior to coding to think over your design. The power OO brings to your toolkit can only be realized if you understand the implications.
I've tried to give you a very general introduction to what I think are the most important aspects of OO for use in everyday application programming work. I'll discuss more of these and how to implement them in Visual FoxPro in this month's user's group presentation. In the meantime, if this article has inspired your interest in OO you can dig out your VFP developer's guide and look at the Designing Classes chapter. This chapter is quite good at explaining how to create classes, subclasses and how objects relate to each other using containers and class hierarchies. If you're interested in reading up on OO in general, here's a short list of books that I can recommend:
Object-Oriented Technology: A Managers Guide by David A. Taylor, Ph.D. Addison-Wesley, ISBN 0-201-56358-4
This is a great introduction to the concepts of OO and its terminology. It's written in a very readable format and covers all the major aspects of OO in a fairly small book that can be read in one night.
Object-Oriented Information Systems: Planning and Implementation by David A. Taylor, Ph.D. Wiley, ISBN 0-471-54364-0
This book picks up where the Manager's Guide left off and gets down to the details of how OO can be applied to application design. Examples are given and sample classes designed. Again this is fairly readable book, which makes it one of the more usable OO texts.
Object-Oriented Systems Design: An Integrated Approach by Edward Yourdon Yourdon Press Computing Systems, ISBN 0-13-636325-3
Another mid-level OO text that reviews the various OO implementations and notations that are commonly used. It compares methods, terminologies and goes through the design of a couple of very different applications.
Design Patterns by Gamma, Helm, Johnson, Vlissides Addison-Wesley, ISBN 0-201-63961
If you're on your way to serious OO design, this is the book to check out. Design Patterns describes in great detail how to use different methodologies (or patterns) of object relations to apply to specific design problems. This book has a lot of variety and many detailed ideas and concepts that can help you design more re-usable and maintainable code. This is not an easy read - it took me two reads to grasp most of the concepts, but it's worth the effort.
