none
How to implement the Factory Method design pattern with 15 subclasses? RRS feed

  • Question

  • Hi!

     

    I am new to software design and first time using GoF design patterns.

     

    I have a situation where the Factory Method design pattern seems a suitable solution.

     

    There are 15 different message formats (there can be more in future) and each has different number of fields and a different pasing algorithm. So an IMessage interface is will be parent to 15 concrete Message classes (1 for each message format). A Creator class will contain IMessage and create concrete Message objects by parsing the message string.

     

    The problem to me is having 15 different classes! This is a big number of classes (or is it?) Please tell me whether this is a good solution, or I better use a single Creator class with 15 different parsing methods. Or if there is any other design pattern more suitable but without that many classes?

     

    Help highly appreciated!

     

    Cheers!

    Thursday, July 3, 2008 2:38 PM

Answers

  • Since I dont know what is unique in the 15 concrete classes, I can not say how to collapse them.  There is probably a good reason to have 15 concrete classes as well.

     

    Your approach is good, not bad at all.  Only suggestion I would add on to this, is using a IOC(Inversion of Control) Container to create runtime objects of these classes instead of having your own creator class.  Some of the ones I would recommend are SpringFramework.NET, Unity from Enterprise Library and Ninject

     

    If you need more help, reply to this response.

    Thursday, July 3, 2008 5:21 PM
  • If they all implement the same interface and the concrete classes handle it slightly different, then I would agree on keeping your Factory Method.

     

    You could also Implement IDisposable that way you can use "using" on the class that gets instantiated. Because as you hinted it will be short lived [It's just parsing a message?]

     

     

     

    Thursday, July 3, 2008 10:29 PM
  • I doubt it would be a good solution to have a single creator class with 15 parsing methods.  It could be very confusing to use.  So I agree that the factory pattern would be a suitable solution.

     

    Depending on the differences between the classes it may also be possible to reduce the number of classes by using the strategy pattern.  For example, there may be message formats with very similiar parsing algorithms.

    Friday, July 4, 2008 8:03 AM
  • Either may be useful depending on your domain.

     

    Not sure if it would help in your scenario but it would be worth looking at.  You might have sub sets of message formats that have the same properties but the parsing changes or the parsing is the same but with different properties.

     

    Perhaps an example from my experience would be helpful;

     

    I worked for a financial institute that had to get some data from a supplier.  This supplier could change and the delivery mechanism could change (Ftp, Smtp, Web service etc).

     

    Most of the functionality was the same, the only difference was the algithim to get the data (log onto ftp server, locate file, parse it into our format etc).

     

    We wrote a service to load the data into our systems and used the strategy pattern to encapsulate the supplier/format specific code.

     

    We ended up having an FtpSupplierX, FtpSupplierX, WebServiceSupplierY strategy.  This lowered the time it would take to switch suppliers (and therefore made our negotiations more aggressive!)

     

     

    Wednesday, July 9, 2008 11:57 AM

All replies

  • Since I dont know what is unique in the 15 concrete classes, I can not say how to collapse them.  There is probably a good reason to have 15 concrete classes as well.

     

    Your approach is good, not bad at all.  Only suggestion I would add on to this, is using a IOC(Inversion of Control) Container to create runtime objects of these classes instead of having your own creator class.  Some of the ones I would recommend are SpringFramework.NET, Unity from Enterprise Library and Ninject

     

    If you need more help, reply to this response.

    Thursday, July 3, 2008 5:21 PM
  • If they all implement the same interface and the concrete classes handle it slightly different, then I would agree on keeping your Factory Method.

     

    You could also Implement IDisposable that way you can use "using" on the class that gets instantiated. Because as you hinted it will be short lived [It's just parsing a message?]

     

     

     

    Thursday, July 3, 2008 10:29 PM
  • I doubt it would be a good solution to have a single creator class with 15 parsing methods.  It could be very confusing to use.  So I agree that the factory pattern would be a suitable solution.

     

    Depending on the differences between the classes it may also be possible to reduce the number of classes by using the strategy pattern.  For example, there may be message formats with very similiar parsing algorithms.

    Friday, July 4, 2008 8:03 AM
  • Thanks Everybody!

     

    G Moore, can you please give an example of how can the Strategy pettern help reduce the number of classes? Are you suggesting using the Strategy pattern instead of Factory Method? or in conjunction?

    Wednesday, July 9, 2008 11:06 AM
  • Either may be useful depending on your domain.

     

    Not sure if it would help in your scenario but it would be worth looking at.  You might have sub sets of message formats that have the same properties but the parsing changes or the parsing is the same but with different properties.

     

    Perhaps an example from my experience would be helpful;

     

    I worked for a financial institute that had to get some data from a supplier.  This supplier could change and the delivery mechanism could change (Ftp, Smtp, Web service etc).

     

    Most of the functionality was the same, the only difference was the algithim to get the data (log onto ftp server, locate file, parse it into our format etc).

     

    We wrote a service to load the data into our systems and used the strategy pattern to encapsulate the supplier/format specific code.

     

    We ended up having an FtpSupplierX, FtpSupplierX, WebServiceSupplierY strategy.  This lowered the time it would take to switch suppliers (and therefore made our negotiations more aggressive!)

     

     

    Wednesday, July 9, 2008 11:57 AM
  •  

    Thanks G Moore. That will help.
    Wednesday, July 9, 2008 12:55 PM