How could you improve this code design?

Question

Lately, I've been making use a lot of the Strategy Pattern along with the Factory Pattern. And I really mean a lot. I have a lot of "algorithms" for everything and factories that retrieve algorithms based on parameters. Even though the code seems very extensible, and it is, having N factories seems a bit of an abuse.

I know this is pretty subjective, and we're talking without seeing code, but is this acceptable in real world code? Would you change something ?

Answer 1

OK- ask yourself a question. does/will this algorithm implementation ever change? If no then remove the strategy.

Answer 2

Whenever I'm implementing code in this fashion, some questions I ask are:

1. what components do I need to substitute to test ?
2. what components will I expect users/admins to disable or substitute (e.g. via Spring configs or similar) ?
3. what components do I expect or suspect will not be required in the future due to (possibly) changing requirements ?

This all drives how I construct object or components (via factories) and how I implement algorithms. The above is vague, but (of course) the requirements can be similarly difficult to pin down. Without seeing your implementation and your requirements, I can't comment further, but the above should act as some guideline to help you determine whether what you've done is overkill.

Answer 3

If you're using the same design pattern all over the place, perhaps you should either switch to a language that has better support for what you're trying to do or rethink your code to be more idiomatic in your language of choice. After all, that's why we have more than one programming language.

Answer 4

Can't you make an AbstractFactory instead off different standalone factories?

AlgorithmFactory creates the algorithms you need based on the concrete factory.

Answer 5

Would depends on the kind of software I'm working on.

Maintenance asks for simple code and factories is NOT simple code.

But extensibility asks sometimes for factories...

So you have to take both in consideration.

Just have in mind that most of the time, you will have to maintain a source file MANY times a year and you will NOT have to extend it.

IMO, patterns should only be used when absolutely needed. If you think it can be handy in two years, you are better to use them... in two years.

Answer 6

How complex is the work the factory is handling? Does object creation really need to be abstracted to a different class? A variation of the factory method is having a simple, in-class factory. This really works best if any dependencies have already been injected.

For instance,

public class Customer
{
  public Customer CreateNewCustomer()
  {
    // handle minimally complex create logic here
  }
}

As far as Strategy overuse... Again, as @RichardOD explained, will the algorithm ever really change?

Always keep in mind the YAGNI principle. You Aren't Gonna Need It.

Answer 7

I am maintence.

I once was forced (by my pattern lovin' boss) to write a set of 16 "buffer interpreter tuxedo services" using an AbstractFactory and a double DAO pattern in C++ (no reflections, no code gen). All up it something like 20,000 lines of the nastiest code I've even seen (not the least because I didn't really know C++ when I started) and it took about three months.

Since my old boss has moved on I've rewritten them using good 'ole "straight up and down" procedural style C++, with couple of funky-macros... each service is like 60 lines of code, times 16... all up less than a 1000 lines of really SIMPLE code; so simple that even I can follow it.

Cheers. Keith.