Is this how to re-use code in OOP?

Question

I have a class with a method that generates random data to fill arrays with. The class had the data member private final Random rnd that is initialized in the constructor with new Random();. This is used in the method for generating data for arrays.

For example

package test;

import java.util.Random;

public class WorkWithArrays {

    WorkWithArrays(Object[] arr) {
        rand = new Random();
        fillArrays(arr);
    }

    /*fills arrays with random data;
      since this method is called from constructor
      must be declared final*/
    public final void fillArrays(Object[] arr) {
        //code goes here
    }

    /*some other methods and data members*/

     final private Random rand;
}

I am writing a new class which I also need to fill arrays with random values. Is there a way I could not have to rewrite the same method? I could extend the class or I could make the method static. Since I only need fillArrays() making it static seems like the better option over extending.

So let's make it static.

public static final void fillArrays(Object[] arr) {
   //code goes here
}

Now fillArrays() uses rand which is a problem because rand isn't static. So why not make it static? Now in WorkWithArrays we no longer initialize rand in the constructor but have it final static private Random rand = new Random(); as a data member. Is this right? It seems like bad practice to initialize things outside of the constructor.

Now I can do

package test;

MyNewClass {
    someMethod() {
        int[] x = new int[25];
        WorkWithArrays.fillArrays(x);
    }
}

Answer 1

It is not bad practice; as Warren pointed out there is a static initializer construct that is used for just this.

For instance, to make a class with utility-like methods ('functions' that don't really require state), there are a couple of things you can do.

Make the class itself final

This prevents extensions of the class, which wouldn't make sense.

public final class WorkWithArrays {
  // ...
}

Make the constructor private

This prevents the class from being initialized

private WorkWithArrays() {}

Create a static randomizer

You could create/initialize it by itself (which isn't bad practice at all!)

private static final Random rand = new Random();

or with the aforementioned static initializer

private static Random rand;
static {
  rand = new Random();
}

Note that final can only be used with static properties if it is initialized in-line.

Make your random array fill method static

As easy as

public static void fillArrays(Object[] arr) {
  // code goes here
}

---

This is one way of achieving a design pattern known as a singleton class, and is actually very common throughout OOP languages.

In Java, instead of creating a getInstance()-type method, instances are commonly stored locally (or no instance is created at all, such as is the case here) and the static methods refer to the internally stored instance.

Initialization logic goes in the static { } initializer block, which is executed when the Java classloader first loads the class.

Note that, in your example (at the time of writing), you had the final keyword on a static method. This is not necessary, and is often caught by static analyzers as invalid/pointless.

---

I'm not one to usually write out code for the OP, but the following is a perfectly fine approach to structure your class¹.

public final class WorkWithArrays {
  private static final Random RAND; // = new Random();
  static {
    WorkWithArrays.RAND = new Random();
  }

  private WorkWithArrays() {}

  public static void fillArrays(Object[] array) {
    for (int i = 0, len = array.length; i < len; i++) {
      array[i] = WorkWithArrays.RAND.nextInt();
    }
  }
}

¹Imports have been omitted

Answer 2

Static variables are often initialized outside the constructor. In fact, in Java, there's the concept of a "static initializer", which is specifically designed to initialize static variables outside of any constructor, if the initialization is too complex for a simple assignment.

Answer 3

The more you use static, the further you drift away from object orientation. Static is not subject to polymorphisim, and rarely does using a state promote data hiding (as all the instances tend to cross-communicate when going through static variables).

In addition, many (not all) details of arrays are at odds with object oriented programming too, as arrays are holders of data without the possibility of combining code and data. As a result, arrays lack behavior and delegate the responsibility of data correctness to other non-related pieces of code.

For an object oriented solution:

public class RandomIntList {
   private int[] values;

   public RandomIntList(int size) {
      values = new int[size];
      Random random = new Random();
      for (int i = 0; i < size; i++) {
        values[i] = random.nextInt();
      }
   }

}

Note that now you can cleanly identify which objects are RandomIntLists and which are not, which is not really possible with int[]s.

Of course, if you add something like

public int[] asArray() {
   return values;
}

You let the cat out of the bag, because other code could modify the internal state of the class without going through the class's boundary (aka interface or methods). So to keep your classes object oriented, you sometimes need to copy (when the data can be mutated).

public int[] asArray() {
    return Arrays.copyOf(values, values.size);
}