<Generics> Is this a good use of Java Generics?! UPDATED: Another question included.

[Emanuele Ghe]

Hi,
I am doing a strange use of generics, and I would like to know from you if is a good use of them or if it's bad.

I wrote this interface:

public interface IExecutor {
    <T> boolean execute(T arg);
}

and this 2 implementing class:

public class Exec1 {
   public <T> boolean execute(T arg) {
      if(!(arg instanceof String)) throw new IllegalArgumentException();

     //rest of logic code, that NEEDS 'arg' to be a String
   }

}



public class Exec2 {
   public <T> boolean execute(T arg) {
      if(!(arg instanceof Integer)) throw new IllegalArgumentException();

     //rest of logic code, that NEEDS 'arg' to be an Integer
   }

}

Is this a BAD use of generics?

My aim with this code is to make a polymorphic use of Executor implementing classes, but the problem is that, depending from the Executor implementing class,
they need a specific type parameter, and that's why I am making the 'execute' method generic.


Is this bad ?
I mean, should generic methods be used only for methods that work whatever type 'T' you pass them, or can be used also in this case,
in which each different implementation of "execute(T arg)" method needs a particular Type to work ?

Thanks to all who will help me anwering.

[Ernest Friedman-Hill]

Yeah, that is pretty ugly. Why not do this?

interface IExecutor<T> {
    boolean execute(T arg);
}

class StringOnlyExecutor implements IExecutor<String> {
    public boolean execute(String arg) {
        ...
    }    
}

class AnythingExecutor implements IExecutor<Object> {
    public boolean execute(Object arg) {
        ...
    } 
}

[Emanuele Ghe]

Ernest Friedman-Hill wrote:Yeah, that is pretty ugly. Why not do this?

interface IExecutor<T> {
    boolean execute(T arg);
}

class StringOnlyExecutor implements IExecutor<String> {
    public boolean execute(String arg) {
        ...
    }    
}

class AnythingExecutor implements IExecutor<Object> {
    public boolean execute(Object arg) {
        ...
    } 
}

Eheh because I didn't think to it... I am really new to generics

Thanks a lot, this perfectly satisfies my needs!

[Emanuele Ghe]

I have a new question:

since I don't want to use "if-chaining", I am using an enum as a "router" between interface callers and interface implementations.

I post some example code.

This is the interface:

    
public interface IRecover<T> {

	boolean recover(T arg);
	
}

This is a class that implements the interface:

    
public class StartSessionTournamentRecoverer implements IRecover<Long> {

	public boolean recover(Long id) {
        ...
       }     
...
}

And this is the Router:

   

public enum DataRecoverRouter {
		
	startSessionTournament(new StartSessionTournamentRecoverer()):	
	
	
	private IRecover impl;
	
	private DataRecoverManager(IRecover impl) {
		this.impl = impl;
	}

	public <T> IRecover<T> getRecoverer() {
		return this.impl;
	}
	
}
 

Now, a "client class" can use this router in this way:

  
public class Client {  
...
Long arg = 0L;
DataRecoverManager.startSessionTournament.getRecoverer().recover(arg);
...
}

and this compiles fine, but I don't have type checking!
I mean, the class "Client" does not see which type the "recover" method argument must be, it only sees that it needs an "Object" as argument.

Is there a way to get compile-time type checking? Maybe the method

public <T> IRecover<T> getRecoverer() {
		return this.impl;
	}

needs some rework?


Thanks again to everyone that will help me.

[Ernest Friedman-Hill]

Think about what you're asking for. It sounds like you want compile-time type checking of a method, the type signature of which is unknown until runtime!

I think you may need to consider how to define IRecover without generics, so that the argument type(s) of recover() are sufficient for all implementations to work with. If you want to dynamically look up an implementation, then it has to be polymorphic!

[Emanuele Ghe]

Ernest Friedman-Hill wrote:Think about what you're asking for. It sounds like you want compile-time type checking of a method, the type signature of which is unknown until runtime!

I think you may need to consider how to define IRecover without generics, so that the argument type(s) of recover() are sufficient for all implementations to work with. If you want to dynamically look up an implementation, then it has to be polymorphic!

Well, actually "Googling" I've found someone that did what I mean, and actually I am studying his article to deeply understand and use his solution.

Here is the link:

http://www.rbgrn.net/blog/2008/04/advanced-typesafe-command-pattern-using-java-generics.html

[Ernest Friedman-Hill]

Emanuele Gherardini wrote:
http://www.rbgrn.net/blog/2008/04/advanced-typesafe-command-pattern-using-java-generics.html

I've read over that article twice, now, and I can't figure out what this gets you; it's seems to me it's really just an insanely complex way to emulate non-polymorphic method calls! The strength of the Command pattern is being able to bundle up many individual Commands and put them in a queue, or hand them to a Thread pool for execution, or pass them down a chain of command. As soon as you do any of these things with the "commands" described in that article, the information about the return type disappears -- you can't have a Queue<Command> which lets you recover that return type information -- and of course, that Queue would want to call those commands polymorphically, and in doing so, it wouldn't be prepared to handle the different return types anyway.

Everything in that article is statically bound: you need to know the class name, argument types, and return type of a Command to be able to use it. That means that the code can't make any use of new Commands discovered or loaded at runtime -- another traditional strength of the Command Pattern. The application can only use the commands that are hard-wired into it.

So quoting the final code from his article, I cannot for the life of me figure out why this:

// Declaration of Command, ChooseFileCommand, ChooseFileCommandParameters, CommandHandler,
// CommandHandlerBinding, ChooseFileCommandHandler, etc omitted!
File chosenFile = executeCommand(Command.CHOOSE_FILE, new ChooseFileCommandParameters("c:\", "*.txt"));

is supposed to be any better than, say, something like this:

//  Note no interfaces, no generics, just this one class
public class ChooseFile {
    public ChooseFile(String, String) { ...
    public File execute() { ...
}

File chosenFile = new ChooseFile("c:\", "*.txt").execute();

[Emanuele Ghe]

Ernest Friedman-Hill wrote:

Emanuele Gherardini wrote:
http://www.rbgrn.net/blog/2008/04/advanced-typesafe-command-pattern-using-java-generics.html

I've read over that article twice, now, and I can't figure out what this gets you; it's seems to me it's really just an insanely complex way to emulate non-polymorphic method calls! The strength of the Command pattern is being able to bundle up many individual Commands and put them in a queue, or hand them to a Thread pool for execution, or pass them down a chain of command. As soon as you do any of these things with the "commands" described in that article, the information about the return type disappears -- you can't have a Queue<Command> which lets you recover that return type information -- and of course, that Queue would want to call those commands polymorphically, and in doing so, it wouldn't be prepared to handle the different return types anyway.

Everything in that article is statically bound: you need to know the class name, argument types, and return type of a Command to be able to use it. That means that the code can't make any use of new Commands discovered or loaded at runtime -- another traditional strength of the Command Pattern. The application can only use the commands that are hard-wired into it.

So quoting the final code from his article, I cannot for the life of me figure out why this:

// Declaration of Command, ChooseFileCommand, ChooseFileCommandParameters, CommandHandler,
// CommandHandlerBinding, ChooseFileCommandHandler, etc omitted!
File chosenFile = executeCommand(Command.CHOOSE_FILE, new ChooseFileCommandParameters("c:\", "*.txt"));

is supposed to be any better than, say, something like this:

//  Note no interfaces, no generics, just this one class
public class ChooseFile {
    public ChooseFile(String, String) { ...
    public File execute() { ...
}

File chosenFile = new ChooseFile("c:\", "*.txt").execute();

Well, in fact what I am trying to do is to solve a problem without doing stupid "if-chaining" code, trying to use some good object oriented design to get higher quality code.

The problem is:

As "input", I have a pameter that can take, for example, at least 3 valuses, say:

A
B
C

For each "input" value, there is a logic class that handles the logic behind the "input":

public class ALogic {
      public void doLogic(AParameters args) {...}
}

public class BLogic {
      public void doLogic(BParameters args) {...}
}

public class CLogic {
      public void doLogic(CParameters args) {...}
}

Even if each "doLogic" method has parameters depending from the "Input", the operations that they do are "the same" (not strictly the same from the point of view of code, but logically the same, for example "save something":
it could be that "ALogic" saves something to a disk referred by "args", the "BLogic" saves something else to a remote storage, and the BParameters are the IP/PORT of the remote storage, etc etc).

A simple way to implement this behaviour could be:

if(input.equals("A") {
   AParameters A_args = new AParameters();
   (new ALogic()).doLogic(A_args)); 
} else if(input.equals("B") { ...}
...

I don't like this, because in my opinion this has low quality: if you want to add a 4th option, you have to add another if block etc etc.

I wanna do something modular, that dynamically loads the requested logic class based on the input, and executes it. And the code I wanna write must be easily "upgradable" without having to add an if etc etc, but only adding the "logic class" and, for example, the new Input value to an enum.

For example something like:

public enum InputValues {
	
	A("A", new ALogic()),
	B("B", new BLogic()),
	C("C", new CLogic());
	
	private String value;
	private ILogic manager;
	private InputValues(String value, ILogic manager) {
		this.value = value;
		this.manager = manager;
	}

      public ILogic getLogic() {
return this.manager;
}

//in this way the "client" just have to do: "
InputValues(input).getLogic().doLogic(); 
and this code does never have to change if adding new "values".

public interface ILogic {
	void doLogic();
}

public ALogic implements ILogic {
	public void doLogic() {
		//ALogic code
	}
}

...and so on for B and C inputs

In this way, adding a new input value is simple as adding a new value to the enum and providing the new logic class, without touching all the rest.


The problem is that, as you may have noticed the "doLogic" method here DOES NOT TAKE INPUT PARAMETERS.

What I was trying to solve is implementing this structure having "doLogic" method that takes different parameters based on the input value, continuing to hide the implementation with the interface, and that's why I used your suggestion:

public interface ILogic<T> {
   void doLogic(T arg);
}

But, in this way, I am not able to get safe-type checking at compile time when invoking the "doLogic(T arg)" from client classes, letting the client pass the wrong arguments and making a nice RuntimeExeption bubble up...And this makes the use of generic quite "useless", doesn't it ?


And that's why I am doing all this .

Can you suggest me something ?