Aggregation Mini-Lecture: Day 5
And then the gas station attendant said, "Why don't you take them to the Zoo?" but penguins don't come from next door, they come from the Antarctic. No, BURMA! No, the Zoo! Penguins come from the ZOO! Not the Zoo! NOT THE ZOO! PLEASE SOMEONE HELP ME IT'S THE ZOO!!!!!!
Your screams of abject terror startle you awake. It's the same recurring nightmare: the Veterinarian has taken on the city Zoo as a customer and your pet care application has become an unimaginable behemoth. Class module after class module added, more and more and more animals. Worst of all, the Vet wants to add "Habitat" as an individual care type!! What if you forget to add it to one of the class modules??....
Thankfully, it's just a nightmare. However, you can take steps now to modify your application before it takes on a life of its own and starts acting like the bad thing in a 1960s B movie.
There are two types of Visual Basic inheritance. Both types are Implementation Inheritance, but the one you've saw last time is called Non-Abstract (Aggregation) and what we'll be dealing with this time is Abstract. (The proper name for the end result is Interface, btw.)
An advantage to an abstract interface is that the class that implements it can code the methods and properties however it wants, and differently from how any other class might chose to implement. Another advantage is that abstract interface implementation doesn't incur the overhead that aggregation does by creating an instance of the implemented object (remember that that was noted as the primary drawback of aggregation).
It's very easy to create an Abstract Interface. It's a class module with
a series of public Properties and Methods that are just procedure stubs - there is no code in them.
(You might run across a situation in which VB magically deletes procedures that have no code in them;
in that case add a comment where you would normally put code.) By convention, these class modules
are prefixed with an I (for Interface). So, the abstract interface for the Pet Care application
is clsIPet (link opens new window).
So, now we're ready to move on to the implementation class module. Of course, the rules of Implements still apply, as they did last time: we have to make sure we refer to all the public properties (and/or methods), HOWEVER, we don't have to provide public versions of all the procedures - we'll see why when we get to the Form.
But, wait! There's only one class module, clsPet - what's going on here?? Where's clsCat and clsDog, etc.??
Well, the approach you're about to see won't work for every application out there, but it does work for this particular one. Through the wonder of the Resource File1, we've been able to condense all those class modules into one.
Each PetType has been assigned a code - Cats in the 200s, Dogs in the 300s, etc.
Food is the 1 series, Cleaning the 2 series, and so on. [ It is often the ultimate goal of every programmer
to code in just one line (mFood = LoadResString(intPetType + 1)).
clsPet is an example of how :-)] (will open new
window)
When we get to the form (link will open new window) it gets a little tricky. You have to make sure that you declare the object as the Abstract Interface (clsIPet), but you create it (New) as the implementing class (clsPet). (These two lines have been highlighted in yellow).
We could use the WithEvents here because we're declaring the variable as a specific
data type, but it wouldn't help because the Event lives in the implementing class, not the Abstract
Interface. Bummer about the Event...oh, well, maybe something will turn up and we can fix that....
1I would like you to read up on using Resource Files on MSDN (links open new windows):
Alrak's Course Resources ©2002-2007 Karla Carter. All rights reserved. This material (including, but not limited to, Mini-lectures and Challenge Labs) may not be reproduced, displayed, modified or distributed without the express prior written permission of the copyright holder. For permission, contact Karla.