Dicing the .NET Framework


Are you ready to digest another bite of the .NET elephant? OK, it is time to examine the bits that make up this particular byte (bite). Imagine for moment that you are sharing the following feedback about this book with a coworker: "Chris Richardson dices the subject matter into digestible bits." Then you will appreciate the fact that I have created a convenient acronym [1] from this feedback that maps to the parts of the .NET Framework. Taking the five letters of the word "dices" to create the acronym DICES, you can say that the .NET Framework is

  • D elegates

  • I nterfaces

  • C lasses

  • E numerations

  • S tructures

These five high-level groupings make up the types of objects in the .NET Framework. Collectively, these objects are available to you as a class library. The class library is broken down into namespaces. As you can see in Figure 7-1, the .NET Framework is a layer of abstraction that sits between your programming code and the common language runtime (CLR). [2]

click to expand
Figure 7-1: The .NET Framework abstraction layer

Before I interject unneeded confusion, allow me to point out the following:

  • The entire .NET Framework is loosely referred to as a class library, but it does contain more than classes.

  • The classes in the .NET Framework can be base classes or classes derived from base classes.

Now that I have cleared all that up, let's discuss how you might go about learning more about the delegates, interfaces, classes, enumerations, and structures. You will start off with the topic of namespaces. Following the discussion of namespaces, you will drill down further to explore delegates, interfaces, classes, enumerations, and structures.

The .NET Namespaces

For a moment, let's revisit the mainframe analogy of the PDSs that represented an extensive library of reusable modules. On the mainframe, if you created PDSs such as this that you wanted other developers to be able to share, you would have made a few decisions along the way, for example:

  • You would have decided which members (objects) should be organized into which PDSs.

  • You would have decided on names for your PDSs.

  • You would have decided on meaningful names for each member that would be stored in each PDS.

These are exactly the types of decisions that Microsoft apparently faced when they organized the thousands of delegates, interfaces, classes, enumerations, and structures. Their choice was to use namespaces . Fortunately, Microsoft did not stop there.

First, Microsoft organized the namespaces in a hierarchy according to function. Second, Microsoft provided useful tools to assist your research when you need detailed information about namespaces.

Note  

On occasion, you will create your own "custom" namespaces. These custom namespaces are useful as you create code targeted for reuse. Microsoft recommends that the namespaces organizations and individuals create be prefixed with a unique value. For example, the "high-level" qualifier could be the name of your company. This will help distinguish your custom namespaces from those provided by Microsoft (or third-party vendors ). In Chapter 9, I demonstrate how to create custom namespaces.

The Functional Hierarchy of Namespaces

I recently had a .NET- related discussion with a friend of mine. Specifically, we discussed the .NET Framework. As the discussion went on, I found myself involved in a deeper, low-level explanation about individual namespaces. We then discussed how .NET's hierarchical namespace structure would help people locate the appropriate .NET objects and so forth. Continuing our discussion, we started to group the namespaces by function: those for client-side user interface versus those for Web development, those for I/O and data versus those for security and configuration, and so on.

As I noticed my friend's eyes glazing over and his face contorting, he asked, "How on earth will anyone ever remember the names of all of the namespaces?" I answered , "Why try to remember all of the names?" I suggested to my friend that he simply remember just one thing: Use the Microsoft Visual Studio .NET documentation (see Figure 7-2).

click to expand
Figure 7-2: Preparing to launch the Microsoft Visual Studio .NET documentation

That may sound like a slick way to avoid helping someone. However, to be fair, I did include the following additional instructions (after all, this is my friend I am talking about):

  1. Click the Start button and select Programs Microsoft Visual Studio .NET Microsoft Visual Studio .NET Documentation.

  2. Locate the URL window on the Standard toolbar.

  3. Type ms-help://MS.VSCC/MS.MSDNVS/cpref/html/cpref_start.htm into the URL window.

  4. Press Enter.

The resulting display is a complete list of the .NET Framework namespaces. You will notice that in Figure 7-3, I have scrolled down to locate the System namespace. Note that the namespace names are displayed in a hierarchical fashion by function.

click to expand
Figure 7-3: The .NET Class Library Help page from the Microsoft Visual Studio .NET Documentation feature

The approach that I chose when helping my friend follows the traditional saying, "Give a man a fish and he'll eat for a day. Teach a man to fish, and he'll eat for a lifetime." Please consider this book ( especially sections like this one) as your guide to learning how to fish. On that note, let's continue fishing .

Browsing a Namespace

Recall that your ultimate objective is to drill down into the appropriate namespace. Your purpose for doing that is to locate, understand, and use the appropriate delegates, interfaces, classes, enumerations, and structures.

Using the Microsoft Visual Studio .NET documentation approach to locating the hierarchical display by function of a namespace, you could simply click the appropriate namespace name and locate the lower-level object. For example, say that you selected the System.Text namespace, as shown in Figure 7-4.

click to expand
Figure 7-4: A portion of the .NET Class Library Help page (via the Microsoft Visual Studio .NET documentation) showing the selection of the System.Text namespace

You will notice that the System.Text namespace contains eight classes. However, there are no delegates, interfaces, enumerations, or structures. Good observation. So, to be accurate, let's agree that a namespace will contain zero or more delegates, zero or more interfaces, zero or more classes, zero or more enumerations, and zero or more structures. Some namespaces will contain one or more of each type of object, whereas other namespaces (such as System.Text) will contain just one type of .NET object (in this case, classes).

Using the information that you have now, you could easily use the Help feature that is located within the Visual Studio .NET (VS .NET) IDE. For example, you could do a search (setting the appropriate search filter) using the value of System.Text. Better yet, now that you have the names of the eight classes that this namespace contains, you may have noted that there is a class named StringBuilder. You could do a search on the StringBuilder class to get detailed information about this particular .NET reusable object.

There are several scenarios involved with and corresponding approaches taken toward the goal of exploring and leveraging the .NET Framework. Up to this point, I have suggested an approach suitable for the scenario where uncertainty exists with regard to either the .NET namespace name or the name of a specific class/object. Suppose for a moment that you came from a different direction. Consider the following (other) scenarios:

  • You already know the namespace name, but you have no idea of what assembly [3] implements the namespace.

  • You already know the class name, but you forgot the namespace name.

  • You already know the assembly name, but you are not sure about the namespace name or the namespace members.

Though the preceding scenarios could direct you toward a variety of search methods , the fact that there is overlap between them is indicative of the nature of Windows and Web development. You have several ways to do practically everything. In some cases it will boil down to a matter of preference. Having said that, let's explore another way to get information about namespaces (and thus information about delegates, interfaces, classes, enumerations, and structures): the Object Browser feature.

VS .NET Feature: The Object Browser

The very name of this particular VS .NET feature, Object Browser, practically explains its purpose in life. Yes, you use this tool to browse objects. Too simple, huh? OK, there is a little more to it. To begin with, the objects that you are interested in (for now) are just the .NET Framework objects contained within the Microsoft-supplied namespaces (which are delegates, interfaces, classes, enumerations, and structures). Yet, there is more.

I need to emphasize that assemblies implement namespaces (recall that generally speaking, an assembly is a compiled unit of code). Having said that, in order to display information about the namespaces using the Object Browser, you will need to have a "reference" to the appropriate assembly. The following assemblies are referred to as the .NET default assemblies:

  • mscorlib.dll

  • System.dll

  • System.Data.dll

  • System.Design.dll

  • System.DirectoryServices.dll

  • System.Drawing.dll

  • System.Drawing.Design.dll

  • System.Messaging.dll

  • System.Runtime.Serialization.Formatters.Soap.dll

  • System.ServiceProcess.dll

  • System.Web.dll

  • System.Web.Services.dll

  • System.Windows.Forms.dll

  • System.XML.dll

You will become familiar with these .NET default assemblies (and others) over time. Depending on the .NET language and the project template type you use, you may have to manually set a reference to the appropriate assembly.

start sidebar
Referencing the Appropriate Assembly

During your mainframe batch travels , you undoubtedly used STEPLIB and JOBLIB JCL DD statements. Your reason for doing this was to provide a "reference" to a program via a load library. The name of the load library was typically associated with a PDS that contained precompiled modules. Granted, there was additional programming needed to CALL the external program. Your understanding of this practice (common in legacy mainframe COBOL development) provides you with a conceptual understanding of the reference used in the context of referencing a .NET assembly.

end sidebar
 

Now let's look at the Object Browser. From an open VS .NET IDE window, access the Object Browser feature by selecting View Other Windows Object Browser. As you can see in Figure 7-5, the Object Browser feature is an available menu option. Notice that I have yet to open a project of any type.

click to expand
Figure 7-5: Selecting the Object Browser feature

The resulting display may be an empty Object Browser window. Now select the Customize toolbar option to begin the steps of adding an assembly reference to the Object Browser (see Figure 7-6).

click to expand
Figure 7-6: Clicking the Customize option in the Object Browser

In the Selected Components dialog box, click the Add button (see Figure 7-7).

click to expand
Figure 7-7: Clicking the Add button in the Selected Components dialog box

At this point, you should be viewing a window titled Component Selector, with the .NET tab selected.

Now recall the "other" scenarios mentioned in the previous section. Suppose that you had worked with the System.Text namespace before, but you could not remember the details of the StringBuilder class. In this scenario, also suppose that you know that the System.Text namespace is implemented in the mscorlib.dll assembly. You are now prepared to select mscorlib.dll from the list of assemblies. After you scroll to locate the assembly in the Component Selector dialog box, select the assembly, and click Select (as shown in Figure 7-8), you can click OK twice to complete the steps of adding an assembly reference to the Object Browser.

click to expand
Figure 7-8: Selecting mscorlib.dll from the Component Selector dialog box

After you return to the Object Browser window, you will notice that the mscorlib assembly is included, along with a plus sign (+). Click the plus sign to expand the tree view and scroll past several namespaces to locate the System.Text namespace. Then proceed to expand the tree view and locate the StringBuilder class. After you click to select the StringBuilder class, you are finally able to see detailed information about the class, as shown in Figure 7-9.

click to expand
Figure 7-9: The Object Browser window displaying information about the StringBuilder class

During your application development, this detailed class information would prove to be critical if you wanted to use the StringBuilder class.

That is one scenario in which you know the assembly. During your development, there will be times when the assemblies will already be referenced in the Object Browser. In those instances, knowing the name of the assembly will be less of a requirement (e.g., when you view the Object Browser from an open Visual Basic .NET project). Additionally, assembly references added to the Object Browser (such as the one that you have just added) will remain available until they are manually removed.

So far in this section, you have covered namespaces, assemblies, and the Object Browser. You should now feel better prepared to drill down into the topic of the .NET Framework. Although I have used the example of a class to assist in the namespace discussion, I still have delegates, interfaces, enumerations, and structures to cover (remember the DICES acronym?). Do not worry. The remaining discussions should be much easier. In the upcoming discussions, you will be able to refer back to your new understanding of namespaces and assemblies. Additionally, you will use the Object Browser again for further illustration. These parts will feel like review for you.

Delegates

As you browse various namespaces, you will notice that some namespaces contain delegates; for example, the System namespace contains six delegates. Therefore, you need to establish a general understanding of what exactly a delegate is. Consider for a moment the lexical [4] meaning of delegate : "To commit or entrust (as task or power) to another."

Let's see how "To commit or entrust . . . to another" relates to the technical use of the term . In Chapter 6, in the COBOL .NET DefineDataTypesSampleCobol sample program, you briefly referred back to the legacy mainframe COBOL use of the USAGE IS POINTER clause. As you know, when you used that clause (occasionally with the ADDRESS OF register) you were pointing to (referencing) the actual memory storage location of one data item for the shared use of a second defined "data item." Again, you were working with data items. In this instance, you can easily see the issue of trust being important. If you have ever had a memory violation (especially with CICS applications), you had simply violated the trust that had been extended to you.

Now, in the current century, some of you have moved on to use the modern mainframe COBOL features of the USAGE IS PROCEDURE-POINTER clause or the USAGE IS FUNCTION-POINTER clause. Unlike the legacy USAGE IS POINTER clause, which pointed to data items only, these other clauses were available for pointing to procedures and/or functions. Naturally, the matter of trust has continued to be important. As before, violating that trust will produce undesirable results.

Note  

Using these newer USAGE clauses will be more familiar to those COBOL programmers who have already started to move away from legacy procedural/structured COBOL programming and toward object- oriented programming (OOP).

On .NET, delegates are practically identical to the USAGE IS FUNCTION-POINTER implementation. In other words, a delegate is a special object (actually, a class) that you use to point to (store a reference for) a method. The matter of trust is dealt with by using a feature called a signature. By restricting the storage of method references to those whose signatures match, the chances of violating the trust are virtually eliminated (some trust, huh?).

Cross-Reference  

I discuss delegates further in Chapter 15. In that chapter, you will learn several ways to use delegates (e.g., events and asynchronous execution).

For now, having a general understanding of what delegates are is sufficient. You will want to keep in mind that the System namespace contains two classes that are inherited (recall the discussion on object orientation in Chapter 4) by other classes implemented in the form of a delegate: System.Delegate and System.MulticastDelegate . The System.MulticastDelegate class is derived from the System.Delegate class. All other delegates are derived from System.MulticastDelegate.

start sidebar
Reuse Through Object-Oriented Design

To get an idea of how the .NET Framework uses object-oriented design, consider the following observation. As noted in this section, all delegates derive directly from System.MulticastDelegate, which itself derives from System.Delegate. Now, here is the amazing part: The .NET Framework class library has approximately 147 delegates, all deriving from the System.MulticastDelegate delegate. Now that is what I call reuse!

end sidebar
 

Interfaces

When you browse the System namespace, you will notice that it contains 11 interfaces. (Perhaps you will also notice that the names of most of the interfaces are prefixed with an I .) So, what are interfaces, and why are they among the namespace constituents?

Simply put, an interface is a contract. This contract specifies a set of functionality that must be followed by any class that chooses to implement the interface. In your legacy mainframe COBOL applications (before object orientation), you had a very limited concept of an interface.

For example, say that you wanted to call a subprogram from within your main COBOL program. You would have added a CALL statement followed by the name of the subprogram. But that was not all. Depending on the requirements of the subprogram, you would have also added a USING statement to indicate the parameters being passed to and returned from the subprogram. In other words, the subprogram was enforcing a "contract."

At this point, perhaps you are reflecting on the occasions when you had to debug some program logic dealing with calling subprograms. On some of these occasions, you may have inadvertently violated this subprogram contract. Although you may have been careful to pass in the correct number of parameters, you failed to adhere exactly to the requirements expected by the subprogram. For example, you may have put the parameters in the wrong order or you may have defined data items of the wrong type (numeric versus alphabetic). Maybe you thought everything was right, only to discover that your receiving fields were truncating your values due to short data field lengths.

Reflecting on these memorable legacy mainframe events, you can say that the subprogram had an interface that needed to be adhered to. The enforcement of the contract between the subprogram and the calling program meant that the requirement of the subprogram's interface was met. Therefore, in legacy mainframe terms, this is an example of the limited use of an interface that served as a contract.

In the context of .NET, the .NET Framework, and a .NET namespace, an interface includes the general concept of the mainframe "subprogram using" scenario. However, thanks to object-oriented design features, the more complete understanding of an interface includes much more.

On .NET, an interface can describe methods (conceptually similar to the legacy subprogram), fields, properties, and events. Classes can then "implement" this description (interface) and thus the class will be required (by contract) to provide all of the functionality described in the interface.

Cross-Reference  

I discuss interfaces further in Chapter 15. In that chapter, you will review several ways to use delegates (e.g., events and asynchronous execution).

Object-oriented design plays an important role in the .NET Framework and its parts. The existence of Microsoft-supplied interfaces (contained in various namespaces) provides developers the opportunity to reuse existing code. As shown in Figure 7-10, the System namespace contains 11 interfaces.

click to expand
Figure 7-10: A portion of the .NET Class Library Help page (via the Microsoft Visual Studio .NET documentation) showing the interfaces available in the System namespace

Classes

If you were the type of proficient legacy mainframe COBOL developer who leveraged the COBOL intrinsic functions as often as possible, you will want to become extremely familiar with this particular namespace constituent . You can practically draw a one-to-one match from each of the legacy COBOL intrinsic functions to a particular .NET Framework class. But then, by far, the .NET Framework collection exceeds the quantity of the legacy COBOL offering.

Although you can create applications without explicitly creating classes, this will typically not be the case. The sample applications that you created in Chapter 6 were simple applications that did not justify the structure of a class. The sample code that you will create in this chapter presents an example of explicit class creation.

You will see object-oriented design being used in the creation of the .NET Framework classes. (Recall that a basic understanding of OOP was listed as a .NET prerequisite in Chapter 4.) As you browse the list of namespaces, notice that practically all of them contain classes. Practically all of the classes derive from another class (a base class).

That is, all but one of the classes derive from another class. One class in the System namespace is the root, the superclass of all classes in the entire .NET Framework. All classes are derived (either directly or indirectly) from the System.Object class (or the Object class, for short). As shown in Figure 7-11, System.Object sits at the very top of the .NET Framework type hierarchy.

click to expand
Figure 7-11: A portion of the System.Object superclass hierarchy

To quickly review, a class serves as a template ( roughly speaking). The class can contain methods, properties, and events. To access the functionality of a class, you need an instance. The instance then is an object.

Note  

This is an extremely abbreviated explanation. For example, there are value type objects and reference type objects, each with their own style of instantiation. Look for further discussion of this subject in Chapter 9.

To finish the namespace classes discussion, you will revisit the StringBuilder class from the System.Text namespace previously discussed in this chapter. You will use the StringBuilder class as an example to introduce the use of a class viewing tool: the .NET Framework Class Viewer.

.NET Framework Tool: Class Viewer

What would you do if you were coding a COBOL .NET program and wanted to use the StringBuilder class? Assume that you had used the StringBuilder class before, but you could not remember which namespace contains the class. At worst, you could not locate any code samples. Additionally, assume that you could not remember the name of the assembly that implements the namespace.

Armed with the question "What are the methods and properties of the StringBuilder class?" you would begin your search. For some, the first choice might be to conduct a search using either the VS .NET IDE Help/Search feature or the Microsoft Visual Studio .NET documentation's Help/Search feature. Others may even take advantage of the online MSDN Search feature.

The good news is that each of these Help/Search choices would eventually lead you to your answer. The bad news is that some of these choices may not be the fastest method of accessing the information you're after. Depending on the filter you use, you'll get about 500 results returned from your search. With practice, you'll learn how to recognize the right result out of the 500 potential right results. Fortunately, you have an alternative.

Microsoft provides a .NET Framework tool called the Class Viewer (not to be confused with the Class View option available in the VS .NET IDE). Using this tool, you will receive multiple results from your search as well. The difference is that each result that you receive will directly relate to a class/namespace/assembly relationship.

You execute the Class Viewer tool from the VS .NET Command Prompt window. As shown in Figure 7-12, you type in WinCV.exe to access the Class Viewer user interface.

click to expand
Figure 7-12: Enter WinCV.exe in the Visual Studio .NET Command Prompt window to execute the Class Viewer.

The Class Viewer user interface is rather intuitive. You simply type in the name of the class that you are interested in. In this case, you would enter StringBuilder . Notice that as you type, the window display on the right immediately updates to display the information you are looking for. Using the Option feature on the Class Viewer toolbar, you can easily copy the output. I have pasted portions of the output display here:

 'c:\winnt\microsoft.net\framework\v1.0.3705\mscorlib.dll' . . .     // Constructors     public StringBuilder();     public StringBuilder(int capacity);     public StringBuilder(int capacity, int maxCapacity);     public StringBuilder(string value);     public StringBuilder(string value, int capacity);     public StringBuilder(string value, int startIndex, int length, int capacity);         // Properties     public int Capacity { get; set; }     public char Chars { get; set; }     public int Length { get; set; }     public int MaxCapacity { get; }         // Methods     public System.Text.StringBuilder Append(short value);     public System.Text.StringBuilder Append(char value);     public System.Text.StringBuilder Append(long value);     public System.Text.StringBuilder Append(int value);     public System.Text.StringBuilder Append(bool value);     public System.Text.StringBuilder Append(string value);     public System.Text.StringBuilder Append(byte value);     public System.Text.StringBuilder Append(SByte value); . . .     public System.Text.StringBuilder Append(char[] value);     public System.Text.StringBuilder Append(object value);     public System.Text.StringBuilder Append(double value); . . .     public System.Text.StringBuilder Append(Decimal value);     public System.Text.StringBuilder Append(char value, int repeatCount); . . .     public int EnsureCapacity(int capacity);     public virtual bool Equals(object obj);     public bool Equals(System.Text.StringBuilder sb);     public virtual int GetHashCode();     public Type GetType();     public System.Text.StringBuilder Insert(int index, double value);     public System.Text.StringBuilder Insert(int index, int value);     public System.Text.StringBuilder Insert(int index, char[] value);     public System.Text.StringBuilder Insert(int index, float value);     public System.Text.StringBuilder Insert(int index, long value);     public System.Text.StringBuilder Insert(int index, UInt64 value);     public System.Text.StringBuilder Insert(int index, object value);     public System.Text.StringBuilder Insert(int index, UInt32 value);     public System.Text.StringBuilder Insert(int index, Decimal value);     public System.Text.StringBuilder Insert(int index, UInt16 value);     public System.Text.StringBuilder Insert(int index, SByte value);     public System.Text.StringBuilder Insert(int index, bool value);     public System.Text.StringBuilder Insert(int index, string value);     public System.Text.StringBuilder Insert(int index, byte value);     public System.Text.StringBuilder Insert(int index, char value);     public System.Text.StringBuilder Insert(int index, short value); . . .     public System.Text.StringBuilder Remove(int startIndex, int length);     public System.Text.StringBuilder Replace(char oldChar, char newChar); . . .     public System.Text.StringBuilder Replace(string oldValue, string newValue); . . .     public virtual string ToString();     public string ToString(int startIndex, int length); 

This Class Viewer tool is nice. The ability to easily copy the output is an added bonus. As I have copied and pasted portions of the output here, you can copy and paste portions of output directly into your program code. This has productivity written all over it. Can you tell that I am excited about this tool?

Tip  

So far, I have introduced you to two "Microsoft-provided" tools that actually fall under the category of ".NET Framework tools": the ILDASM.exe tool (introduced in Chapter 6 during the Microsoft Intermediate Language [MSIL] discussion) and the WinCV.exe tool (the Class Viewer discussed in this section). The .NET Framework has many other tools. To find information on the other tools the .NET Framework provides, please visit the Microsoft Visual Studio .NET Documentation Help page using the following URL: ms-help://MS.VSCC/MS.MSDNVS/ cptools/html/cpconnetframeworktools.htm .

That concludes this chapter's discussion of classes and the Class Viewer tool. In the following sections, you will explore the remaining types of objects you are likely to come across when you use the .NET Framework: enumerations and structures.

Enumerations

Believe or not, you have worked with a data structure similar to the .NET enumeration object before. How many times in your legacy mainframe COBOL past have you seen tables or group items defined that listed a collection of numeric values? Sometimes, "88" levels were used, other times not. You would then use the individual items as constants. In the legacy COBOL code snippet in Listing 7-1, the group of data items called My-Days-Of-Week is implementing this type of behavior.

Listing 7-1: Legacy COBOL Code Snippet Showing a Group Item Definition
start example
 Data Division.      File Section.      FD My-File         Record Contains . . .      01 My-Record.         05 My-fields.  . . .      Working-Storage Section.      01 My-Days-Of-Week.         05 Sunday             Pic 9(1) value = 0.         05 Monday             Pic 9(1) value = 1.         05 Tuesday            Pic 9(1) value = 2.         05 Wednesday          Pic 9(1) value = 3.         05 Thursday           Pic 9(1) value = 4.         05 Friday             Pic 9(1) value = 5.         05 Saturday           Pic 9(1) value = 6.         01 My-Other-Fields    Pic x(20).      . . .      Procedure Division.         . . . 
end example
 

In the .NET Framework, you will come across namespaces that provide enumerations (you can also create your own). All enumerations (about 477) are derived from the System.Enum class. When you examine the System namespace, you will notice that there are eight enumerations, one of which is the DayOfWeek enumeration. The functionality of the System.DayOfWeek enumeration is the same as that in the legacy COBOL code snippet in Listing 7-1.

For example, if you were to type in DayOfWeek in the .NET Framework Class Viewer, you would see the display shown in Listing 7-2.

Listing 7-2: The DayOfWeek Enumeration Declaration in C#
start example
 public enum DayOfWeek  {     Friday = 0x00000005,      Monday = 0x00000001,      Saturday = 0x00000006,      Sunday = 0x00000000,      Thursday = 0x00000004,      Tuesday = 0x00000002,      Wednesday = 0x00000003,  } // end of System.DayOfWeek 
end example
 

By design, the Class Viewer output is in C#. Just for fun, let's quickly translate the enumeration declaration in Listing 7-2 to Visual Basic .NET (VB .NET). Listing 7-3 shows the result.

Listing 7-3: The DayOfWeek Enumeration Declaration in VB .NET
start example
 Public Enum DayOfWeek      Friday = 0x00000005     Monday = 0x00000001     Saturday = 0x00000006     Sunday = 0x00000000     Thursday = 0x00000004     Tuesday = 0x00000002     Wednesday = 0x00000003 End Enum 
end example
 
Note  

In the cases of enumeration creations, you will notice that there is not a big difference between C# and VB .NET.

Cross-Reference  

Appendix B reviews the basics of the C# language.

The enumeration declarations in Listings 7-2 and 7-3 demonstrate what Microsoft has already done for you. For the predefined enumerations, you simply use the predefined enumerations. You use enumerations in a similar way to other numeric data types (e.g., Int16 and Int32). In the case of the DayOfWeek enumeration, you would declare data items with the type DayOfWeek.

Many of the common number constants that you would have coded (over and over again) in your legacy applications have already been coded for you. Familiarize yourself with what is available ”many times you will avoid having to reinvent the wheel. Again, the .NET Framework, as a class library, offers many opportunities for reuse. In the cases where an enumeration does not already exist, you can create an enumeration that derives from the System.Enum base class.

Note  

COBOL .NET does not allow the creation of enumerations. However, you can reference and use the existing enumerations provided by the .NET Framework.

Structures

The My-Days-Of-Week group item shown in Listing 7-1 provides the perfect starting point for a brief discussion about structures. If you can, try to imagine the previous group item declaration on steroids.

At first, it may appear that a structure (also referred to as a value object ) is functionally similar to an enumeration. For example, you can use a structure to "declare" data items that behave as traditional fields (or properties). However, that is where the similarities end. A structure adds the following to its feature list:

  • You are not limited to numeric data types.

  • You can add methods with executable logic.

In Chapter 6 in the COBOL .NET code sample, you used a few structures. These were structures from the System namespace. In the sample code, you used the .NET data types System.Int16, System.Int32, and System.Double. Well, each of the numeric .NET data types (e.g., Int16, Int32, and Double) actually is a structure in the System namespace.

Cross-Reference  

In Chapter 9, I further discuss value types. In that chapter, I contrast these types of objects with reference types. Additionally, I discuss appropriate considerations when using each type of object.

As with enumerations (discussed in the previous section), Microsoft has provided predefined structures in the .NET Framework class library. You will notice that there is a base class in the System namespace called System.ValueType . Approximately 100 structures (or value objects) are derived from System.ValueType. As you now know, you can create your own enumerations deriving from the System.Enum base class. Likewise, you can create your own structures deriving from the System.ValueType class.

This concludes the chapter's discussion of delegates, interfaces, classes, enumerations, and structures (DICES). In the following section, you will explore some interesting ways to use (rather, to reuse ) some of the .NET Framework objects.

[1] All right, I admit it is not that impressive, but it might help you remember the parts of the .NET Framework. I suppose I should leave the acronym creating to the Microsoft marketing gurus.

[2] I discuss the common language runtime (CLR) in Chapter 8.

[3] In Chapter 6, I briefly mentioned the .NET assembly. In this context, the .NET Framework namespaces are implemented by the Microsoft-supplied assemblies (DLLs).

[4] According to The American Heritage College Dictionary, Third Edition (Houghton Mifflin, 1995).




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