-1

To make a long story short, I have a toolbox with different tools. I want to implement a class for each tool and the class must implement a common interface creatively called "Tool". Since each tool is simply a set of methods, there is no reason to create an instance of the tool and therefore I would like the methods to be static. However since these methods are abstract, they cannot be made static.

I would like to be able to do this:

RectangleTool.getCursor();
EllipseTool.getCursor();

(EllipseTool and RectangleTool being class names)

I feel this is a legitimate use for an abstract static method. However, I realize it is not possible in Java.

Am I not seeing this properly? I realize I could instantiate a single object of each but I don't like the semantics of it.

Convince me there is a better way to see this.

ReX357
  • 1,199
  • 3
  • 19
  • 43
  • Workaround for [almost] all static methods: Dependency Injection. – user2864740 Mar 23 '15 at 05:04
  • possible duplicate of [Java abstract static Workaround](http://stackoverflow.com/questions/1916019/java-abstract-static-workaround) – DonyorM Mar 23 '15 at 05:04
  • These possible duplicate comments are so annoying. I get it, there's a workaround in a different thread. I was trying to argue for my current situation as to why the next version of Java should allow abstract static methods. I guess my title is misleading. – ReX357 Mar 23 '15 at 05:14
  • 1
    @ReX357 If you want to make an argument for such a feature in a future version of Java, write a blog, hop on the Java Mailing Lists, or go post on a debate-friendly bulletin board, eg. If you want a viable solution to this 'problem' in Java - as it is today - then take heed of the 'duplicate comments'. – user2864740 Mar 23 '15 at 05:14
  • @user2864740 Alright, fair enough. Thanks. – ReX357 Mar 23 '15 at 05:17

2 Answers2

1

Your abstract static method would serve no purpose. Since static methods need to be called directly on the class that defines them, there is no layer of indirection that would be served by them being abstract in a base class.

In essence, since you have already identified that you need to call eg. RectangleTool.getCursor() or EllipseTool.getCursor(), the existence of a Tool.getCursor() makes no difference, as no part of the code can refer directly to it anyway.

It would be a different thing, of course, if Java supported polymorphism for static methods, but it doesn't.

Dolda2000
  • 25,216
  • 4
  • 51
  • 92
1

I would suggest that it may be better design to give up on wanting static methods here.
Using static methods on your tools isn't going to be possible without using reflection to call them. But, beyond that restricting yourself in this way might remove the future possibility of writing parameterised tools, or of reusing code between tools. I don't know the full scope of your situation, but imagine something like this:

Tool pentagonTool = ShapeTools.regularPolygonWithEdges(5);
Tool triangleTool = ShapeTools.regularPolygonWithEdges(3);

I would suggest that you get rid of your requirement for static methods, and for the tool implementations where it is only methods, make those implementations singletons.

Tool tool1 = RectangleTool.INSTANCE.getCursor();
List<Tool> toolbox = ImmutableList.of(
    RectangleTool.INSTANCE,
    EllipseTool.INSTANCE,
    SquareTool.INSTANCE,
    CircleTool.INSTANCE
);
Nicholas Daley-Okoye
  • 2,267
  • 1
  • 18
  • 12
  • Thank you. This is exactly where I went to after accepting the answer. Gonna use singletons. Your example at the top is not gonna be useful for me since I have a ngonTool. The rectangle tool is for convenience since it is a common thing to create rectangles of different dimensions. The ngon tool only creates equilateral polygons. But I see where you were going with it. – ReX357 Mar 23 '15 at 05:31