• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 197
  • Last Modified:

extending a class

Say I run a used car dealership. So I have a class for Vehicle.

A new vehicle arrives, so I create an instance of the Vehicle class:
v = new Vehicle();

Open in new window

Then I'm told this vehicle is blue:
v.Color = blue;

Open in new window

Then I'm told this vehicle is a motorcycle with chrome handlebars. My Motorcycle class is an extension of the base class Vehicle, but now I have to abandon my Vehicle class v and create an instance of Motorcycle:
 m = new Motorcycle();

Open in new window

and copy over the color:
m.Color = v.Color;
m.handlebars = Chrome;

Open in new window

This doesn't seem right. I shouldn't have to abandon my vehicle class v and start a new class m. Yet it wouldn't be appropriate to have a "handlebar" field in my Vehicle class.

This could continue. Say I'm then told this is a Kawasaki. Now I have to abandon my m instance of Motorcycle, create an instance of class Kawasaki which extends class Motorcycle, and copy over all the info once again.

What I'm really doing is receiving a message, which I thought I'd create an instance of a Message class and put the message in it. Only problem is there are several different types of messages, I don't know what type of message I have until I parse it, but it seems from a design point of view that the parsing should be done inside the Message class, but I don't know what kind of Message class instance to create until I parse the message. Catch 22.

How does one deal with this from a design point of view?
0
deleyd
Asked:
deleyd
  • 4
1 Solution
 
Bill NolanCommented:
You are right; you shouldn't be re-creating the class.

I don't know your exact code or data flow, but in general you might consider:

1. Create base class for vehicle, and derive all from it.  E.g.,:

public class Motorcycle : Vehicle { // stuff }

2. create an enum of vehicle types. e.g.:
enum Vehicles
{
   Car,
   Motorcycle,
   Unicycle
}
3. create enum's of sub-components for each vehicle type, if necessary.  You may want to use bitfields if you plan on supporting more than one at a time.  E.g.:

enum Parts_Unicycle
{
   Wheel = (1 << 0),
   RocketLauncher = (1 << 1)
}
4. parse your message and gather all your info.
5. Create the appropriate class and assign values after you've collected all data.  E.g.:

Vehicle h = null;
switch (typeVehicle)
{
   case Vehicles.Unicycle:
      v = new Motorcycle();
      // assign parts, etc...
   break;
}
0
 
Bill NolanCommented:
oops, sample at end should have shown:

v = new Unicycle();
0
 
Bill NolanCommented:
Also, if you actually have to support a system where the vehicle type/integrity DOES change as you go, then either:

1. Store all info to DB.  Create appropriate vehicle at run time from this data.
2. If all must be done at run time (changing classes), consider creating one vehicle class that contains all potential info (including the type of vehicle, a parts list [each part in list derived from a base class].)
0
 
deleydAuthor Commented:
OK so there's no simple remedy I'm missing. I either create one class which contains all message types and possible message info fields, or I parse the message first, then create the appropriate class to store the already parsed info in.
0
 
Bill NolanCommented:
If you set this framework up carefully, taking care to recognize any constituent elemental parts, etc., that may have class-specific implementations (e.g., class RocketLauncher derives from class Part) you will find that you can easily accommodate anything new, at the same time as avoiding a host of other potential issues.
0

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now