Extending a class versus new class with static methods 1

[logicg8]

I am working with a library that has a class called Message. I need to have a way to determine if the message is a duplicate, a test message, or if it is one of a few other types of messages. The duplicate check will be made against a database. The rest of checks will be based on just the message itself.

The library Message class does not have methods to do this. Should I extend the Message class to add these methods or would it be better to add a Filter class with static methods that can do these checks?

Thanks in advance for your help.

 

[jmeckley]

i think the term "static methods" imply a specific choice of language. the advice you receive here may not be in your specific language but the concepts will carry over.

What is a message? is this a rich domain object, or a simple dto? This will have some weight as to where the logic goes.

you mention 2 specific tests (duplicate message and test message) and then "a few other types". what is the context of determining the type of message? for example: are you validating the message? determining how to process the message? logging the message? etc.

generally it's a good practice to avoid the static keyword. static implies singletons and singletons are usually unnecessary. that doesn't mean you should extend the message object either. how the message is handled is different than what the message is.

Jason Meckley
Programmer

faq855-7190
faq732-7259

 

[logicg8]

Thanks for the reply.

The language will be Java.

Message is a very rich domain object (it's quickfix.Message and has methods to parse the message (private), etc. ).

To determine the type of message, I look at the field values of the message. For example,

if (message.getSender().equals("bob") || message.getSender().equals("fred")) { // we have a core trade message }

The results of these checks determine if we should process the Message.

My first thought was to have a class called MessageFilter. Since the methods of the class only need to receive a Message object and indicate if it should be processed, I had the methods as static (requiring no instance data).

Later, I second guessed myself and thought of creating a model class FilterableMessage that extended Message giving the class the ability to tell you its type.

 

[logicg8]

I meant to also note that the decision to process the Message is in another class (e.g. Controller). The MessageFilter or FilterableMessage would only tell the Controller the type of Message (via a boolean). For example the Controller would make a call like this...

if (filterableMessage.isCoreTradeMessage()) {
//process }
else { //don't process
}

OR

if (MessageFilter.isCoreTradeMessage(message)) {
//process }
else { //don't process
}

 

[jmeckley]

In that case I would not extend the message object. I would create a filter interface to determine if the message can be processed. this will allow you to easily create new filters when the need arises.

I would also keep the details of filtering the message separate from actually processing the message. create a composite object which is really just a wrapper around the filter and controller. here is one example:

class FilteredController : Controller, Filter
{
   public FilteredController(Controller controller, Filter filter)
   {
        this.controller = controller;
        this.filter = filter;
   }

   public bool CanProcess(Message message)
   {
       return filter.CanProcess(message);
   }

   public void Process(Message message)
   {
       controller.Process(message);
   }
}

interface Controller
{
   void Process(Message message);
}

interface Filter
{
   bool CanProcess(Message message);
}

you can then have specific implementations of the filter and the controller which have no knowledge of each other.
create a collection of FitleredControllers and loop through

var controllers = new [] {
      new FilteredController(new ThisFilter(), new ThisController()),
      new FilteredController(new ThatFilter(), new ThatController()),
   };
foreach(var controller in controllers)
{
   if(controller.CanProcess(mesasge) == false) continue;

   controller.Process(message);
   break;  //assumes exactly one controller will handle the message.
}

that's one approach to the problem. I believe some form of chain of command would work well for your scenario.

Jason Meckley
Programmer

faq855-7190
faq732-7259

 

[logicg8]

The FilteredController idea with interfaces is great. Thanks for the excellent advice.

Yes; after looking at your approach and thinking about the design a bit more, I think I have two layers of filtering. One would be the initial decision if we should process the message (canProcess). Then, out of the messages that I canProcess, I must figure out what type of messages it is (probably a second layer of FilteredControllers). Depending on the type of message, I will map it into either my domain object A or my domain object B. There are four different types of messages that will differ mapping logic.

Later, I will then do some transformation and eventually insert into a database.

Does that seem to follow along the approach you were explaining or did I just introduce something that changes things?

 

[jmeckley]

nothing major. the process is sound. the only change is 2 layers of filtering. I would distinguish between the 2. one layer determines if you should continue at all. the second determines how you process the message (at least which controller processes the message).

all in all you're on the right track.

Jason Meckley
Programmer

faq855-7190
faq732-7259

 

[logicg8]

Great. Thanks again for your help. Do you have any design books that you would recommend?

 

[jmeckley]

1. Release It! by Nygard
2. Domain Driven Design by Eric Evans
3. Patterns of Enterprise Application Architecture by Fowler
4. Head First Design Patterns by Freeman & Freeman
5. Clean Code

#4 is a good, fun introduction to patterns. i recommend this for someone just starting out.
#2 helps you understand how to model your code to the business problem. It's also the bible for DDD. Most of the common vernacular of DDD comes from this book.
#3 is very deep. the good news is that there are open source frameworks which solve each of the problem mentioned in the book. This is great to know the principles behind those frameworks and how to roll your own, if the need arose.
#4 is pragmatic advice. it's not so much about patterns and code, but how to structure your application to avoid catastrophe. it's an entertaining read as well.
#5 was recommended to me recently. I haven't read this yet.

Jason Meckley
Programmer

faq855-7190
faq732-7259

 

[jmeckley]

I just came across this blog today. I read through a few posts and like what this guy has to say about design.

http://simpleprogrammer.com/

Jason Meckley
Programmer

faq855-7190
faq732-7259

 

[logicg8]

Thanks for the great resource information.