How to reverse design?
Arjan de Haan
I'm building a library which allows callee's (applications) to send
messages (any kind) to recipients. These messages could be regular
email, SMS or other kinds of messages. So they are NOT windows messages!
So far, I have the following hierarchy for the message structures:
TMessageRequest
^
|
+-----------+---------------+
| |
TMailRequest TSMSRequest
TMessageRequest holds several general attributes about messages to be
sent, such as the Sender and a list of Receivers.
Problem is, the original concept was that the Sender (which is a person
logged in) has various flags to tell which type of message request to
use. Eg. he/she would want to send messages only by mail, not by SMS.
Now, my client has decided that it needs to be the other way around: the
_Receiver_ of a message flags how he/she wants to receive the message
(OK, some hindsight here....).
Now I'm stuck on how to 'reverse' this design! Since the Sender doesn't
(need to) know how its Receivers want to receive the message...
I've been thinking about the idea of having the base class
TMessageRequest hold all attributes needed for any of the descendant
classes, but that strikes me as a bit odd. Since the hierarchy might be
extended later on to tackle new or additional message types, this would
create a very fat base class. Not nice.
Problem is that I (the callee) don't know upfront what attributes are
required to send a message to a particular Receiver. A email for example
has a subject, whereas a SMS doesn't. Both do have a message body, and a
(list of) Receivers, but that's about it.
Anybody has any other ideas on this? Any input appreciated.
...Arjan...
Marc Rohloff [TeamB]
<snip>
I would start by trying to make a message just that, a message with
attributes without worrying about how it will be sent. This would mean
that the sender should just supply all the attributes since it does
not know which ones are needed (Assuming there isn't a high cost to
getting the attribute).
I would then let each of the recipient objects worry about sending the
message to themselves.
--
Marc Rohloff [TeamB]
marc -at- marc rohloff -dot- com
Arjan de Haan
> On Wed, 09 Jul 2008 09:35:48 +0200, Arjan de Haan wrote:
>
> <snip>
>
> I would start by trying to make a message just that, a message with
> attributes without worrying about how it will be sent. This would mean
> that the sender should just supply all the attributes since it does
> not know which ones are needed (Assuming there isn't a high cost to
> getting the attribute).
>
> I would then let each of the recipient objects worry about sending the
> message to themselves.
>
Marc,
if I understand you correctly, that would mean the 'fat-baseclass'
option. It is not that much work to apply this to the current classes,
but it doesn't feel ...right :(
Sending it is not a problem. The framework for selecting the proper
mechanism for sending (and actually sending) messages is in place, and
works. That's part of the 'challenge': there exists a complete framework
which works well, but now this minor (albeit important) detail - a
simple change of viewpoint for a specific attribute - needs to be changed.
If they only had decided on this a couple of weeks earlier. <sigh>
Thanks for the help.
...Arjan...
Andrea Raimondi
Sending a message is a completely different matter from receiving it.
If your recipient wants to receive an email as an sms, then when you read in
the email message just forward it as sms.
I really don't see the issue here.
You must simply have a proxy that reads messages in and decides how to
dispacth them - no big deal, imho.
Andrew
Marc Rohloff [TeamB]
> if I understand you correctly, that would mean the 'fat-baseclass'
> option. It is not that much work to apply this to the current classes,
> but it doesn't feel ...right :(
No, I was suggesting that your message class be very lightweight with
very few methods and you delegate sending to another class.
var msg:TMessage; svc:TMessagingService;
msg := TMessage.Create;
msg.Subject := ...
msg.Body := ...
for recipient in recipients do
begin
svc := ServiceFor(recipient.PreferredFormat);
svc.SendMessage(recipient, msg);
end;
dot
> No, I was suggesting that your message class be very lightweight with
> very few methods and you delegate sending to another class.
>
> var msg:TMessage; svc:TMessagingService;
>
> msg := TMessage.Create;
> msg.Subject := ...
> msg.Body := ...
>
> for recipient in recipients do
> begin
> svc := ServiceFor(recipient.PreferredFormat);
> svc.SendMessage(recipient, msg);
> end;
>
Marc,
funny, that's more or less the way I programmed it now. The
TMessageRequest is only a class holding the properties common for (at
this point) the TMailRequest and the TSMSRequest. Sending the message is
done by another class.
But as you and Andrew suggested, I'll go with the design you propose.
Thanks for your suggestion.
...Arjan...
dot
> I honestly don't see the problem with it.
>
In my opinion (and I hope it's a sane one) you wouldn't normally have a
class holding all attributes, including those for specialist behavior.
You design a hierarchy with a common base class, and specialize on that
by descending from that class. That's the current model anyway.
Having only a single 'fat class' (fat, as in having lots of attributes
which only have meaning in some of the intended usage) just doesn't feel
completely right, but as I wrote in response to Marc, I do not see
another way of doing this. I was hoping someone had a better design for it.
> Sending a message is a completely different matter from receiving it.
> If your recipient wants to receive an email as an sms, then when you read in
> the email message just forward it as sms.
> I really don't see the issue here.
>
> You must simply have a proxy that reads messages in and decides how to
> dispacth them - no big deal, imho.
>
See my response to Marc. I have a dispatching framework which is capable
of handling every type of message, but currently relies on the hierarchy
described in my OP. I'll be 'reversing' it to the structure you and Marc
suggested.
Marc Rohloff [TeamB]
> Having only a single 'fat class' (fat, as in having lots of attributes
> which only have meaning in some of the intended usage) just doesn't feel
> completely right, but as I wrote in response to Marc, I do not see
> another way of doing this. I was hoping someone had a better design for it.
Although I agree about not having fat classes, why make the sender
worry about what attributes are required? Especially since the
recipients could be a combination of SMS and EMail messages.
You would land up with code like:
if AnyRecipientIsEmail
then msg.Subject := SomeValue
To me it is much clearer and simpler just to skip the if part (unless
SomeValue takes a long time to calculate)
Andrea Raimondi
news:4875...@newsgroups.borland.com...
> You design a hierarchy with a common base class, and specialize on that by
> descending from that class. That's the current model anyway.
Exactly. Your sender classe may, for example, be an email one.
Now, your receiver wants to see that email as an sms, the proxy allocates an
SMS class,
maps the attributes appropriately and forwards it. It's the proxy that needs
to read a configuration item and
factory the appropriate class, agnostically in respect of what was sent in
the first place.
> Having only a single 'fat class' (fat, as in having lots of attributes
> which only have meaning in some of the intended usage) just doesn't feel
> completely right, but as I wrote in response to Marc, I do not see another
> way of doing this. I was hoping someone had a better design for it.
WHERE did you read me saying anything like that?
You need a mediator between your sender and your recipient.
Andrew