Encapsulation
Encapsulation is a method of data abstraction that allows us only to change data through a representation, not the real thing. In Visual Basic, we can accomplish this using properties and methods. To illustrate, consider the code below.

	Private mintEmployeeNumber as Integer

	Public Property Get EmployeeNumber() As Integer
		EmpoyeeNumber = mintEmployeeNumber
	End Property

	Public Property Let EmployeeNumber(ByVal intNewValue As Integer)
		mintEmployeeNumber = intNewValue
	End Property

Notice that you can modify employee number data only through the property Get EmployeeNumber and Let EmployeeNumber, but not by accessing the mintEmployeeNumber variable directly. We have made it somewhat more difficult to change the data, but more importantly, we have made a more reliable component because any changes to the data come through a very strictly typed process. Properties are not the only way we encapsulate data. We can also do this by calling methods, using user defined types (UDT), collections, variant arrays, and other methods.

Other OOP Principles
Overloading allows us to provide multiple procedures that have the same name and do similar things. You may rightly ask, “Isn’t that similar to polymorphism?” Well, yes and no. You can accomplish similar results. Recall that polymorphism allows varying functionality of the same interface.

Overloading allows varying functionality of the same method by providing more than one signature. For example, with both methods, you could create several objects that have the same interface and different implementation, but with overloading, you can accomplish this in a totally different means. Instead of overriding, thus rewriting the method for each object, you could provide several methods named the same, but with different parameters in the same interface. Notice the following pseudocode.

	Public Function GetEmployee(strName As String) As Variant
	End Function

	Public Function GetEmployee(lngID As Long) As Variant
	End Function

	Public Function GetEmployee(dtStartDate As Date) As Variant
	End Function

How do you do that in Visual Basic 6? Well, unfortunately you can’t. The code sample below is as close as we can get, but Visual Basic just doesn’t support overloading methods.

	Public Function GetEmployeeByName(strName As String) As Variant
	End Function

	Public Function GetEmployeeByNumber(lID As Long) As Variant
	End Function

	Public Function GetEmployeeByDateOfHire(dtStartDate As Date) As Variant
	End Function

Architecting a Case Study
Many times in web development, we need users to register to use our site. Suppose that you wanted to create a truly reusable process to use with other projects, or that your business rules change often. It may even be that your site offers an a la carte service with various different, or yet unknown, offerings. How can these goals be accomplished using Visual Basic 6?

Case Study
“Better Cottages and Flowers” magazine needs their web site to collect user data, thus allowing them to opt to receive newsletters, buy gardening tools, buy magazine subscriptions, place ads, gain access to the site for research, and many other things. They will also constantly be adding new monthly specials.

Here are the business rules:

• Users emails must be recorded to receive the monthly newsletter;
• Users can register for access to their research site;
• Users can purchase products such as gardening tools and their profiles and information are stored;
• Users can purchase their annual paper magazine subscriptions;
• Advertisers can submit advertisement requests.
• June’s special is 10% off an annual subscription
• July’s special is join the newsletter and you get your choice of either
• August’s special is get a garden credit card and get a 50% off a subscription and a free pot
• Marketing has not come up with September-May offers yet.
• June-August offers are subject to change depending on market prices and availability.

• Occasionally, they may partner with other vendors, and there may be specials depending on the customer/site that referred them, or coupons.

When we analyze the business requirements, we can see that they are all essentially forms of registering.

The Traditional Approach
Simple, create a web site with a page, component, and messy data structure for each offering. Code a method for each business rule, perhaps as done below.

	Public Function SignupforNewsletter(ByVal sEmail As String)
		'Add them to the database
	End Function

	Public Function BuyGardeningTools(ByVal sFirstName As String, ByVal
		sLastName As String, ByVal sAddress As String, _
		ByVal sCity As String,
		ByVal sState As String,
		ByVal sZipCode As String,
		ByVal lCreditCardNumber As Long, _
		ByVal dtExpirationDate As Date)

		'Add them to the database
		'Charge their card
		'Send authorization to shipping department
	End Function

	Public Function SubscribetoMagazine(ByVal sFirstName As String, ByVal
		sLastName As String, ByVal sAddress As String, _
		ByVal sCity As String,
		ByVal sState As String,
		ByVal sZipCode As String,
		ByVal lCreditCardNumber As Long, _
		ByVal dtExpirationDate As Date)

		'Add them to the database
		'Charge their card
		'Send authorization to fulfillment center
	End Function

And so on…

What happens when you need to add September’s promotion? We’d have to add it to the DLL and recompile, or create a new one. You can see that in no time, it will get ugly.

The OOP Approach
One design could allow for a common “registration” interface (we’ll call it IRegister) that all of our different types could inherit from. As long as all server objects support that interface, clients would call the objects seamlessly. Since there is little code that is in common, implementation inheritance is not needed here.

Since Visual Basic doesn’t support the purist’s definition of inheritance, we can simulate it with the addition of polymorphism. We’ll start with a singleton classfactory pattern to achieve our desired result. A singleton is an object that will exist in only one instance. A classfactory is a special type of singleton whose job is to create other types of objects. A true classfactory would return a single interface.

We mentioned that we don’t need implementation inheritance here. If we did require it, we could simulate it by placing common code in its own COM object and exposing its methods to a host object through the IRegister interface. The diagram below shows us the relationship that our processes will have. ASP pages will only interface with the classfactory, which will in turn, interface only with IRegister components.

IRegister component

This sequence diagram shows us the order of events. The ASP page gathers the information, and then calls the classfactory, which creates the appropriate IRegister component, and so forth. Only the classfactory’s interface will be exposed to the client. Every object that supports the IRegister interface will be created by the classfactory. In this case, we won’t return the component (or reference to it). We’ll instead do our business and return a Boolean result, and raise an error, which will be handled by the classfactory.

One predicament though, is that these different registration types require different parameters. We can handle this in a variety of ways.