views:

72

answers:

5

Hi, I have a lot of classes which are basically equivalent, ie have almost the same functions in all respect. Let's call them A and B. There are hundreds of methods that are using A and now due to code changes I have to change them to B.

Is there a way by which I can program a mapping between A and B such that I have minimal code changes?

+1  A: 

Well, you should probably use inheritance in this case.

If you make B a subclass of A, you can use B wherever you had been using A without changing any of the code.

Sun/Oracle has some great tutorials on inheritance that you may want to take a look at in order to get started.

jjnguy
+2  A: 

You should define an interface that both A and B implement.

Frank
+1. First make A implement (let's call it) I. Now make every caller take, instead of an A, an I. Your program behavior is unchanged at this point. Now, as needed, you can make B implement I and pass B's in, testing as you go. This is cleaner than the subclass options others have suggested.
Carl Manaster
+2  A: 

If A is not final, you can make B extends A, and have B's methods @Override A's. Then wherever previously you were invoking methods on an instanceof A, you now provide an instanceof B, and let dynamic dispatch handle the rest.

This is called polymorphism. It only works with non-static methods having the same exact signature. You can not @Override static methods.

See also

Related questions


On interfaces

Depending on why you were doing this, you should know learn the concept of interfaces and how they're used in object-oriented programming to allow precisely this kinds of flexibility and convenience.

Consider the interface List<E>, for example, and an implementation ArrayList<E>. If you wrote an entire library that works with an ArrayList<E>, doing all the usual add/addAll/remove etc, and now you must use a LinkedList<E> instead, then you'd have little choice but to go to the source code and change all the ArrayList<E> to LinkedList<E>, and hope that the change doesn't break another code which still assumed that ArrayList<E> was used.

If instead your library works with a List<E>, then switching to a LinkedList<E> need to be done only wherever the objects are created. All the other code that was doing the add/addAll/remove would've still worked just fine, since those are methods that are defined in the interface List<E> which all implementors will have.

It's not clear from the current context, but if A and B are so similar, then perhaps they belong to some type X. If so, you should consider defining interface X, and have A implements X, and B implements X.

See also

Related questions

polygenelubricants
+1  A: 

You can make A an adapter for B. I.e.

class A {
   private B b = new B();

   public String someMethod() {
      return b.equivalentSomeMethod();
   }
}

That's in case the methods are similar, and not exactly the same. If they are exactly the same - use your IDE to get rid of one of the classes and replace it with the other.

Bozho
Is there any reason this would be preferred over setting up some inheritance relationship?
jjnguy
yes - I added a comment about that. In case the methods differ in some ways (which was my initial impression)
Bozho
+1  A: 

There are many ways, each with advantages and disadvantages. A couple ideas:

Make B a subtype of A. Then you can pass instances of B to methods requiring A. Alternatively, extract a common interface, and replace uses of A with that interface where possible (a good IDE can do this automatically).

In A, include the following constructor:

A(B b) {
    // create an A with the data from b
}

or create an Adapter that subclasses A and delegates all calls to B.

In any case, if minimizing tedium in changing the code is your objective, look into your IDE's refactoring operations.

meriton
+1 for naming *both* solutions, both have their uses and we can't recommend one without more details.
delnan