views:

96

answers:

4

Lets say I have this class (just as an example):

internal class Packet
{

    private readonly UInt32 _length;
    private readonly Byte _type;
    private readonly UInt32 _requestId;

}

There are many different types of packets each of which inherit from this class and each packet type can have any number of properties of varying types.

Is there a way to implement every type of packet without using inheritance?

I thought about using a property such as List<Tuple<Type,Value>> _typesSpecificValues - I know it won't compile but I don't know how else to express what I mean.

I need to avoid creating an inheriting class for each type of packet because there are about 50 types - or am I just being lazy??

+7  A: 

It sounds like you should be creating separate classes, yes.

However, I'm not sure whether I'd make them derive from this class. It sounds like this should be in a Header class (or possibly even a struct) and then you could have multiple classes which each contain a Header.

Jon Skeet
Thanks. It just seems like a bad design to be creating 50+ new classes to represent something seemingly so simple.
rmx
@rmx: You're representing 50 different types of data, by the sounds of it. It doesn't sound unreasonable to have 50 different types.
Jon Skeet
@Skeet: I have to disagree with you since this is an obvius example of overuse of Inheritance. It IS unreasonable to create so many classes that will behave similarly. Instead it is better than having only a "base" class for Packet and many Decorator (pattern) classes that add properties to the existing Packet class.
Carlos Muñoz
@Carlos: Did you notice how I suggested he *didn't* use inheritance? I've suggested using composition instead. Could you quote exactly which bit of my answer you disagree with?
Jon Skeet
@Skeete: My disagreement is not in the answer but in the comment: The 50 different types part, It does sound unreasonable for me to have so many classes that differ in having or not having some property. Anyway i misread the answer, my mistake :(
Carlos Muñoz
+2  A: 

Based on your brief description it sounds more like they should be structs instead of classes. Take a second look at your 50+ different definitions and try to see what is really different about them. For example, if half get processed one way and half another maybe you really just have two classes that know how to deal with the different structs.

BitOff
+1  A: 

What you need to ask yourself is: does is make any sense to use 'Packet' by itself?. Will you be accessing the base class's properties in all/most uses?

For example, let's say you have:

public class CommPacket : Packet
{
    public string Message { get; set; }
}

Would it be typical to access CommPacket.Length? Or would it ever make sense to pass a CommPacket to some class that accepted a Packet as a parameter? If the answer to either of these is Yes, you should be using a base class.

Jess
+1  A: 

If you have so many different types of classes with many diverse caracteristics between them you should not use inheritance but instead you should use Composition.

Read this article that explains it way better than I could.

EDIT

Read this even better chapter about the decorator pattern from the excellent book Head First: Design Patterns

To make sure I get you attention to this book here there are some screenshots:

Inheritance Inheritance

Composition Composition

Carlos Muñoz