Another way to program "static": Is Code ok?

Question

I need some advice about how to structure of my java applications. Personally I like to decide - like for example in python or C++ - if I program OO or not. For me, static is a way to do the same in Java.

I read, most people say static is "evil". So I thought of another option of doing the same you do with static.

What about creating a class called "StaticClasses" containing an instance of each class, which methods/attributes normally would be static.

I could create one instance of StaticClasses and set a reference to this instance in each object I create.

I could even create a new object-class mObject, which is the new parent-class of everything - directly after Object to set up these references.

And: I could make the StaticClasses class a Singleton.

Just small code examples, so you know what I mean:

// mObject.java
public class mObject{
    static StaticClasses staticCl = StaticClasses.I;
}

// StaticClasses.java
public class StaticClasses{
    public static StaticClasses I = new StaticClasses();

    // declare instance of each "static" class
    public Example0 ex0 = new Example0();       
    public Example1 ex1 = new Example1();

    private StaticClasses(){
    }
}

// Example0.java
public class Example0 extends mObject{
    public void do_something(){
        System.out.println("function call example 0");
    }
}

// Example1.java
public class Example1 extends mObject{
    public void do_something2(){
        // class "static" function
        staticCl.ex0.do_something();    
    }

    public static void main(String[] args){
        // call "static" function
        staticCl.ex1.do_something2();
    }
}

Is this a good or a really bad idea? Do you know any improvements? Do you know disadvantages of this code? Static should have slightly better performance, but shouldn't make much difference. Or should I manually set up references where I need them - even if this means more complicated code.

UPDATE:

You don't like the singleton. New Code without singleton (names are not final):

// mObject.java
public class mObject{
    Classes cl;
    public mObject(Classes c){
        cl=c;
    }
}

// Classes.java
public class Classes{
    // declare instance of each "static" class
    public Example0 ex0 = new Example0(this);       
    public Example1 ex1 = new Example1(this);
}

// Example0.java
public class Example0 extends mObject{
    public void do_something(){
        System.out.println("function call example 0");
    }
}

// Example1.java
public class Example1 extends mObject{
    public void do_something2(){
        // class "static" function
        cl.ex0.do_something();    
    }

    public static void main(String[] args){
        // call "static" function
        cl.ex1.do_something2();
    }
}

Answer 1

It's a lot of complication for zero benefit. You can make a singleton instance and throw some inheritance at it, but in the end you cannot whitewash away the fact that you're still calling a static method.

Java allows static methods as a way to let you write code that is not 100% object-oriented. For example, Math.sin(0.5) is perfectly fine; you don't want to have to write something like new Double(0.5).sin(). The advice to avoid static methods is not dogma that you need to follow — it's a general warning that you might want to consider a more object-oriented approach. Your scheme doesn't help make things any more object-oriented at all, so it's a misguided effort.

Answer 2

It is hard to answer on an academic example. Static is evil is a general rule, and as any general rule it may have exceptions. One is the singleton pattern where the singleton object is a static variable in its class accessed through a static method. Take large well known projects like Spring Framework, and you will see that they do use static.

Static is considered evil because it is often used when another object or class would be more appropriate. A common example is the students in a university. The university name is common for all students and first idea is to make it static in student class, as for other parameters for the university. And now as the program is genial you want to extend it to another university ... and all crashes because university is static in student class : you should have a university class and an object of that class (not static) in student class

Another example would the number of objects in one class. It is generally better to have a factory object that count them than a static field : what if you later want to count separately two kinds of objects ?

For your current question the best answer is in Boris the Spider's comment : You are avoiding one Java "edict" (static is evil) by creating something truly hideous.