Separate Class vs Method

Question

Quick design question.

ClassA has a method called DoSomething(args)

In DoSomething(), before it can actually do something, it needs to do some preparatory work with args. I believe this should be encapsulated within ClassA, (as opposed to doing the prep work outside and passing it in) as nothing else needs to know that this prep work is required to DoSomething.

However, it's where the actual preparatory work code belongs that is making me think.

The preparatory work in my particular example is to create a list of items, which satisfy a certain condition, from args.

My hunch is that I should create a new class, ListOfStuff, which takes args in its constructor and put this preparatory work here.

From a TDD-perspective, I think this is the right choice. We can then unit test ListOfStuff til our heart is content. If we had put the preparatory work in a private method of ClassA, we'd have only been able to indirectly test it through testing DoSomething().

But is this overkill? Since adopting the TDD and DI approach, I've seen the number of classes that I write multiply - should I be worried?

Ta.

Answer 1

There are a couple of heuristics here.

1. Is there state on this class that survives from invocation to invocation? Does this prep work get done every time you need to doSomething(), or is it done and saved? If so, that argues for the class.
2. Does this computation need to happen in more than once place? If so, that argues for a class.
3. Can the details of the implementation of the doSomething() method, or the preparation work for it, change without affecting the enclosing class? If so, that argues for a class.

Well, three heuristics. No one expects the Spanish Inquisition.

Answer 2

What is the simplest thing that could possibly work? That's the TDD mantra. Don't try to think too far ahead. If the time comes to create the helper class, you'll know it because you'll be doing all sorts of related work in multiple methods in other classes. Until then, do the work in your method. If it makes the method too long or cumbersome to read, extract the work to its own method. This method can also be tested to your heart's content without the need for another class.

Answer 3

Definately put it in a new class. Its called separation of concerns. You don't want to overload a class and make it do all sorts of other stuff. This is because your class will not be able to be used anywhere else as its so specific to one thing.

Put it in class, then use that class elsewhere. Otherwise you'd have to write this again and again in the future.

To make it extensible, and be able to pass in all sorts of different algorithms, the design pattern your after here is the Strategy pattern. But that is for the future...