Object-Oriented Programming

The first time that someone tried to explain object-oriented concepts to me was several years ago in a Visual Basic class. I remember sitting there with a blank look on my face as the instructor used analogy after analogy to help the class grasp this new concept. The instructor's presentation went something like this:

"Class, let's explore some of the basic object-oriented concepts. Thefirst one is the idea of a class and an object. Now, I want you to imagine that you are an architect who has designed a blueprint to build ahouse. With that blueprint, you can create an unlimited number ofhouses ”each house would be identical to the next . According to yourblueprint, each house would have the same number of windows ,doors, and so on. Therefore, by following this analogy, the blueprintwould mimic the general idea of a class. Each house that you created, using the same blueprint, would mimic the general idea of an object. In other words, an object is like a copy (an instance) that wasbased on a model or template (a class)."

Tip  

Although it is possible to create a .NET program without good object-oriented design practices, this one characteristic will separate efficiently designed, scalable, and maintainable .NET applications from all the rest.

The Visual Basic instructor then went through several other analogies before we finally "got it." Probably the most amusing (attempted) analogy was one in which the instructor asked a student to stand up in front of the class. The instructor then started to point out the characteristics (properties) of the student. As the student blushed, the instructor proceeded to ask the student to do all sorts of weird things (e.g., jump up and down, wave his arms, and so forth), which were supposed to demonstrate the idea of object-oriented methods . This analogy had taken a wrong turn somewhere. The instructor then switched course and went on to two other analogies. In one of these analogies, he described cookie cutters (as an object-oriented class) that created ( instantiated ) copies of cookies (objects).

The last analogy that I remember the instructor trying was that of an automobile factory assembly line. With this assembly-line analogy, the instructor described how each automobile (object) rolling off (being instantiated) the assembly line matched the master specification (class). The features (properties) of the automobile would match from one automobile to the next. The instructor explained that a person could make different types of requests (methods) of the automobile (e.g., opening a door, closing a door, pushing the horn, turning the key in the ignition, and so forth). I have to hand it to the instructor for not giving up.

Note  

Generally , object orientation is object orientation. However, there can be a difference in the degree of the orientation (i.e., how strict the adherence is). For example, the .NET Framework thoroughly implements object-orientation practices. However, older versions of Visual Basic only partially implemented object-orientation practices.

In keeping with tradition (and in honor of all of those instructors out there struggling to teach the programmers of tomorrow), I will offer up my own analogy to help explain object orientation: the mainframe Job Control Language (JCL).

A Mainframe JCL Analogy

I will begin by stating that all mainframe programmers (unknowingly) have been using object orientation practices since the beginning of time (back when key-punch machines and UNIVAC computers were among us). One of the key areas of object orientation concerns the idea of flexible component reuse. Think for a moment about the Job Control Language Procedures ^[3] (JCL PROC) that every mainframe programmer has used through the years.

Note  

How ironic that JCL, which helped with your introduction to mainframe programming, will now help with your departure from mainframe programming.

Recall that one of the great things about a JCL PROC was the advantage of flexible component reuse. You could create one JCL PROC ”a general one. Then, through the magic of symbolic substitution and JCL override (some creative JCL wizards even incorporated JCL INCLUDE members within their PROC), you would customize the JCL with "temporary" changes. Each individual executing Job then would create its own virtual/in-memory copy of the JCL PROC. Each customized step would execute for the specific needs of the particular executing Job. The executing steps essentially defined the behavior of the PROC and thus the behavior of the executing Job. Additionally, the executing Job would have ultimate control over which PROC steps executed (using JCL COND parameters).

One of the other great things about the JCL PROC was its capability to free programmers from having to worry about some of the unpleasant details involved in implementing a particular series of JCL PROC steps. The user of the PROC would need only minimal information (i.e., the name of the PROC and any necessary input symbolic parameters) to use the PROC. In this approach, mainframe programmers would use the JCL PROC as an extendable, customizable package of JCL statements.

As it turns out, the knowledge that you have from your mainframe past (even with JCL) will greatly assist your understanding of the object-oriented way of doing things in programming code. This JCL analogy may sound like a very abstract stretch (by the way, abstraction is part of OOP). For now, I touch briefly on each OOP topic in the sections that follow. The full applicability of object orientation will be further exploited throughout the remaining chapters of this book.

Extending the JCL Analogy to Introduce Key OOP Terminology

Well, now I (just like my Visual Basic instructor) have used an analogy to help explain the concept of object orientation. I can only hope that the use of JCL (a familiar technology) assisted in that high-level review. Now, let's drill down a bit into some of the specific portions of the OOP methodology. The following list ^[4] and the respective sections that follow present the basic OOP terminology that you will come across when you are developing on the .NET platform:

• Class

• Property

• Method

• Class library

• Base class

• Instantiation of objects

• Object construction

• Object finalization

• Inheritance

• Encapsulation

• Abstraction

• Polymorphism

• Overriding and overloading

• Shadowing

• Unified Modeling Language (UML)

Class

In my analogy, the general PROC served as a template. From this template, virtual copies are produced and customized. When you design applications to solve real-life problems, using the object-oriented approach is significantly different from designing the structure of a PROC (or a structured program, for that matter). A PROC (my analogy of a class) generally is designed around functionality.

However, in general object-oriented approaches, functionality would be the responsibility of the methods. Think of object orientation in terms of nouns, verbs, and adjectives. A class typically represents the noun. In subsequent chapters, you will learn that the .NET Framework offers various types of classes/objects (value types, structure types, reference types, and so forth) that are each unique for different programmatic uses.

Property

Using the noun-verb -adjective approach again, a property represents the adjective of a class. Using the JCL analogy, the names of the PROC and JCL steps, and the names of the parameters available for symbolic substitution and overriding, would all mimic properties of a class.

Method

Using the noun-verb-adjective approach one last time, a method represents the verb of a class. In the mainframe JCL analogy, the JCL executable steps mimic the ability to invoke a class's methods. In subsequent chapters in this book, you will be further introduced to the various types of methods and the different ways to invoke them.

Class Library

Generic PROCs are stored in a PROCLIB library. In OOP, this library is referred to as a class library. In fact, the entire .NET Framework is one big class library filled with classes and objects that you will use. In addition, you will create your own classes (that inherit from classes in the .NET Framework).

Base Class

In OOP, the class library takes on a hierarchical structure/relationship. As an example, imagine if there was a main JCL PROC (at the top of the PROCLIB library) and all PROCs below it inherited basic characteristics from the PROC above, creating a parent/child relationship. In this analogy, the main JCL PROC (the one at the top of the PROCLIB) would represent the parent. The parent is analogous to the base class.

Instantiation of Objects

When a mainframe Job is submitted to the JES2 queue, a virtual/in-memory copy of the generic PROC is created. When you create your .NET applications, you will code programming statements that will cause the creation, or instantiation, of objects. Subsequent chapters will further introduce this topic with code examples.

Object Construction

At the point of instantiation, the construction of the object takes place. Let's say that you have a JCL step named "NEW" that executed automatically ”as soon as the Job is submitted to the JES2 queue. This NEW step would be called your constructor. Any initializing or housekeeping that you want to do could be performed in this constructor step.

Object Finalization

Objects have a limited lifetime. Using the JCL analogy, when a JCL Job's execution is terminated and the in-memory copy (object) of the customized PROC "disappears," all resources ^[5] that the JCL statements had allocated are then released. Right before the in-memory copy of the PROC ceases to exist, if it was possible to execute one last JCL Job step (named Finalize or Dispose ”see the following Note regarding a Destructor method) you would then be going down the path of object finalization.

By the way, additional concepts branch off this topic, for example, deterministic versus nondeterministic finalization and the garbage collector. Chapter 8 expands on these additional topics using a different mainframe analogy: CICS's GETMAIN and FREEMAIN commands for resources management.

Note  

At the time of this writing, it appears that the J4 Committee is in serious disagreement about how to implement all of the object-oriented features into the upcoming COBOL standard. In this case, what is in question is how (or whether) to include in the COBOL 2002 standard a Destructor/Finalizer method. The discussion surrounding the Finalizer method boils down to how the COBOL 2002 language will clean up after itself to free resources: clean up by default, when the program ends, clean up on demand via the call of the Finalizer method, or perhaps clean up periodically via a "garbage collector" when needed.

Now it looks like the J4 Committee has agreed to disagree on the question of standard inclusion for the Finalizer method. The J4 plans to create a technical report separate from the upcoming COBOL 2002 standard that will address the fate of the Finalizer method. That is too bad. My guess is that this will make it rather easy for the skeptics (and the OOP purists ) to criticize the partial implementation of object orientation in the COBOL 2002 standard. ^[6]

Cross-Reference  

For more information regarding the J4 Committee's discussion on the Finalizer method and their technical report, please see http://www.ncits.org/tc_home/j4htm/m230/01-0079.doc , http://www.ncits.org/tc_home/j4htm/m230/01-0081.doc , and http:// www.microfocus.com/whitepapers/developmentcobolstandard.asp .

Inheritance

On the mainframe, some of the more advanced JCL users used the JCL INCLUDE statement. With this statement, a JCL PROC can inherit an INCLUDE group, which is usually a group of JCL statements saved in a partition data group member. In .NET, the Framework (class library) offers thousands of classes that can be inherited. Additionally, other classes can inherit classes that you create yourself.

This is the portion of object orientation that fully exploits the idea of flexible code/component reuse. As you might have guessed, this mainframe "analogy" for inheritance is rather scaled-down compared to the real power of object-oriented inheritance. When I discuss the .NET Framework further in later chapters, I dig deeper into the topic of inheritance.

Encapsulation

Say you've created a JCL PROC that has many steps, and each step has many DD statements. Your main reason for creating it as a cataloged JCL PROC is to save others the trouble of reinventing the wheel (or rather, re-creating the same PROC). In effect, you have created an extendable, customizable package of JCL statements, as described earlier in this chapter. Regardless of whether the user chooses to override (customize) any of the statements, the user may be able to just refer to the PROC by name in the Job, execute it, and that's it.

The idea surrounding encapsulation is that of the black box, which furthers the idea of plug and play (with class/objects). You will appreciate this black box approach as you benefit repeatedly from the powerful classes offered in the .NET Framework (without always needing to look too far under the hood of each class/object). By the way, the information that you use to identify a class and its exposed characteristics makes up the interface of the class.

Abstraction

The concept of abstraction works hand in hand with encapsulation. As you go through the process of deciding which properties and methods to expose and which to "hide" in your class, you are assisted along the way by your ability to abstract the "important" characteristics. Given a business problem, an application designer will reduce a seemingly complicated problem down to its most essential characteristics (e.g., nouns, verbs, and adjectives). The result will be an object model of the problem. All of this will occur before any actual program coding is done.

This high-level design approach may remind some of you of the mainframe programming flowcharts that you have created at one time or another. In this case, however, you would create the object model before you would create a flowchart. After you create the object model, it is time to define how the objects relate to each other. This latter design step (defining how objects relate to each other) might be closer to the idea of flowcharting .

Polymorphism

Polymorphism refers to the ability to have a class or any of its members (properties and methods) behave differently depending on how it's inherited (or on how it's implemented). The approach of customizing generic JCL PROCs with JCL override and symbolic substitution leans heavily toward the idea of polymorphism.

Using the mainframe JCL analogy, a given JCL step might behave differently depending on how a particular Job has implemented the override statements. A very common approach that I am sure you have encountered is to have one JCL PROC that has a symbolic substitution parameter that is used to indicate whether the PROC is being used for production or for testing. By overriding the JCL, the behavior of each JCL step will differ greatly, accessing either testing/development resources or production resources.

Overriding and Overloading

Much like the mainframe JCL overriding that I have discussed, when one class inherits from another, you can choose to override the properties and methods of the "parent" class to modify the characteristic or behavior that takes place in the "child" class.

However, overloading is different from overriding . Overloading is more similar to the idea of having one Job step and a series of JCL override statements that override the same step conditionally. As you dig into the practice of inheritance, you will come across .NET Framework classes that have methods that are overloaded. Depending on how you use the class, the method execution will differ. This is good example of polymorphism (discussed previously).

Shadowing

Shadowing is similar to overriding, but it's much more powerful. Let's stretch the JCL analogy a bit. Imagine a type of JCL statement that allowed you to cause all of the PROC Steps and PROC DD statements to be "hidden" from the system. Let's say that this same imaginary JCL statement caused only the JCL override statements found in the JCL Job to be recognized. Well, this is heading in the direction of describing the power of shadowing ”when you're looking for an extended way to override properties and methods that exist in the inherited parent class.

Unified Modeling Language

Recall what I said earlier about the flowcharting that you have done before. Typically, before you created a mainframe COBOL program, as standard practice you would create a flowchart (OK, maybe you just intended to create one). The flowchart did what you would expect from its name: It charted out the flow of the program. Well, I mentioned earlier that the practice of designing an object model is similar to the idea of flowcharting, except that it includes much more than just "the flow." An object model shows everything there is to possibly know about an object. This would include what class the object was derived from, any attributes (properties) and methods, how the object will relate to other objects, and much, much more. Fear not, a language and a tool exist to assist you through your object model design efforts.

Through a collaborative effort, a notation language called Unified Modeling Language (UML) is available to help you with documentation of object models that you create using object-oriented design and analysis methodologies.

Cross-Reference  

UML is now an accepted specification of the Object Management Group (OMG). For more information, please visit http://www.omg.org/uml/ .

In the previous chapter, I mentioned that Microsoft has a diagramming product called Visio. Using Visio, you can create UML object model drawings (see Figure 4-1) to document your object models.

Figure 4-1: A sample Visio UML drawing

But you can do more with this program than just create drawings. Using Visio, you can build a program code skeleton like the one shown in Figure 4-2 from your UML object model drawing. ^[7] That's right ”using this software tool, you can design your entire object model using UML notation, and then with a few mouse clicks you can have all of your program class files created for you. You then simply need to edit your program class files to add in the business rules and program logic. By the way, Visio 2002 Professional ^[8] supports all nine of the diagram types defined by the UML 1.2 specification.

Figure 4-2: The Person class module created from a UML drawing (in Visual Basic .NET)

But Wait, There's More to Microsoft Visio 2002

The features list for the Microsoft Visio 2002 product is extensive . As much as I would like to discuss each feature here, doing so would extend far beyond the scope of this discussion. That said, there are two additional features that I would like to point out:

• You can create many types of drawings other than UML-based object models. To help get you started, Visio ships with various types of sample drawings. In fact, I used one of the sample drawings to give me a head start in creating the drawing in Figure 4-1. Notice the Visual Basic .NET (VB .NET) class (skeleton) that was automatically generated using Visio.

• You can take an existing .NET application with the classes, properties, methods, and program logic created already and then have Visio create the UML-based object model drawing for you. This process is called reverse engineering. Some of you may have had experiences (many years ago) on the mainframe with computer-assisted software engineering (CASE) tools. Some of those experiences may have not been pleasant. Keep in mind that this is a different platform now and the technology has improved.

 

Once you create your Visio diagram, leveraging the full support for UML, you will want to save the diagram. When you proceed to do that, you will be presented with the Save As dialog box. Near the bottom of this dialog box is the Save As Type drop-down list. There, you have many choices to pick from ”everything from the default Visio format (.vsd) to common graphic formats (i.e., Graphics Interchange Format [.gif], Adobe Illustrator File [.ai], and so forth). You can even choose to save your Visio UML diagram in the Hypertext Markup Language (.htm or .html) format. This may be helpful to remember while you read the next section.

^[3] For you JCL purists, I am referring to cataloged JCL PROCs, not instream JCL PROCs.

^[4] This list is not meant to represent a complete list of OOP terms; rather, it is provided as a list of common OOP terminology. I will delay the discussion of persistence and state management until a later chapter (Chapter 16). Although both concepts apply to this OOP discussion, I would rather save them for the user interface section of this book. At that time, I will rely on your familiarity of common mainframe CICS technologies (COMMAREA, EIB, TS queues, and pseudo-conversational CICS design) to assist you in that discussion.

^[5] When you think about "resources," remember that you will soon turn all of your focus toward a program and away from JCL. Start thinking about your legacy COBOL programs and the data that exists in your working storage and linkage section as some of the "resources" that you will be concerned about.

^[6] Just look at how the OOP purists criticized Visual Basic (earlier versions) as not being truly object oriented. Up until recently, Visual Basic lacked inheritance as part of its object- oriented implementation. Now, the OOP purists are satisfied with VB .NET, considering that now it is completely object oriented.

^[7] Of course, you can also do this with other, non-Microsoft software packages. Also, you could do this manually, without the aid of a software tool.

^[8] Visio Professional 2002 is included with Visual Studio .NET Enterprise Architect edition. The code generation and reverse engineering features are applicable to the version of Visio that is bundled with Visual Studio .NET Enterprise Architect edition, but not the Visio 2002 stand- alone version.