About a static superclass and overridden static methods

[Mads]

Normally, I like how interfaces work and all, but sometimes I want to use them without making an instance, because its not necessary. Would it be possible to override a static method, but call the method using the superclass?

Like, could I make an object that takes a class as a parameter, only to make a static call on that class (which then might be subclassed/overridden).

This would just be to avoid creating instances when it's not necessary.

I can elaborate on the idea, if necessary.

Cheers guys.

[Riven]

Static methods cannot be overridden.

[Mads]

Static methods cannot be overridden.

Oh well. I'll use an instance.

Games published by our own members! Check 'em out!

[Roquen]

What do you really what to do?

[Mads]

I have a few methods that might as well be static, but theyre overridden. I thought it would be easier to reference the class and use the static method, instead of having a ton of the same objects.

[Roquen]

If you have a solution then ignore me..but I'm still not understanding what you're saying.  By "might as well be static" you must mean that it doesn't need a access state data of an instance, but beyond that I'm lost.  Can you give a concrete example?

[jonjava]

You should only ever override methods if you want to add/change something to/in them. To me it looks like you're overriding methods because you want to use them in other objects?

If you want to access the methods from other objects you should either 1) make the class that has them static 2) make the methods static 3) give a reference of that object to the objects that need to use the methods.

#1 and #2 are for lazy people (me). (Try to make as little static classes as  possible).


#3 is true clean good OOP design. I.e:

1   2   3

UtilityObj util = new UtilityObject(); LittleObject lilObj = new LittleObject( util ); // pass the lilObj a reference to your utility object so that it can access the "util" objects public method

E.g:

1   2   3   4   5

// LittleObject's constructor public lilObj( UtilityObject ob ) {    this.ob = ob; // save the reference for use in other methods of this class.   myName = ob.getRandomName(); }

There's also another option #4 where you create a non-static class (because you want to avoid creating static classes) but you give the class a static method for accessing the objects reference. (My description is bad, search google for "Singleton" for more detail).

#4 e.g:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16

public class MySingleton {    private MySingleton mySelf = null;    private MySingleton() {       // Make constructor private =      //    nobody else can create a new MySingleton but itself   }    public static MySingleton get() {       if (mySelf == null) {          mySelf = new MySingleton();       }       return mySelf; // So that other classes can get a reference to this object   } }

[davedes]

Why are you using static in the first place? It sounds like you should be using instance methods.

[Abuse]

It's probably not worth going into the finer points of static method hiding, as it's almost certainly not what you want to be do. (there are situations it's useful, but they're extremely specialized)

As others have suggested, it's much easier to give a 'right' answer if we know precisely what it is you are trying to achieve.
Show us a code example.

[Mads]

First of all, thanks for reading and answering everyone!  For that I am grateful.

You should only ever override methods if you want to add/change something to/in them. To me it looks like you're overriding methods because you want to use them in other objects?

I am aware how to override things, and when it should be done. I also know what design patterns I could apply to make it work like intended. What I tried was something very specific, but it would only work if I could override methods I could access in a static context. I can't do that, though.

Why are you using static in the first place? It sounds like you should be using instance methods.

I could, but that's not what I wanted to do.

I think there is a miscommunication somewhere. I might have explained myself poorly. It doesn't matter though, because I've solved my problem in a different manner. Enough rambling

Please avoid replying to this thread anymore. I've found out what I wanted, and I don't think it would be beneficial to keep this debate going. I could explain exactly what I wanted to do, but that would take too long, and I doubt there will be any input of usable substance - at least for me.