CODEWITHSUNDEEP
java
uideveloperui
uideveloperui

Reputation: 19

Is it ok to keep common code in a separate class and make the method static in java?

I would like to know if it safe and a good practice to keep common code in a separate class and make method static.
I have a class Car, that is constructed based on inputs from other classes. I need to apply some post construct processing after the Car object is created. Example below.
Class Travel uses Car and calls postConstructProcessing method.
CarProcessor is simillary used in other classes whenever car object is creates.

My question is should I make method process Static in CarProcessor. 

Class car{

  Type type;
  Int model

Car(Type t, int m){
...
...
}

;
....
...}

Below class of code uses Car and calls postConstructProcessing method

public class Travel {
    public void go(){
       ....
       ....
      Car c = new Car(t,m);
      new CarProcessor().process(c);
    }
}

class CarProcessor{
    public Car process(Car c){
      If(c.type.value.equals("ABC"){
         c.type.version=1.1;
      }
      if(c.model=5.7){
         c.price=50k
      }
    }
}

My question is , is it safe and a good practice to make method process in CarProcessor static.

Upvotes: 0

Views: 271

Answers (1)

Bill K
Bill K

Reputation: 62789

In general it's not great.

The most obvious problem is, if you are testing the go method, how do you replace/mock out CarProcessor::process?

The real problem is organizational though. When you are coding next time and looking for the functionality you'd expect to see in "Car" or "go", you type "car." or "go." into your IDE and hit ctrl-space, you'd expect to see all the interesting methods shown to you. How do you know to create a CarProcessor to proceed?

Some things are difficult to implement in OO though--in particular utilities. Look at the entire Math package in the java library. It's full of static methods that you just call. An oo fanatic would say these all belong in the Number class (maybe something like "Number.math.sqrt()?", but java didn't take that route--in fact they don't even have a good common number class (We have one, it's not good)--

But even when we have real classes like String, we lean towards "StringUtil" and such. This has led to a HUGE number of conflicting "Util" implementations of String. In this case part of the problem is that String is immutable and we can't really back-fill it with methods (probably a good thing). but in general, OO just isn't great for general-purpose utility methods.

Functions (which is what you are proposing) are not awesome, but are heavily used. If you have the ability to modify your business classes then that's almost always a better fit for this type of code.

Just to clarify: A Function is different from a Method--methods work on members (class variables), functions are stand-alone (Might as well be static).

Functions are a very old approach at organization. OO is a somewhat newer approach invented for when the sheer number of functions become too difficult to manage (conceptually).

Upvotes: 1

Related Questions