Java Design Patterns – Refactoring an Existing Abstract Class and Its Parameters

abstract classabstractiondesigndesign-patternsjava

I have an abstract class A which declares an abstract method doStuff. Currently there are many classes that inherit from A and implement doStuff.

The class' instances are initialized at run-time via AFactory based on user input.
Originally all the classes had the same single parameter (the user input). But now I have an additional parameter that only a new class that inherits A needs.

So breaking it down I though of the following logic:

The interpreter class that generates instances based on user input(using AFactory of course) was not aware of this extra parameter.
- Trying to push it into the class interpreter class would be really awkward because then I would have to know when to pass it to the factory which defeats the whole purpose of having a factory in the first place.
- Sending it blindly into the Factory hoping it might do something with it seems quite ugly as well.
My current solution: Meanwhile I've decided to refactor A.doStuff(Param param) into A.doStuff(AParams params).

AParams can hold what ever parameters needed and doStuff can ignore then if they're not interested in them. This also seems a bit awkward to me , and remids me of sending structs in WIN32API that can hold a lot of ugly useless parameters and I'm not fond of it.

Is there a more elegant way to approach this problem ? Or some design pattern that I've overlooked and solves this?

Notes :

We're using Java 1.7
The class' names are silly in order to emphasize the theoretical design issue they do have normal indicative, meaningful names in reality 🙂
I did search quite a lot but having figured out that it's quite hard to search the web for specific abstract theoretical issues (as opposed to why is X throwing Exception in this code) I've decided to ask anyway so I'm sorry if this is a duplicate.

Edit 1:

Clarification: I need to pass a subclass-specific argument to the doStuff method.

EDIT 2:

I did not fully understand Kilian Foth's intention so I've written some Java-pseudo-code to help me better explain the problem/understand your solution. So:

This is a skeleton of my problem.

This is a skeleton of my solution.

This is what I think might be Kilian Foth's solution, but I'm not sure.

Best Answer

The point of a factory is to hide the fact that you may get objects from slightly different classes. Therefore, if some of these objects need certain data and others don't...

Either they aren't similar enough to be produced by the same factory. Then you need to have more than one factory and make the decision way earlier than you are currently doing.
Or they are similar enough that the client isn't supposed to care which one they get. Then you can't expect the client to care about whether to send the extra data or not. It follows that they must always be passed, but the factory will sometimes ignore them without bothering the client with that implementation detail. Anything else would burden the client with the very distinction that the factory was supposed to conceal.

Related Solutions

Java Template Method Pattern with Varying Input Types

Use generics to specify the parameter type. The parent class would restrict this parameter to be a subclass of GeneralParameter:

abstract class GenericAlgorithm<Param extends GeneralParameter> {
    void someMethod(Param p);
}

Then, the subclass would extend the parent class but provide the used parameter type as a type argument:

class ConcreteAlgorithm extends GenericAlgorithm<SpecificParameter> {
    @Override
    void someMethod(SpecificParameter p) {
        ...
    }
}

Note that this may require you to also use generics for other parts of your program if you want to avoid casting. Here's a full (albeit contrived) example that creates Sandwiches.

abstract class SandwichMaker<S extends Spread> {
    public void make(S spread) {
        toastBread();
        addSpread(spread);
        enjoy();
    }

    protected void toastBread() {
        System.out.println("...toasting bread");
    }

    protected abstract void addSpread(S spread);

    protected void enjoy() {
        System.out.println("this is yummy!");
    }
}

class CheeseSandwichMaker extends SandwichMaker<Cheese> {
    @Override
    protected void addSpread(Cheese cheese) {
        System.out.println("... adding " + cheese.name + " cheese from " + cheese.origin);
    }
}

interface Spread {}
class Cheese implements Spread {
    public final String name;
    public final String origin;

    public Cheese(String name, String origin) {
        this.name = name;
        this.origin = origin;
    }
}

...

SandwichMaker<Cheese> sandwich = new CheeseSandwichMaker();
sandwich.make(new Cheese("Camembert", "Normandy, France"));
sandwich.make(new Cheese("Cheddar", "Somerset, England"));

See it live on ideone.

Java – Pattern for Validating Rules with Different Signatures

I guess your Rule class is an example of specification or command pattern. Definitely different rules will need different types of information to do its work, but if it were me, I would not pass those information during method invocation, I would use constructor instead. The information that is different from one rule to another is the implementation detail of that rule, the invoker of the rule should not need to know about that, the invoker just needs to know the public interface of the rule. The knowledge to construct the rule should be put on client or another class.

The client of MyClass is the one that pass array of rules to MyClass, so it can be the one who create the rule, or it can delegate to a factory class to create the rule, or if you use dependency injection, you can rely on IoC to inject the list of rules for you. Either case, the data that is different between each rule class should be passed in Rule at that time:

//Client
Rule[] rules = new Rule[2];
rules[0] = new AnExampleRule("some context information");
rules[1] = new AnotherRule(12);

MyClass myClass = new MyClass(rules);

Best Answer

Related Solutions

Java Template Method Pattern with Varying Input Types

Java – Pattern for Validating Rules with Different Signatures

Related Topic