Object Design

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I've a number of objects (classes) defined in an application which I'm using
to model packets on a network. I have a class hierarchy of Packet (inherited
by) EthernetPacket (inherited by) IPPacket (inherited by) TCPPacket.

I've some control logic which takes in a data stream and determines which
kind of packet to create. Should this logic be within the constructors of the
packet classes - so I create a Packet and within the contructor of the packet
it itself determines if it's an ethernet, ip or tcp packet.

At the root of this is can a base class change itself into a subclass or
does the determination of the class type have to be down outside of the class
structure.

What I'm finding now is that the logic that determines if a packet is a TCP
packet is encapsulated within it's base class (the IP packet) and therefore I
need to firstly create an IP packet - call the method of the IP object to
determine if this is a TCP packet and then create a TCP packet (and delete
the IP packet) - is this the way to do it or should I recast the IP packet as
a TCP packet.

Sorry if this is confusing.
tia
 
Rob said:
I've a number of objects (classes) defined in an application which I'm
using
to model packets on a network. I have a class hierarchy of Packet
(inherited
by) EthernetPacket (inherited by) IPPacket (inherited by) TCPPacket.

I've some control logic which takes in a data stream and determines which
kind of packet to create. Should this logic be within the constructors of
the
packet classes - so I create a Packet and within the contructor of the
packet
it itself determines if it's an ethernet, ip or tcp packet.

At the root of this is can a base class change itself into a subclass or
does the determination of the class type have to be down outside of the
class
structure.

What I'm finding now is that the logic that determines if a packet is a
TCP
packet is encapsulated within it's base class (the IP packet) and
therefore I
need to firstly create an IP packet - call the method of the IP object to
determine if this is a TCP packet and then create a TCP packet (and delete
the IP packet) - is this the way to do it or should I recast the IP packet
as
a TCP packet.

Sorry if this is confusing.

No this is a common problem. A superclass constructor cannot actually
create a subclass. Just can't. You need to use a factory method, often a
static method on the superclass type that makes a runtime decision about
which subtype to create an and return.

Something like:

public class Packet
{
public static Packet NextPacket(DataStream s)
{
if (whatever)
{
return new IPPacket(s);
}
else
{
return new TCPPacket(s);
}

}
. . ..
}

David
 
Hi,

You won't be able to change the type from within the type's constructor.

It sounds to me like you need a class factory. Create a class that can
create packets based on the specified stream:

// C# 2.0 example

public static class PacketFactory
{
public static Packet CreatePacket(Stream stream)
{
// TODO: determine type of stream and return appropriate packet
}
}

Start from the least-derived type and work your way towards the most derived
type. If the stream is Tcp then return a TcpPacket. Else, if while
checking for tcp you discovered that the stream was IP then create an
IPPacket. Else, if while checking for ip, you discovered that the stream
was ethernet then create an EthernetPacket.

Just call the PacketFactory.CreatePacket method anytime you need a packet in
code based on a stream.
 
Thanks - I thought it might require this.

David Browne said:
No this is a common problem. A superclass constructor cannot actually
create a subclass. Just can't. You need to use a factory method, often a
static method on the superclass type that makes a runtime decision about
which subtype to create an and return.

Something like:

public class Packet
{
public static Packet NextPacket(DataStream s)
{
if (whatever)
{
return new IPPacket(s);
}
else
{
return new TCPPacket(s);
}

}
. . ..
}

David
 
Back
Top