Action objects VS handle/service-methods

Question

a short question:

class ItemActionObject
{
    private final Object moreParameters;
    private final Object otherDependencies;
    private final Item item;

    public ItemActionObject(Item item, Object moreParameters, Object otherDependencies)
    {
        this.item = item;
        this.moreParameters = moreParameters;
        this.otherDependencies = otherDependencies;
    }

    public Object process()
    {
        //do some processing -> return result
    }
}

VS

class ItemHandler //or ItemService
{
    private final Object otherDependencies;

    public ItemHandler(Object otherDependencies)
    {
        this.otherDependencies = otherDependencies;
    }

    public Object process(Item item, Object moreParameters,)
    {
        //do some processing -> return result
    }
}

ActionObject:

• It seems to be more object oriented
• It treats the item as part of its own instance (in design-view)
• I can add there some more methods, to change options (moreParameters) later
• I dont have one process-method with a lot of arguments
• But: I have a lot of boilerplate code
• But: I instantiate one object only for one process-run and throw that object away after that.

Handler-Method:

• It is classic procedural-programming, i guess? (a negative point?)
• It has a separate view on the behaviour and on the item (in design view)
• It dont waste that much ressources, if i want to process 100 000 items, so i dont have to create 100 000 ItemActionObjects to process them, i just have to do 100 000 method-calls to process(item...)

Examples: Design: Object method vs separate class's method which takes Object as parameter? (the pdfPrinter is designed with a Service/Handler-class)

Example2: Some CSV-, or HTML-Export handler or Action-Object, where the export-classes encapsualte the behaviour of the export-algorithm and the item is some item with a well-definend interfaces, from where the exporter can get the correct data out of them to do its job.

Example3: I think a lot of things or all things in the world we can design like ItemActionObject or ItemHandler

So my question is, which one should i choose? Maybe your answer is: it depends. So my question is also, which more criteria i have to know to decide which solution is better. Maybe there are some criteria to get me on the way in some situations to use ItemActionObjects, in other situations ItemHandlers. But maybe there are also often criterias which speaks for both solutions. And which should i use then? (Im not a friend of throwing a coin^^)

Answer 1

Let me scetch the general situation:

• you have some parameters for an object, and
• there is some method m to be called after its construction, working with these parameters.

Now you are unsure which of the parameter to pass through the constructor (to be stored in some member variables), and which ones to pass through the method m(...) - both approaches will technically work. Then ask yourself

• what do you want to happen when m is called more than once?

• which of the parameters will always stay the same, and which ones may have to be changed between different calls?

• in case object construction happens at a different place/scope apart from calling m: are there parameters which are not known at construction time?

Naturally, the non-changing parameters go into the constructor, and the changing ones become parameters of m. If you have parameters which are non-changing now, but might become changeable later, then start with what you have now, build the most simple approach you can think of and refactor in case requirements change.

And that's it. Don't overthink this. None of the alternatives is more or less object oriented than the other, and you need context to answer the questions above. And what I wrote is not just valid for "Action objects" or "Handlers", but holds for any other kind of class following the same basic structure.

Answer 2

Of course "it depends" :) The criteria to decide is the rest of your design and the business case.

No object exists in isolation, or put it another way: There is no "optimal" design for any object in any absolute sense. Let me give you an example.

Let's imagine we have an Image object, and we can save() it. Do I supply the file name as parameter to save(). Or does the Image know the file it "goes to"? You might be tempted to say that images shouldn't know the file they go to, because you could easily save the image to different files.

But could you really? What if you have a command line application where the filename is specified on invocation and can not change? Do I want other classes to know about the file name when in reality it doesn't really change and could be fixed? It's less knowledge for other objects not knowing the filename.

So the criteria are:

• Are the construction and usage of the object even in different places? If not then it doesn't really matter.
• Should/must other objects know about those parameters?
• Could you reduce knowledge about this thing in any of the options for others?