The Origin of the Object

The Origin of "the Object"

Many years ago, I was happily programming COBOL batch and CICS applications on the mainframe (before my own reformation ). At that time, I recall the topic of "object orientation" coming up in a friendly workplace debate. My coworkers and I had read how COBOL was going to become an object-oriented language. With much anticipation, we started to discuss the meaning of this "new" way of programming. Oh, how I remember the way we drilled down into defining the words "virtual," "physical," and "logical." All the while, we were trying to apply the "idea" of object orientation to our COBOL 85 procedural/structured code mainframe way of doing things.

As you know, with limited success, object-oriented COBOL eventually became a reality. Also, as discussed (at great length) in Chapter 1, the new COBOL standard has continued in that direction. You have to wonder , why in retrospect have "we" ^[1] struggled so with this subject?

Part of the problem (of course, we did not realize this at the time) was that we simply did not have the "right" context from which to discuss the topic. Hence, the object orientation analogy offered in Chapter 4. Recall that I suggested that Job Control Language (JCL) and its pieces could loosely be viewed as classes, objects, and so forth. Although I still stand behind that analogy, the fact remains that you need to understand more (much more) about objects. Specifically, you need to really understand the .NET objects.

The Elusive Object

If it's any consolation, even the nonmainframe programming community has struggled somewhat with the topic of object orientation. Although the Windows and Web programmers certainly have gotten a head start, even they are learning new things today. For example, the object orientation purist contends that the .NET platform avails a "first-time" opportunity to the Visual Basic programmer to perform "real" object-oriented program design.

Beyond that, others have suggested that if you limit your view of object orientation to the functionality of programming routines, you will miss the more complete object-oriented "business" view. This, of course, speaks to the practice of designing objects that represent entities, activities, patterns, and relationships found in business.

 

That JCL analogy was provided to give you a place to start. Chapter 4's discussion presented a high-level view into object-oriented concepts. I would expect that Chapter 4's high-level discussion answered a few questions. At the same time, though, new questions undoubtedly arose. For example:

• Where do .NET objects come from?

• How exactly do you create .NET objects?

• What types of .NET objects are there?

• How do you handle .NET objects?

Let's now move toward answering these questions.

Where Do .NET Objects Come From?

I start this discussion with the System.Object class, the class from which all .NET objects derive. Listing 9-1 was generated from the .NET Framework's Class Viewer tool. ^[2] It shows the contents of the System.Object class. (The line numbers in Listing 9-1 were added manually.)

Listing 9-1: Output from the Class Viewer for System.Object

 (1) // from module 'c:\winnt\microsoft.net\framework\v1.0.3705\mscorlib.dll' (2)   public class object  (3) // Constructors (4)   public Object(); (5) // Methods (6)   public virtual bool Equals(object obj); (7)   public static bool Equals(object objA, object objB); (8)   public virtual int GetHashCode(); (9)   public Type GetType(); (10)  public static bool ReferenceEquals(object objA, object objB); (11)  public virtual string ToString(); (12) // end of System.Object 

 

Well, from the self-documenting System.Object class name alone, you already know that "Object" belongs to the System namespace. Additionally, from the Class Viewer tool output, you can see in line 1 that this particular Namespace.Class is in mscorlib.dll .

Line 2 indicates that this particular class is Public . This means that the scope of this class is fully visible (I further explain the concept of scope in the section "Object Visibility and Availability" later in this chapter). The next set of code lines, 3 and 4, introduce the topic of constructors. Basically, the constructor is the method responsible for initializing an instance of the object. In the following section, I further discuss the topic of constructors. The remaining code lines, 6 through 11, are a list of methods.

Tip  

As you have noticed, the code output of the Class Viewer tool is in Visual C# .NET (or simply C#). Fear not, Microsoft has provided several very useful translation guides. You can easily translate the C# statements into Visual Basic .NET (VB .NET) statements. I have included the URL that links to this collection of Microsoft documents at the end of this chapter in the "Web Sites" subsection of the "To Learn More" section ( please see the reference for "Language Equivalents"). I am sure that you will find this URL to be worthy of a bookmark.

Using the list of included methods, let's make a few more observations. Notice that lines 6 and 7 both define a method with the name Equals that will return a Boolean type (indicated by "bool"). However, you will notice that the characteristics of each are different (i.e., one of the methods has the attribute Virtual and the other has the attribute Static ” for more information, see the section "Object Visibility and Availability").

Additionally, please note that the static Equals method (line 6) is defined as taking in one input parameter, whereas the other Equals method is defined as taking in two input parameters. These two methods, having the same name and appearing as they do with the other appropriate differences, are said to be overloaded. I discuss this concept further in the section "Availability via Object Orientation" later in this chapter.

Lastly, note the lines 9 and 11 in Listing 9-1. GetType and ToString are two very common methods that you'll see used in various code examples. Seeing them defined here, as methods of System.Object, you now know which base class actually defined these two useful methods. More interestingly, notice that the GetType method is defined to have a return type of Type . On the other hand, the ToString method is defined to have a return type of String . Why do I think this is interesting? Because it actually makes sense, that's why. This isn't always the case, so when it happens, why not acknowledge it?

A Minimalist View

One of my coworkers once stated, "Computer programming is just a matter of moving data from one place to another place." Although that is true, I would like to offer a similar statement, one that reflects a .NET minimalist perspective: ".NET computer programming is just a matter of creating objects and using objects."

 

There you have it. Within those few code snippet lines, you have the object that every (yes, I do mean every ) .NET object is derived from. As you drill down a bit further, you will refer back to the code in Listing 9-1.

Bringing an Object to Life

When I discussed lines 3 and 4 in Listing 9-1, I mentioned the term "constructor." So, you already know that a constructor initializes an object. The other purpose that a constructor serves is to allocate memory on the heap (or stack) for the object in question. In COBOL .NET and VB .NET code, you will recognize a constructor as "a method of a class that happens to have the name of NEW." In other words, when you execute code to instantiate an object using the NEW clause, you are actually executing a method that has the name "NEW." This causes the following to occur:

• Memory is allocated on the heap or stack.

• The object gets initialized .

Let's say for example that a COBOL .NET class had the constructor method shown in Listing 9-2.

Listing 9-2: COBOL .NET Code Snippet Showing a Constructor

 000020 CLASS-ID. AClass. . . . 000400 METHOD-ID. NEW. 000410 DATA DIVISION. 000420 WORKING-STORAGE SECTION. 000430 PROCEDURE DIVISION. 000440* Do something  000450 END METHOD NEW. . . . 

 

Then, it would be reasonable to also use a COBOL .NET statement as shown in Listing 9-3 to create an instance of that class (in other words, to instantiate an object).

Listing 9-3: COBOL .NET Code Snippet Showing How to Instantiate an Object

 . . . PROCEDURE DIVISION. 000260 METHOD-ID. MAIN. 000270 DATA DIVISION. 000280 WORKING-STORAGE SECTION. 000290 01 OBJ OBJECT REFERENCE AClass. 000300 PROCEDURE DIVISION. 000310     INVOKE AClass "NEW" RETURNING OBJ. 000320 END METHOD MAIN. 000330 END STATIC. . . . 

 

Likewise, if you saw a VB .NET class that had the following constructormethod:

 Public Class AClass       Sub New()         ' Do Something       End Sub  End Class 

you might also use the following VB .NET statement to instantiate the object:

 Sub ADifferentProcedure()        Dim AnObject As New AClass() End Sub 

Are you confused now? Are you wondering what the previous code snippets have to do with the System.Object class? Well, since you know that the System.Object class contains a NEW method (a constructor) similar to the ones shown in the previous code snippets, you can visualize the type of method that gets called every time that you instantiate an object.

Let's try a little question and answer (Q&A):

Question 1: What happens if you create a class, but you do not explicitly code a constructor?

Answer 1: The constructor of the base class is implicitly executed.

Q2: Can you pass parameters into the constructor?

A2: Yes. In fact, if the constructor happens to be inside of a value type object, you must have at least one input parameter.

Q3: Can you have more than one constructor in a class?

A3: Yes, thanks to the concept of overloading in object orientation.

Q4: If you have multiple constructors (overloaded), which one is the default constructor?

A4: The default constructor is the NEW method that is defined as parameterless ” in other words, lacking input parameters.

Q5: Why is it that the value type object's constructor cannot be "parameterless"?

A5: The default constructor (the one that is parameterless) is "reserved" for the value type object's initialization needs.

Q6: Why is it that some constructors have as their first coded statement an instruction similar to "Mybase.New()"?

A6: This is true ( generally ) if you define a class that derives from another class. Because constructors are not inherited, you must explicitly execute the constructor of the base class.

Q7: Is there more to learn about constructors?

A7: Yes, but not too much more. This is certainly enough for now.

Now, wasn't that fun? The preceding Q&A list (hopefully) addressed most of your questions about constructors. As you learn more throughout this chapter, some of these answers will become clearer. On that note, I need to clear up one additional point before I conclude this discussion of constructors.

The discussion here has focused strictly on instance constructors . You should be aware of the existence of the other constructor type: Shared constructors . Shared constructors are used to initialize Shared variables, in other words, variables that are declared with the Shared access attribute are Shared variables . Shared constructors provide a convenient way to initialize these types of variables. Access attributes are further discussed in the section "Object Access and Scope" later in this chapter.

Note  

COBOL .NET does not support the creation of Shared constructors. The constructors (methods with the name NEW) that you will use in COBOL .NET are instance constructors. However, you will find that VB .NET does provide support for both types of constructors: Shared and instance.

You will recognize a Shared constructor as a method with the name NEW and the access attribute Shared. For example, in VB .NET, the coding statement to define a Shared constructor looks like this: Shared Sub New() .

When you come across the need to use Shared variables and Shared constructors, please take advantage of the Microsoft Visual Studio .NET Documentation ( ms-help://MS.VSCC/MS.MSDNVS/vbls7/html/vblrfVBSpec7_2_2.htm ). Recall that you can access this Microsoft documentation package (locally, on your desktop) as follows : Click the Start button and select Programs Microsoft Visual Studio .NET Microsoft Visual Studio .NET Documentation.

OK, is that all clear now? Are you totally comfortable with the topics of constructors and object creation? Are you ready to move on to the next section? Great, let's do it.

Tip  

COBOL .NET coding introduces a few special considerations for constructors (i.e., the constructor name "new" must always be capitalized: NEW). Fujitsu has provided a "NetCOBOL for .NET Language Reference" document bundled with their NetCOBOL for .NET product. I suggest that you refer to this document, particularly its last chapter (Chapter 12). This useful document happens to be in PDF format. You can simply navigate to its installed location, which is typically the following: <hard disk>\Program Files\Fujitsu NetCOBOL for .NET\doc\.

^[1] I am using the general reference of "we" to include the average legacy mainframe COBOL/ CICS programmer.

^[2] This tool was first introduced in Chapter 7. It is a command-level tool you use by executing WinCV.exe.