Introduction to OOP with Visual Foxpro

Introduction to OOP With Visual FoxPro

An Introduction to Object Oriented Programming

With Visual FoxPro

HHHH

Introduction to OOP With Visual FoxPro

Table of Contents

Introduction 5

Part 1 - OOP Concepts 5

The OOP Paradigm 5

The Paradigm 6

Object Oriented Design and Analysis 6

Object Oriented Programming 7

Characteristics of an Object Oriented Language 8

Abstraction 8

Encapsulating Data and Functionality 10

Classes, Inheritance, and the World Model 11

Polymorphism 12

The Program/Data Dichotomy 12

The Development Cycle 14

Top-Down Design With Top-Down Programming 15

Object-Oriented Programming in VFP 15

Summary 16

Part 2 - Applying the Concepts 18

Building the Foundation 18

Step 1 - Start With the Most General Data 18

Step 2 - Define Methods and Properties 19

Step 3 - Write Some Code 20

Step 5 - Move to More Specific Representations 25

Step 7 - Write some more code 26

Step 8 - Get Even More Specific 27

Step 9 - Write Some More Code 27

Step 10 - Creating the Database 29

Using our Objects in Code 30

Part 3 - Bringing it all Together 34

Some Things to Try 34

Bibliography 35

Appendix 36

Introduction

The purpose of the paper is to introduce you to the concepts of Object Oriented Programming using Visual FoxPro. This paper is intended as an introduction to Object Oriented Programming for individuals who have some understanding of programming but not necessarily any background in Computer Science or Object Oriented Programming theory. The intent here is to familiarize you with the concepts of Object Oriented Programming to help you understand the object model that is an integral part of the Visual FoxPro.

Part 1 covers the concepts of Object Oriented Programming and provides the background needed for Part 2. In this part I define the key characteristics of an Object Oriented Language and the terminology necessary to understand Object Oriented Programming.

Part 2 explores how these concepts are applied in Visual FoxPro by working through an example. In this part we will develop a library of objects and a very simple application using the objects in our library. The sample code used here is designed to demonstrate specific concepts and is not intended to represent a preferred method or approach to programming in Visual FoxPro.

My hope is that after reading this paper and working through the example you will have a clear picture of what an object is, what properties and methods are, and how objects fit into the picture of application development in Visual FoxPro.

Part 1 - OOP Concepts

The OOP Paradigm

In their book, “An Introduction to Object-Oriented Programming and Smalltalk," Lewis J. Pinson and Richard S. Wiener give us the following definition of Object Oriented Programming (OOP).

“Object-oriented programming is defined in its purest sense as programming implemented by sending messages to objects. With this definition, problem solutions that use object-oriented programming principles consist of identifying the objects, messages, and object-message sequences to effect a solution. Object oriented programming is further clarified by a discussion of the properties of objects. Computer languages are object-oriented if they support the four specific object properties called abstraction, encapsulation, inheritance, and polymorphism.”

A key point here is the qualifier “...in its purest sense...”. Visual FoxPro is not an Object Oriented Language (OOL) in the purest sense of the term. Visual FoxPro does support abstraction, encapsulation, inheritance, and polymorphism, but it doesn’t enforce Object Oriented Programming methodologies. You can choose to follow the OOP paradigm or not and still write efficient programs with Visual FoxPro. It does, however, provide us the capability to implement nearly pure object-oriented systems if we choose, and that is the focus of this document.

The Paradigm

Object Oriented Design and Analysis

The Object Oriented Programming paradigm encompasses Object Oriented Analysis (OOA), Object Oriented Design (OOD), and Object Oriented Programming (OOP). The principles, and methodologies of this paradigm have been used for years in the design of micro chips, studied extensively in academic circles, and have most recently found their way into commercial software development.

Object Oriented Analysis (OOA) is the analysis and specification of information systems. OOA addresses the problem of correctly abstracting real-world situations into object-oriented computer models. Its focus is on analyzing real-world systems to determine how best to accurately represent them in an Object Oriented model.

Object Oriented Design (OOD) is the process of formalizing the model in an Object Oriented Language (OOL), that is, designing the software necessary to represent the real-world model. Both OOA and OOD involve modeling real-world systems using object-oriented methodologies. The primary distinction between these two is that OOA is focused primarily on going from the real world to the model and OOD is focused on going from the model to the computer system. In practice this distinction may not be so clear.

The customary approach to software development involves top-down design followed by bottom-up programming. That is, the system is designed by starting with the most general statement of purpose and continually refining and modifying until an agreed upon specification is reached. The specification is then handed off to programmers who build data structures, and functions to work with those data structures, and functions to work with those functions, and so on, until a working program is achieved. In actual practice it isn’t this simple. Typically development goes through a cycle of design, implementation, and refinement.

If the system is well defined and carefully programmed this process results in an efficient and correct program. Contemporary structured languages and modular coding techniques have helped us build libraries of efficient, reusable, and portable code which has had a significant impact on the software development industry. OOP doesn’t replace this—it builds on it.

In the Object Oriented approach the goal of the design process is a set of objects and message sequences that can be used to solve the problem at hand. The objects in an Object Oriented (OO) system are models of the things that make up the real-world system. For example, an accounting program for a business is a model of the employees, products, equipment, and actual accounting practices that make up the accounting system currently followed by the business.

Object Oriented Programming

Object Oriented Programming involves creating objects that represent the people and things that make up a real-world system and then defining message sequences that, when executed, result in a computer solution to a real-world problem. In the OOP paradigm we focus our attention on the objects that make up our system and encapsulate within them all the data and functionality they require to accomplish whatever it is that they are designed to do. Program tasks are accomplished by sending messages back and forth between the objects that make up the system. For example, when you need customer information, you instantiate a customer object and request the information you need from it.

In the non-OOP world, our focus is primarily on the tasks and the functions necessary to accomplish those tasks, rather than the parts (or players) that perform those functions. Programs call procedures or subroutines to work with the data used by the system. These procedures may in turn call other procedures which may call others, and so on, in a very complex web of procedure calls that makes up the algorithm that solves the problem. In this structured procedural approach we must be more aware of how each procedure affects the system and data to avoid introducing new problems when making changes, additions, or repairs. How things are done becomes as important as what is being done by which part of the system. Object Oriented Programming doesn’t replace this, it expands it to an even more structured level.

In an OOP system the data and the functions we need to work with that data are encapsulated in objects. Our primary focus is on the players rather than the details of how they interact. Once we encapsulate data and functionality into an object, programmers can work with these encapsulations (objects) in much the same way they would work with their real-world counterparts. That is, the programmer who needs to determine a part number can call on the Part object for its part number just as they would in the real-world by looking at the part to get the number inscribed on it. Another equally important aspect of this encapsulation is that other parts of the system can access data through the object without risk of corruption or loss. Rather than writing new code to access data, any programmer who needs information that is already encapsulated simply instantiates the object that encapsulates the data they need and uses that object to access the data.

To summarize, Object Oriented Programming is a paradigm shift from a function-centric approach to an object-centric approach to software development. That is, instead of focusing on the underlying bits of data and procedures to work with that data, we focus on who or what works with the data, and embed the details within objects. In the object model, data and the functionality specific to that data are bundled together (encapsulated). Once this encapsulation is complete, programmers are freed from thinking about the details of how the object works with the data, and can focus on what the object does. This allows designers and programmers to think in terms of real-world objects rather than the details of how the computer stores and manipulates data.

Characteristics of an Object Oriented Language

Abstraction

Abstraction is the process of modeling what’s important to us about a real-world system in a computer representation of that real-world system. A language that supports Abstraction is one that allows the programmer to create representations of the various components that make up the real-world system. In an Object Oriented Language those representations are objects.

In the following figure the real-world objects are mapped to data in tables that represent those objects. Each table is an abstraction of the real-world thing that it represents.

Figure 1. Abstraction maps real-world objects to computer models.

When modeling or abstracting, we start with an analysis of the real-world system and determine the appropriate parts necessary to create each piece of the computer model. Whether following OOP or non-OOP, this typically involves a top-down approach. That is, we look at the more general aspects of the system, determine the appropriate models, or parts, and then refine those models into their appropriate component parts. In the non-OOP world, those component parts can be modules, procedures, libraries, or any combination of these. In the OOP world, these component parts are objects.

Figure 2. In OOP, abstraction involves modeling real-world systems into objects that represent the actors and actions that make up those systems.

Figure 2 shows how a real-world Accounts Receivable system could be mapped to an OOP model. The arrows indicate how information might flow through the system. In this model, each object represents some specific entity in the real-world system. It’s important to note that the objects could represent a person, a department, or an automated order entry system that the customer uses via telephone.

Suppose you want to create a program to help you manage an apple orchard. Following the OO paradigm you would look at the real-world things you want to model, in this case apple trees, or more specifically a collection of apple trees. Each tree has certain characteristics that interest you. For instance, each tree has height, age, a history of health, an average annual yield, and so on. You represent an apple tree with an apple tree object which encapsulates, or contains, all these characteristics. Your model of an apple orchard is simply a collection of these apple tree objects. Once you have designed the apple tree object you can use it in any part of the program, or another program, that needs information about apple trees, without duplicating any code, and without digging back into how the details of that information were obtained or stored.

Encapsulating Data and Functionality

To say that OOP allows designers and programmers to think in terms of real-world objects is not to say that they never have to write functions and procedures. What it means is that once you have created the necessary data structures and functions for a particular object you need never duplicate that code in other parts of your program or other programs. Any system or part of the system that needs information about the real-world thing that your object represents simply asks your object for it. The data, and any functions necessary to work with that data, are encapsulated within your object. Your object is an independent self-contained unit, ready to respond to any legitimate request presented to it.

Returning to our apple tree object. It has certain characteristics or properties that define it as a particular apple tree. Within the orchard any tree can be located by a specified set of coordinates; for example, the third tree in the second row. To represent this in our model we include Row and Position properties.

Figure 3. Encapsulation of an Apple Tree object.

To determine the average annual yield of an apple tree we could count the number of apples harvested from it over a period of years and then take the average, or we could calculate some statistical average based on the number of trees in the orchard and the total annual yields for the orchard over time. The approach we take only matters when we design the apple tree object. Once a choice has been made and implemented, we simply ask an apple tree object for its average annual yield and it returns a number that represents this statistic. How this statistic is obtained is part of the functionality built in, or encapsulated in, our object. No other object need know or care how we get the number; just that we do, and that it’s available for the asking.