Object Visibility and Availability


In preparing to write this section, I reflected on my legacy mainframe COBOL days. I pondered the questions "When did we ever have to deal with visibility or availability of components ?" and "When, on the mainframe, did we take into consideration the exposure and access of a component (or even the attributes of a component)?"

Mainframe Analogy: JCL and PROCs

One possible answer to these questions can be found in the legacy mainframe coding of JCL Jobs and procedures. Say that you are preparing to use a JCL Procedure (JCL PROC) in a particular Job. As you know, it is very common to use JCL overrides and symbolic variables in your Job to override portions of the PROC. Using either approach you can override EXEC statement parameters, OUTPUT JCL, and DD statements. However, there is a limit.

While all of the internal JCL portions of the PROC are visible (Public) to the external JCL job, the PGM parameter (alone) is the one portion of the EXEC statement that is not available for override ( NotOverridable ). On the other hand, all of the remaining JCL parameters are available for override ( Overridable ). Reflecting on this typical JCL scenario (as an analogy) will support further discussion on the visibility and availability of objects.

So, there is at least one possible answer to the question of whether the legacy mainframe coding arena dealt with visibility and availability of components. This JCL analogy speaks to that. I actually have another analogy that will help drive the point home. Let's (re)visit the practice of legacy mainframe COBOL programs calling subprograms.

Mainframe Analogy: COBOL Subprograms

Imagine, if you will, that you are creating a rather useful legacy mainframe COBOL routine. Wanting to move in the direction of code reuse, you design the routine to be used as a subprogram. Potentially, several other "main" programs will call [6] your subprogram. Typically, what design choices have you made (in your subprogram) to make all of this possible?

At some point in your subprogram design, it is likely that you made a decision to declare certain fields (variables) in your Linkage Section and other fields in your Working-Storage Section. As you know, this is the way that you make certain fields visible to any calling program while leaving others hidden. Those declared in the Linkage Section (exposed) would then be visible (Public) to the outside world. A calling program (calling the subprogram) would not "see" the (Private) fields defined in the Working-Storage Section.

Note  

When you work with legacy mainframe COBOL subprograms, the calling program has a choice of whether to include any of the following "Using By" clauses: BY CONTENT, BY REFERENCE, or BY VALUE (with BY REFERENCE being the default). Naturally, any senior-level legacy mainframe programmer is already familiar with this COBOL coding convention. This is a good thing. It makes it much easier for you to understand the concept of using the ByVal and ByRef coding options on the .NET platform. Just be aware that value type objects and reference type objects behave differently depending on whether you have passed them as ByVal or ByRef. Also note that ByVal is the default on the .NET platform.

Alternatively, you may have worked with the COBOL COPY statement (instead of the CALL statement). Still in the spirit of code reuse, you may have had components shared between programs in the form of copybooks. [7] Well, how about those times when you included the REPLACING clause on the COPY statement? You would have used the REPLACING clause to cause your COPY statement to "modify" all matching text inside of the target component ”that is, all matched text that was "available" for update. Besides that, if the targeted component (to be copied ) was nested, then all bets were off and the REPLACING clause simply could not be used. Thus, depending on established criteria, the contents of the targeted component were either Overridable or NotOverridable .

Point made, right? Perspective established, correct? Good. OK, let's return to the twenty-first century and .NET. The following sections introduce you to the terminology used in COBOL .NET and VB .NET programming in the context of object visibility and availability.

Object Access and Scope

The terms "scope" and "access" are used interchangeably. Both terms speak to the determinable extent to which an object is visible or accessible. For defining scope attributes (or access attributes), COBOL .NET and VB .NET both use syntactical terms such as Private, Public, and Protected.

The Public access attribute provides for the highest degree of visibility and access. The Private access attribute is the most restrictive , providing the least amount of visibility.

In the case of COBOL .NET, these access attribute terms (Private, Public, and Protected) apply only to the class's methods . On the other hand, VB .NET allows these same access attributes to also be used at the class, structure, enumeration, property, and field levels. Additionally, VB .NET includes the Friend and Shared access attributes. Both COBOL .NET and VB .NET implement an additional "access attribute": Static .

Tip  

You will find that the Static access attribute is an opportunity for confusion. Understand that the access attribute of Static in COBOL .NET is equal to the access attribute SHARED in VB .NET. Usually when you see the term "static" used in the Class Viewer and other .NET tools, it will most likely be referring to the COBOL .NET definition of Static. On the other hand, when you see the term "static" used in the VB .NET context, the definition is completely different than COBOL .NET's. The way that VB .NET defines a Static access attribute specifically applies to VB .NET. For further details on this subject, please take advantage of the references provided at the end of this chapter in the "To Learn More" section.

Basically, a Static (or Shared in VB .NET) variable is instantiated once per class. The content is then visible to all instantiated objects (of that same class). In the COBOL .NET context, Static is used when defining a class. Optionally, you can include a Static Definition for data and methods within the class. In VB .NET, you can use the Shared (equivalent to Static in COBOL .NET) access attribute only at module, namespace, or file level ”in other words, everywhere except inside of a procedure.

At a high level, almost in summary fashion, you have been introduced to object visibility. Is that a lot to digest? Understanding will come with practice and experimentation. Additionally, I believe that you will find the following Tip rather helpful.

Caution  

You can consult the Fujitsu NetCOBOL for .NET Help text along with Microsoft's VB .NET Help text (both via Visual Studio .NET) for further details. Additionally, I have included URLs in the "To Learn More" section ("Web Sites" subsection) at the end of this chapter for your continued learning on the topic of access attributes. In fact, the URLs present a chart-style display that you can print out for frequent cross- referencing.

Availability via Object Orientation

In the two previous mainframe analogies (presented in the sections "Mainframe Analogy: JCL and PROCs" and "Mainframe Analogy: COBOL Subprograms"), the terms Overridable and NotOverridable were introduced. Guess what? I have a surprise for you! You were actually introduced to the term Overridable much earlier in this chapter. Recall the section "Where Do Objects Come From?" where I discussed System.Object? There was a section of code displayed from the Class Viewer tool similar to Listing 9-17.

Listing 9-17: A Portion of System.Object As Shown in the Class Viewer Tool Output
start example
 . . . (5) // Methods (6) public virtual bool Equals(object obj); . . . (8) public virtual int GetHashCode(); . . . . . . (11) public virtual string ToString(); (12) // end of System.Object 
end example
 

Notice that lines 6, 8, and 11 include the word "virtual." What is the significance of this? Well, virtual is the C# (and C++) term for Overridable.

Tip  

See the "Web Sites" subsection of the "To Learn More" section at the end of this chapter for a useful URL that should ease the translation of key terms from one .NET language to another.

All right, you know that a method can be Overridable. So what, right? Again, I will refer back to one of those .NET retraining prerequisite topics presented in Chapter 4. In this case, I'm talking about object orientation. So, you ask, what does object orientation have to do with object availability?

Using the System.Object class as an example, the three methods marked "virtual" are made available to other classes as Overridable. In order for this to become relevant to other classes, the System.Object (base) class would first have to be inherited by the "other" classes. When you are talking inheritance and base classes, you certainly are talking object orientation. What's more, whether a member is Overridable or not is just scratching the surface in terms of object availability.

As with object "scope" (discussed earlier in the section "Object Access and Scope"), there are various levels (or degrees) of object availability. Though I prefer not to repeat the entire object orientation content presented earlier in the book here, I do feel it is useful to emphasize the applicability of the topic in this context. To affect object availability, you will expose (or hide) members of a class (using any of the Override- related keywords). On other occasions, you may choose to "add" functionally new objects to a class (using the Overloads and/or Shadows key-words). Yes, your focus here is on "the object," yet you have proven that eventually you will go full circle.

start sidebar
Going Full Circle Around the Object

In order to program on .NET, you really need to understand what System.Object is. That will lead you to understanding the difference between the value type objects and reference type objects. In order to effectively use these objects, you need to understand how to influence their scope and availability. Once you have gone that far down the path , you are not only programming the .NET way, you are programming the object-oriented way.

end sidebar
 

[6] To settle your curiosity , in the context of this analogy, it would not matter if you were designing the subprogram to be called/linked dynamically or statically.

[7] I am loosely using the term "copybooks" to include legacy mainframe COBOL copybooks targeted for the Environment, Data, and Procedure Divisions of a consuming program.




COBOL and Visual Basic on .NET
COBOL and Visual Basic on .NET: A Guide for the Reformed Mainframe Programmer
ISBN: 1590590481
EAN: 2147483647
Year: 2003
Pages: 204

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net