Java`final`类和嘲弄

Question

I'm developing a programming game where players will have access to an abstract class and extend it to control the behaviour of a robot. Because it is a programming game, I am trying to protect my game infrastructure so that players don't mess with the game instead of just the class that I give them; for this I make most of my classes final but now I can't mock them in my unit tests (mockito + testNG).

So I was wondering, how can I work around this? is there a way to maybe leave the classes non-final for testing and then somehow automatically ' final -ize' them at a later stage of the build cycle (i'm using maven in case it's relevant for the answer). I don't want to add another external library or change my mocking library.
If it's not possible, then a second question: is making a class final really secure? i saw some libraries that could remove the final classifier from bytecode, which makes me think that maybe then final is useless if it can be removed from an already compiled class

Answer 1

First, you can't prevent people from messing with your game by declaring things 'final'. There are reflection tricks and whole code generation libraries that make it merely slightly inconvenient to get past this.

So, lose the finals, and then you can use jmock or whatever library you like to make mocks.

Answer 2

You can eventually try to apply automated refactoring tools, like Jackpot 3 or RefactoringNG . I never tested them but they are more than capable to do what you want if going the way of refactoring.

Another way would be to use Powermock which allows to mock finals and statics (even tough I'm not fond of mocking statics, as it suggests something is wrong in your design).

Answer 3

You always can use delegation instead of inheritance.

public interface Foo {
    // ...
}

public final class FooImpl implements Foo {
    // ...
}

public class MockFooImpl implements Foo {
    private FooImpl delegate;
    // ...
}

However, it is bad idea to have abstract classes in your API. Interface will be better.

Answer 4

IMO, classes are marked final to make their objects immutable. If you want to control the behavior of a class, you mark the methods in the class as private so that they cannot be overridden. If you leave them protected, then someone can extend your class, override these protected methods and pass an instance of the extended class to your APIs that expect your class object as paramter, thereby inducing the modified behavior. So, you would mark methods that you don't want to expose as private.

You leave only extension points in terms of protected/public methods which can be overridden for custom behavior, by the clients that use these classes.

Answer 5

Making most classes final is good practice, since they are usually not designed for extension by subclassing. All books on API design that I know of recommend doing so ("Effective Java", "Practical API Design", "API Design for C++"). This is beneficial for several reasons, including the expression of the API designer's intent, the safe evolution of the API, and the prevention of dead code (for example, a good IDE will detect when a final method doesn't use one of its parameters, or never throws a checked exception listed in the throws clause - which would not be possible for a non-final method).

As for mocking said classes, you just need to use a proper mocking tool such as JMockit (which I developed precisely because I wanted to write unit tests without sacrificing certain OO/API design practices).