Design Question

[Alex]

Hi,

I am writing a chat server application and am currently stuck at a
general question of OO design.

I am wondering what would be the best way to manage the existing
channels. Each channel is represented by a seperate instance of a class
and I need to have a central repository to access them.

Now I could simply add a static hashtable to the channel class and have
the channels self managing them by adding each new instance from its
construnctor. The second way could be a central manager class which does
all the handling.

The latter solution looks a bit cleaner to me because the particular
jobs are separated, however at the same time it also seems a little bit
like a waste of resources, because it introduces a class (with
additional memory and CPU allocations) which basically just "extends" a
hashtable and can also be solved via the former solution.

I'd really appreciate any comments about this. Thanks

Alex

 

[shakah]

You didn't offer at lot of specifics about your design, but my
inclination would be to make Channel an interface, and create a
ChannelFactory class to create concrete implemenations of Channels and
otherwise manage them (i.e. function as a "central repository").

 

[Alex]

You didn't offer at lot of specifics about your design, but my
inclination would be to make Channel an interface, and create a
ChannelFactory class to create concrete implemenations of Channels and
otherwise manage them (i.e. function as a "central repository").

Thanks, but why an interface? I only have one kind of channel. Basically
I have n instances of a class and need to keep control over them
somehow. The manager class I I wrote about would have a hashtable with
all channel instances and some additional methods for other channel
related tasks. I could also move this hashtable into the channel class
and make is static. Is there any downside by that?

 

[shakah]

At the moment the static hashtable in the Channel class works, but for
that matter so would your Manager class. It all comes down to which
design will be more resilient as new requirements pop up in the future.
Isn't there a chance that at some later date you might offer an
EnctyptedChannel, a VideoChannel, allow others to create different
types of channels, or even retrofit the Channel behavior onto an
existing class? That's when using an interface and creating a
ChannelFactory would shine.

 

[Alex]

At the moment the static hashtable in the Channel class works, but for
that matter so would your Manager class. It all comes down to which
design will be more resilient as new requirements pop up in the future.
Isn't there a chance that at some later date you might offer an
EnctyptedChannel, a VideoChannel, allow others to create different
types of channels, or even retrofit the Channel behavior onto an
existing class? That's when using an interface and creating a
ChannelFactory would shine.

Well, there is always a chance , but at the moment I rather very much
doubt it. Basically the channel object is no more than a good old C
struct or Pascal record. It got some management methods but overall it
only holds integers, strings and lists.

What I am wondering is, whether there is any advantage in either the
static hashtable way or the manager class solution.

 

[Ferenc Hechler]

What I am wondering is, whether there is any advantage in either the
static hashtable way or the manager class solution.

The manager class will also have a hashtable to manage the channel objects.
And every method of the managing class will be equivalent to a static method
in the channel class.

Example with ManagerClass:

ManagerClass
private HashMap
public addChannel
public getChannel

ChannelClass
public ChannelClass
public sendChannel

Example without ManagerClass

ChannelClass
private static HashMap
public ChannelClass
public static addChannel
public static getChannel
public sendChannel

So the difference of the two approaches is wether the managing functions are
separated from the channel functions.

The solution using a ManagerClass is easier to understand and more flexible
for future use. You could decide to have more then one Collection of
Channels to be managed, which would not be possible using ONE static
HashMap.

Best regards,

feri

 

[Alex]

The manager class will also have a hashtable to manage the channel objects.
And every method of the managing class will be equivalent to a static method
in the channel class.

Correct, although there wouldnt be a dedicated "add" method in the
channel class, because it would already add itself to the list in its
constructor.

So the difference of the two approaches is wether the managing functions are
separated from the channel functions.
Exactly.


The solution using a ManagerClass is easier to understand and more flexible
for future use. You could decide to have more then one Collection of
Channels to be managed, which would not be possible using ONE static
HashMap.

Yes, it seems to be the cleaner solution. The only thing I worry about
is, whether its really necessary/advisable to introduce an own class for
a trivial task like managing a hashtable (more or less).

Thanks Feri.