Beginning Object-Oriented ASP.NET 2.0 with VB.NET From Novice to Professional

C H A P T E R 7 ■ C L A S S D E S I G N

109

•Help Desk Manager

•List of all tickets for a specific technician

•List of all tickets for a specific location

•List of all new tickets

•List of all assigned tickets

•List of all resolved tickets

•List of all unresolved tickets

•List of all closed tickets

The actions listed previously are the most obvious actions that need to take place. However, many other actions must take place that may not be so obvious. These are called supporting actions. The supporting actions and their potential classes are listed next:

•Ticket

•Update ticket

•Validate ticket

•Change status

•Resolve ticket

•Notification of resolved ticket

•Notification of not resolved ticket

•User

•Technician

•Help Desk Manager

As you can see, most of the supporting actions are dealing with the Ticket class. This is because the majority of the business process involves the ticket. It would appear that the majority of the business process really involves the technician, since the technician is performing most of the actions. However, there is a difference between the object performing actions and an object having actions performed on it.

110 C H A P T E R 7 ■ C L A S S D E S I G N

Here’s the resulting complete list of potential classes, properties, and methods that will be used as input into the next step:

•Ticket

•Create new ticket

•Assign ticket

•Update ticket

•Validate ticket

•Change status

•Resolve ticket

•Notification of resolved ticket

•Notification of not resolved ticket

•User

•Ticket not resolved

•Close ticket

•List of tickets created

•List of resolved tickets

•Technician

•List of new tickets

•List of tickets assigned to them

•List of tickets they resolved

•List of all new tickets

•List of all assigned tickets

•List of all resolved tickets

•List of all unresolved tickets

•List of all closed tickets

C H A P T E R 7 ■ C L A S S D E S I G N

111

•Help Desk Manager

•List of all tickets for a specific technician

•List of all tickets for a specific location

•List of all new tickets

•List of all assigned tickets

•List of all resolved tickets

•List of all unresolved tickets

•List of all closed tickets

Create the Class or Classes

The input for this next step is a document that groups the potential classes, properties, and methods together. From this list of potential classes, properties, and methods, you must determine which classes make the most sense. There may be multiple classes that are very similar, and it may make sense to create them as one class or as inherited from a base class. Remember from the inheritance chapter that if an “is a” relationship exists, then inheritance may be used. From your potential list of classes you must determine which classes make the most sense for this application and also determine whether additional classes must be defined. After determining your final list of classes, create a complete list of those final classes. This list of classes will be the input for the next step in the class design process.

Now that you have defined all of the potential classes, properties, and methods, you must make a determination as to the best way to group the functionality required by the application. There really is no correct set of classes, properties, and methods. No one will look at your code and say, “You must rewrite this application because you made the wrong selections.” However, your decision regarding which classes, properties, and methods to use will have a large effect on the amount of work required to develop the application, not to mention the amount of effort required later for maintenance. If the class definitions are either too narrow or too broad, linking the classes together to build the required functionality may be difficult. There is nothing wrong with redefining classes later in the development process. However, be aware that the later in the development process you redefine your classes, the more impact that decision will have. Also be aware that if you change the class definition that will be used by other developers, you must notify them because they are going from the same initial specification that you started with.

In this case, most of the properties and methods are part of the ticket class. This should make sense to you, as the majority of actions and adjectives in the business

112 C H A P T E R 7 ■ C L A S S D E S I G N

process describe the ticket. Again, just because the technician performs the work and interacts with the ticket does not mean the Technician class should have the majority of the properties and methods. Think about the Ticket class as being an object in the real world. If the help desk ticket business process was purely on paper, the majority of the information would reside on a piece of paper called a ticket. The technician would then just interact with the piece of paper. The same is true in this case study—the ticket is the object with the majority of actions and attributes and the technician is simply the object that interacts with the ticket object the most.

So now take a look at your list of classes, properties, and methods. You’ll notice that the technician and help desk manager are not that distinct from one another. They share a lot of the same methods or actions. Should there be two separate objects then? The answer is no.

In this case study, the technician and the help desk manager are really just security roles that have different permissions. Technicians, for example, can only see tickets for their specific location, while the help desk manager can see tickets for all locations. Both objects can see all new tickets.

The best way to approach this situation is to create a base class called Help Desk User. From that base class, inherit the core methods that both the technician and help desk manager share. The resulting derived classes should be called Technician and Help Desk Manager. The reason that inheritance (derived and base classes) can be used here is that an “is a” relationship exists. Technicians and help desk managers are both Help Desk Users. However, the Technician class will have only the methods specific to the technician role and the Help Desk Manager class will only have the methods specific

to the help desk manager role. The resulting set of classes will be:

•Ticket

•User

•Help Desk User

•Technician (inherits from Help Desk User)

•Help Desk Manager (inherits from Help Desk User)

You will notice that the Technician and Help Desk Manager classes will inherit from the Help Desk User class. This list of classes will be used as input into the next step in the process—also known as defining the properties and methods of each class.

Define the Properties and Methods of Each Class

The input for this step is a document that lists the application’s classes and another document that groups the potential classes, properties, and methods together. Now you’ll

C H A P T E R 7 ■ C L A S S D E S I G N

113

need to map the potential properties and methods from the document listing the potential classes to the document listing the application’s classes.

After mapping these properties and methods, you must determine if these properties and methods make sense for the various classes. If they do, then add them to the class. If they don’t, then you must determine if another class is required or if the properties or methods can be placed within another class. You shouldn’t just drop a property or method that doesn’t appear to fit into any of the classes unless you very sure that property or method is not necessary. The next step is to determine if there are additional properties or methods that must be included with each class for the application. If there are, add these to the appropriate class. The list of classes, their properties, and methods will be the input for the next step in the class design process.

Case Study: Define the Properties and Methods of Each Class

Now that you have defined your classes, you must formally determine the properties and methods. To begin, bring forward the list of potential classes, properties, and methods from your earlier list. The list of potential classes and methods was:

•Ticket

•Create new ticket

•Assign ticket

•Update ticket

•Validate ticket

•Change status

•Resolve ticket

•Notification of resolved ticket

•Notification of not resolved ticket

•User

•Ticket not resolved

•Close ticket

•List of tickets created

•List of resolved tickets

114C H A P T E R 7 ■ C L A S S D E S I G N

•Technician

•List of new tickets

•List of tickets assigned to them

•List of tickets they resolved

•List of all new tickets

•List of all assigned tickets

•List of all resolved tickets

•List of all unresolved tickets

•List of all closed tickets

•Help Desk Manager

•List of all tickets for a specific technician

•List of all tickets for a specific location

•List of all new tickets

•List of all assigned tickets

•List of all resolved tickets

•List of all unresolved tickets

•List of all closed tickets

The potential list of classes and properties was:

•Ticket

•User login name

•First name

•Last name

•Phone number

•Location

C H A P T E R 7 ■ C L A S S D E S I G N

115

•E-mail address

•Problem description

•Category

•Date created

•Created by login

•Status

•Importance

•Additional comments

•Assigned to

•Resolution

•Time spent in minutes

•Date resolved

•Date closed

•Ticket ID

•User

•Technician

•Help Desk Manager

Now map the original potential classes, properties, and methods to the classes that were determined to be the best:

•Ticket

•User login name

•First name

•Last name

•Phone number

•Location

116C H A P T E R 7 ■ C L A S S D E S I G N

•E-mail address

•Problem description

•Category

•Date created

•Created by login

•Status

•Importance

•Additional comments

•Assigned to

•Resolution

•Time spent in minutes

•Date resolved

•Date closed

•Ticket ID

•Create new ticket

•Assign ticket

•Update ticket

•Validate ticket

•Change status

•Resolve ticket

•Notification of resolved ticket

•Notification of not resolved ticket

•User

•Ticket not resolved

•Close ticket

C H A P T E R 7 ■ C L A S S D E S I G N

117

•List of tickets created

•List of resolved tickets

•Is Technician

•Is Help Desk Manager

•Help Desk User

•List of new tickets

•List of all assigned tickets

•List of all resolved tickets

•List of all unresolved tickets

•List of all closed tickets

•Technician (inherits from Help Desk User)

•List of tickets assigned to them

•List of tickets they resolved

•Help Desk Manager (inherits from Help Desk User)

•List of all tickets for a specific technician

•List of all tickets for a specific location

Notice that this is a complete list of properties and methods for each class. Also notice that two new properties have been added to the user class. The Is Technician user class property will be used to determine whether the user is a technician or a general user. The Is Help Desk Manager user class property will be used to determine if the user is a help desk manager. This completed list is now the input for the next and final step in the class design process, creating the classes in VB.NET.

Create the Class Structure

This is the final step in the class design process and it takes the list of classes, their properties, and their methods as its input. From the list of classes, you’ll need to create a new class file for each class listed. Within each class defined within the list, you’ll need to define a local private variable for each property. For each property that needs to be public, you’ll

118 C H A P T E R 7 ■ C L A S S D E S I G N

need to create a public property structure. For each property that needs to be private, you do not create a property structure, but can just leave the variable defined as private. For each method, determine whether it should be public or private and then define it as such. Next, determine if each method requires a parameter or not—if so, define that parameter. Finally, for each method, determine whether the method should return a value If the method should not return a value, then define the method as a sub. The output of this last step will be the output of the class design process, also known as the completed class structure.

Now is also a good time to look for reusable classes. If your company has a class library or namespace that contains common functionality, now is the time to determine if any preexisting functionality can be used in your application. It’s possible that a class may already exist for getting user information, for example. You will need to compare the methods and properties that you need to the methods and properties that exist for the common class. If your class needs the common functionality along with additional functionality, then you will want to inherit the common class and then add your own functionality. That added functionality may come in the form of new methods or properties or by an overriding of existing methods.

Case Study: Create the Class Structure

To begin this part of the class design process, create a new web site called HelpDesk. After creating the new web site, create a new class file for each class. To do so, right-click on the web site URL in the Solution Explorer and choose Add New Item.

When the Add New Item window appears, choose Class. Provide the class name as shown in the design, but without the spaces.

After clicking Add for each class, you will receive a message similar to the one shown in Figure 7-2. Click Yes. This message tells you that the class file (.vb file) you are creating will be created within the App_Code folder within the web site.

Figure 7-2. A check for where to put the class page

After adding all of the classes, your Solution Explorer should look like Figure 7-3.