Chapter 8: Reusing Code

Up to this point, you have written a fair amount of code. In fact, if you do a line count, you will find out that it comes to about 3,624 lines of code (this includes blank lines and Windows Forms-generated code, but not comments). That is a lot of work for just two sets of classes that retrieve only two tables worth of data. In this chapter you will look at two ways of reducing the amount of code that your application needs. First, you will consolidate some of the code in your user-centric classes, and you will create a base class that you can use in your user-centric objects. After you do that, you will set up a couple of enterprise templates so that you can add standard blocks of code and just edit the parts you need to edit. In this manner, you might add 1,000 lines of code, but you only have to type about 50 lines. It makes for a much more streamlined development process, as you will see.

Reducing Redundant Code

Many times during an application's lifecycle, I have had the occasion to say something such as, "We use that code everywhere." That one statement means that I have redundant code. Sometimes, during the design phase, it is not always easy to figure out exactly what code will be redundant and what code will not be. Contrary to popular belief, development just is not that cut and dried. I like to review two completed sets of code for two functions that work fairly similar. By looking at these sets of code, I can figure out exactly what code needs to be moved around and changed and reduced. Any further in the process than this generally requires a lot of rework and is not a good idea. If you catch these things too late, it is often just better to count it as a lesson learned, add it to the change management log, and move on. Obviously you would like to avoid this situation altogether, but no matter how many times you think you have got it right, you will always miss a little something.

Visual Basic .NET (VB .NET) gives VB 6 developers a whole new world for removing redundant code. Through inheritance and interfaces you can cut down on a great deal of duplicate code. You have already seen this in action with the power of visual inheritance and even something as simple as inheriting from the dictionary base. So, you will now complete your own code reduction exercise. The first step to doing this is to list all of the routines and variables from the two pieces of code you want to compare. If they are similar, then you also want to add how they are different. If they are very different, then it does not make much difference. To keep it simple, you will examine the Territory and Region objects only by creating the list in Table 8-1.

Table 8-1: Method Comparison Table

Region	Territory	Notable Difference
Delete	Delete	ID is an integer in one, a string in the other
LoadRecord	LoadRecord
mobjRules_RuleBroken	mobjRules_RuleBroken	None
Save	Save
GetBusinessRules	GetBusinessRules	The remoting object on which the call is made
IsDirty	IsDirty	None
IsValid	IsValid	None
Loading	Loading	None
mblnDirty	mblnDirty	None
BrokenRule (Event)	BrokenRule (Event)	None
ObjectChanged (Event)	ObjectChanged (Event)	The object being passed

Note

A good, easy way to do this comparison is to switch to the Class View tab on the Solution Explorer. This gives you a view similar to the view in Figure 8-1 where it is easy to see all of the information you need to review.

Figure 8-1: Solution Explorer's Class View tab

You will notice that Table 8-1 only lists the methods and properties that you could conceivably consolidate. You cannot consolidate constructors, the ToString method, or the properties. You want to create a generic set of reusable code that is reusable by all of the objects you will create from here on out. The methods with no notable difference are not at all similar. What they do may be similar, but they call different objects on the server and therefore they are not good candidates to consider. So, that leaves you with only a few things you can consolidate, but it will make a huge difference.

Note

An important method to note in Table 8-1 is the Delete method. I listed this as an example because you cannot consolidate it—nor would you really want to consolidate it. The reason you cannot consolidate it is because of the ID passed to the remote objects to retrieve the record. If you use an Identity column as the ID on all of the tables, then you could conceivably consolidate the Delete method because it does not return any information. The reason why you would not want to consolidate it is because it is a method that is part of the object as opposed to something that acts on the object, so you do not really want to move this code outside of your object.