Best way to do things

[John Tsioumpris]

Hello to everybody and Merry Christmas.
I have a simple question and i would like some opinions.
Currently i have a Java application for my diploma thesis which needs upgrading-refactoring...
What is troubling is that i have a lot of code that is scattered in various classes and does repetitive tasks throughout the application.
So i am asking what is the correct way to do it ?... i mean you need to reuse code through out your application to do simple things like print a message or add an item to a list.
Currently in the application when a task is needed to be performed usually an instance is created ..which i guess is normal and correct,
but i have also seen that classes are subclassed just to get access to their parent methods..
e.g. a class was subclassed just to get access to a methods that performs Arraylist add....(the same as Arraylist.add but because the arraylist resides inside the class it can be used as long an instance of the class is there)
Currently - mainly because my programming background is VBA - i have used the static way of an auxiliary method so that code is used throughout the application ...but i am not sure if this is the best practice.

[Winston Gutkowski]

John Tsioumpris wrote:Currently - mainly because my programming background is VBA - i have used the static way of an auxiliary method so that code is used throughout the application ...but i am not sure if this is the best practice.

On the whole I'd say probably not, but without a specific example it's difficult to say for certain.

Java is an Object-Oriented language, so it generally works best when you have objects (ie, instances) cooperating with each other. However, there are cases (for example, the java.lang.Math, java.util.Arrays and java.util.Collections classes in the Java SE), that are essentially sets of static utility methods, and it's a perfectly reasonable alternative in some cases.

It should, however, be added that Math.random() (a "catch-all" random number generator method) has since been superceded by the far superior Random class which allows you to generate RNG instances for your own use.

So, in answer to your question - and without more detail - my answer would be:
Prefer instance methods to static ones, and utility objects to static utility classes.

About the only exception I can think of is if you have a method that is wholly self-contained, and my test would go something like this:
If I can write a static method with an identical signature to an instance one, and it works just as well, then I might consider making it static; but not otherwise.

However, there are exceptions to that general rule too (there always are in programming ) - Arrays being a good case in point.

HIH

Winston

PS: Welcome to the Ranch, John; and I hope you had a good Christmas too.

[John Tsioumpris]

Well i guess some code is usefull
Here is the present situation
We have a class lets call it Foo

public class Foo
{
 ArrayList myList= new ArrayList();
 boolean displayMessage = false;

 public void add(String message)
 {
    myList.add(message);
    if(displayMessage)
    System.out.println(message);
}
}

Another class inherits from Foo

class JustAnotherClass extends Foo
  {
    ArrayList someList = new ArrayList();
    public void someMethod(String InfoNeededbysomeMethod)   //e.g path of a class
     {
      // some code here
      someList.add(InfoNeededbysomeMethod)

     }
 }

There is no connection between Foo and AnotherClass it is just inheriting in order to get the methods of Foo
Till now i have used the utility class but i am puzzled if this is a better approach

[Winston Gutkowski]

John Tsioumpris wrote:There is no connection between Foo and AnotherClass it is just inheriting in order to get the methods of Foo...

What methods? Even if it did, none of them would affect your 'someList' member, so I don't really see the point. If, on the other hand, it was defined as:

public class JustAnotherClass extends Foo {
   public void someMethod(String InfoNeededbysomeMethod) {  //e.g path of a class
      add(InfoNeededbysomeMethod)
   }
}

it would make a lot more sense. Or indeed:

public class JustAnotherClass {
   private final Foo list = new Foo();

   public void someMethod(String InfoNeededbysomeMethod) {  //e.g path of a class
      list.add(InfoNeededbysomeMethod)
   }

   ...
}

ie, using composition, rather than inheritance. However, you would then have to add "forwarders" to implement whatever part(s) of the Foo API you want, and you might want to define some sort of interface to group the two classes together.

I think we need a more concrete example to really advise you. However, if you're only using inheritance to reuse code, it's probably a bad design.
The question you should always ask yourself when extending a class is: "IS a JustAnotherClass in fact a Foo?"
If the answer is "no", then extends is almost certainly NOT what you want.

I would also suggest that you type your ArrayList (and very possibly your Foo class too). At the very least that declaration should be:
ArrayList<String> myList= new ArrayList<>();

Winston

[Winston Gutkowski]

It's possibly also worth mentioning that ArrayList is NOT final (something many people forget), so you could define Foo as:

public class Foo
   extends ArrayList<String>
{
   boolean displayMessage = false;

   @Override
   public boolean add(String message) {
      if(displayMessage)  
         System.out.println(message)
      return super.add(message);
   }

   ...
}

HIH

Winston

[John Tsioumpris]

John Tsioumpris wrote:
Another class inherits from Foo

class JustAnotherClass extends Foo
  {
    ArrayList someList = new ArrayList();
    public void someMethod(String InfoNeededbysomeMethod)   //e.g path of a class
     {
          String objectName = null;
          Object o;
      // some code here
             add(objectName +" --> "+ o.getClass().getName());

     }
 }

There is no connection between Foo and AnotherClass it is just inheriting in order to get the methods of Foo
Till now i have used the utility class but i am puzzled if this is a better approach

I am extremely sorry i put wrong "add" on the AnotherClass.....this is the correct usage of the add method of Foo Class

[Campbell Ritchie]

But that would imply that a Foo is an ArrayList.