设计模式，无需重新编译/重新链接即可覆盖方法

Question

We are building a product that needs to run on production environments. We need to modify some of the functionality of a existing library. The existing library has class's and methods, we need to override 1 or more methods so that the caller uses our overriden methods instead of the original library.

OriginalLibrary

package com.original.library ;
public class OriginalLibrary {
    public int getValue() {
        return 1 ;
    }
    public int getAnotherValue() {
        return 1 ;
    }
}

Original Client

public class MyClient {
    private OriginalLibraryClass originalLibraryObject ;
    public MyClient () {
        originalLibraryObject = new OriginalLibraryClass() ;
        System.out.println(originalLibraryObject.getValue()) ;
        System.out.println(originalLibraryObject.getAnotherValue()) ;
    }
}

Output

1

2

Now, I need to change getValue() to return 3 , instead of 1

Needed Output

3

2

package com.original.library.improved ;
    public class OriginalLibrary extends com.original.library.OriginalLibrary {
        public int getValue() {
            return 3 ;
        }
        public int getAnotherValue() {
            return super.getAnotherValue() ;
        }
}

If I do the above, I need to tell my Original Client to reorder and use my new com.original.library.improved jar file before com.original.library .

I am almost convinced that this is the most non intrusive way to launch my improved services over and above the OriginalLibrary . I would have preferred a solution where I need to tell the customer to just add my jar file, no need to recompile, relink your client code.

Similar (not same) questions on a google search here here

Answer 1

java assist is excellent library for bytecode manipulation. I have modified code below as per your sample code given, You have to explore javaassist more for your actual requirenment

CtClass etype = ClassPool.getDefault().get("com.original.library.OriginalLibrary");
// get method from class
CtMethod cm = etype.getDeclaredMethod("getValue");
// change the method bosy
cm.setBody("return 3;");
etype.rebuildClassFile();
// give the path where classes is placed, In my eclipse it is bin
etype.writeFile("bin");


OriginalLibrary originalLibraryObject;
originalLibraryObject = new OriginalLibrary();
System.out.println(originalLibraryObject.getValue());
System.out.println(originalLibraryObject.getAnotherValue());

Now output of getValue is 3 because I changed body of that method.

Answer 2

A couple of questions -

• How is the client getting an instance of your library's class?
  If they are using new OriginalLibrary() , then you're pretty much stuck with creating a new subclass of OriginalLibrary and then asking your client to use your new OriginalLibraryImproved class. This is a common problem encountered in projects and is one reason why a library should not allow its clients to instantiate its classes directly using the new operator.
  If instead, your client is instantiating OriginalLibrary using a factory method provided by the library (say, OriginalLibrary.getInstance() ), you may want to check if there are any hooks into the factory that allow you to change the object being returned.

• Do you have full control of the source code of the original library?
  If yes, then you definitely should (and I cannot emphasize this strongly enough) provide factory methods for any class in the library that is instantiable. Doing this allows you to change the actual object being returned without modifying the client (as long as the returned object's class is a subclass of the return value from the factory method).
  If not, then I suggest you do the following.

  • Create a subclass of OriginalLibrary (say, OriginalLibraryImproved ).
  • Create a Factory class named OriginalLibraryFactory that has a static method named getInstance() . Write code to return an instance of OriginalLibraryImproved from this method.
  • Ask your client to replace all occurrences of new OriginalLibrary() with OriginalLibraryFactory.getInstance() . Note that this approach will only involve adding an extra import for the factory class. The client will still refer to the returned instance using the same OriginalLibrary reference as before.

The advantage of this approach is that it gives you complete flexibility to change the implementation details of OriginalLibraryImproved without affecting the client in anyway. You could also swap OriginalLibararyImproved with a newer version like OriginalLibraryImprovedVer2 and the client will be oblivious to the fact that it is using a new class. You'll just have to make sure that OriginalLibraryImprovedVer2 subclasses OriginalLibrary .

An even more flexible approach is to use the Wrapper or Decorator pattern to avoid the pitfalls of inheritance. You can understand more about the Decorator pattern here .

In a nutshell, try to avoid forcing your clients to use new and try to avoid inheritance unless you have very compelling reasons.