Develop Reference

Return enum value or use boolean getters

I have a question that might be a matter of pure taste, however I just like to get some opinions from different angles to become more clear about this.
A class reads and writes status values from and into a database. There are currently 5 status values, they might become a few more. For brevity, I only use 3 status values in the example. Also, though this is Java code, the concept can be transferred to other languages as well.
class Status {
private enum Value { FAILED, FINISHED, RUNNING }
// getters (read from db)
// ...
// setters (write into db)
// ...
}
I can't decide whether I should use generic getters and setters like
Value get()
void set(Value value)
or if I should create specific getters and setters with more semantics like
boolean isRunning()
boolean hasFailed()
boolean hasFinished() // could also be named isFinished()...
void setFailed()
void setFinished()
void setRunning()
The component is not performance-critical, still the obvious drawback of the semantic getters is that you need multiple database reads for if-else if statements and switch cannot be used. On the other hand, it hides the internal details of the implementation from the consumer and there is no need to work with the enum values outside this class:
if (status.get() == Status.Value.RUNNING) { ... }
vs.
if (status.isRunning()) { ... }
Any comments are appreciated.

If clients have to write multiple times comparisons such as :
if (status.get() == Status.Value.RUNNING) { ... }
You provide probably a too much fine grained API for the enum field containing in the Status class.
It will force each client to have duplicate code or otherwise create their own util methods such as boolean isRunning(Status status){return status.get() == Status.Value.RUNNING}.
It is not a good idea for two reasons :
the boiler plate code has to be in the internal/implementation of the API, not in the client side.
a method has to be located in the class that suits best to hold it. In this case, this is Status. Don't constraint clients classes to take the responsibility of this method.
Note that you should not provide both : Value getter/setter + specific methods for them. It could be misleading.

I agree with Mena that this is opinion based, I would prefer using isRunning, hasFailed etc.
Because names give more meaning and is much shorter and more understandable.
As you wrote:
if (status.get() == Status.Value.RUNNING) { ... }
if (status.isRunning()) { ... }
The second option is much shorter and gives better overall sense of what is happening, but again this is more of personal thing.
Also you could consider having more functional approach, something similar to Optional, for example ifFailed(Consumer<Throwable>).

Java 7 changed the behavior of Collections.checkedCollection to allow nulls. Is it still worthwhile for an API to use this in a mixed environment?

First of all, here's the behavior added by Java 7's Collections.checked*:
Since null is considered to be a value of any reference type, the returned collection permits insertion of null elements whenever the backing collection does.
This doesn't appear to be listed in the compatibility documentation, though. Demo:
public class MyAPI {
private Set<Polygon> polygons = new Collections.checkedSet(new HashSet<Polygon>(), Polygon.class);
public Set<Polygon> getPolygons() {
return polygons;
}
}
public class MyAPITest {
// This JUnit test passes when using Java 6 or earlier, but fails for Java 7.
#Test(expected=NullPointerException.class)
public void testAddNullPolygon() {
new MyAPI().getPolygons().add(null);
}
}
So as you can see I'm writing an API that exposes a Set for client code to populate. From what I've read, this is one of the use cases for Collections.checkedCollection etc: the added runtime check helps prevent weird stuff from getting inserted.
I've changed my API to handle nulls regardless, but my concern is that the client code could sometimes throw the NPE, sometimes not, depending on what version of Java the end user was running. That just feels broken. Ideally I'd like to preserve the old behavior, preventing nulls at insertion time.
I guess my options are:
Give up on runtime checking entirely.
Not worry about it, and trust client code to never insert nulls.
Declare that my API only supports JRE 7.
Use Guava, which looks great but is an extra dependency my API would be saddled with.
Roll my own Set wrapper that enforces null and type checking.
Some other more elegant solution that I'm missing.
Any guidance would be much appreciated!

The option that I ultimately went with is to get rid of the checkedCollection, making the exposed collection unmodifiable. Users of the API need to call one of the extra add/remove/clear methods to modify the collection.
This limits API users somewhat: they can't, for example, use addAll to copy all elements of another collection in a single method call. But it's a fair tradeoff for simplicity and type safety.
public class MyAPI {
private Set<Polygon> polygons = new HashSet<Polygon>();
private Set<Polygon> polygonsReadonlyView = Collections.unmodifiableSet(polygons);
public Set<Polygon> getPolygons() {
return polygonsReadonlyView;
}
public boolean addPolygon(Polygon p) {
if (p == null) {
throw new IllegalArgumentException("polygon cannot be null");
}
return polygons.add(p);
}
public boolean removePolygon(Polygon p) {
return polygons.remove(p);
}
public void clearPolygons() {
polygons.clear();
}
}
One takeaway from all this is to never rely on a checkedCollection to prevent nulls from being inserted.
A Google search might suggest this... but don't do it! Null-checking is not one of checkedCollection's use cases.

Protect access to Java methods depending on custom conditions

In short: I want to allow/forbid the execution of Java methods depending on certain conditions. What is the best available solution/mechanism/technique?
Long question, via an (admittedly dumb) example:
Say I have several methods in a vehicle controller, like void openWindow(Window w), void openRoof(), void keepSpeed(double speedKmh). If it rains, the openRoof should not be called, and we want to put in place a mechanism to ensure it. Similarly, if the speed is below 60 km/h, keepSpeed is forbidden, like openWindow if it rains a lot or if the speed if above 100 km/h.
Since accessing the rain/speed sensors requires several lines of code, and these conditions are used everywhere, I don't want to use use assertions or conditions in the body of the methods, but I'd rather make them easily used by domain developers. Besides, I'd like the security concern to be separated from the actual logic of opening the windows, etc. More complex, custom conditions should be easy to configure too.
For instance, I'd like to have this:
#ForbidIf('default:rain') openWindow();
#ForbidIf('default:speedBelow(60)') keepSpeed();
#ForbidIf('default:speedAbove(100)', 'custom:rainsALot') openWindow();
If it helps, this application is a Spring-powered client-server application.

You can use a simple Spring AOP aspect, something like this (untested):
#Aspect
public class SecurityAspect{
#Pointcut("execution(#ForbidIf * *(*))")
public void annotatedMethodCalled(){}
#Before("annotatedMethodCalled() && #target(annotation) && target(bean)")
public void beforeRestrictedMethodCall(
final ForbidIf annotation, final Object bean){
final Expression expression =
new SpelExpressionParser().parseExpression(annotation.value());
if(!Boolean.TRUE.equals(expression.getValue(bean))){
throw new IllegalArgumentException();
}
}
}

Something similar is implemented in Spring Security as expression based access control, but I think it's not suitable in your case.
However, it should be easy to implement similar functionality from scratch by creating an aspect that can evaluate SpEL expressions against a certain context.

OP, commenting to Andreas_D's answer: "If the execution is forbidden, I want a runtime exception to be raised. In this case, if the condition is false, it means this method should have never been called under the current circumstances."
What's wrong with:
public void openWindow() {
if (itsRaining()) {
throw new IllegalStateException("Window should not open if it's raining");
}
}
? I mean, doing an annotation is effectively the same thing, only more complex (especially if your conditions for the method grow in complexity, for example if the window should not be opened if it's raining, snowing, vehicle speed > 100 KPh, wind speed > 6, temperature below freezing, etc).
Of course, I could also just be missing the point. Just wanted to give the hint that overthinking, -engineering or -complicating the problem aren't the only paths to take. Don't want to say that using AOP or annotations are overthinking/engineering/complication a problem, of course. Probably basing this post on the simplified example, too.

This is an interesting idea, although I see some real problems. You may annotate a method and refer to some environment settings. But if execution is forbidden, what should be done instead?
Consider this example:
#ForbidIf('default:durationIs(0))') double getSpeed(double distance);
and use it like
double speed = getSpeed(distance); // the duration is set globally in this example
What should happen if the duration value is set to 0 - what should be assigned to speed in that case? Or do you want to raise a runtime exception?
In your case, we already have two ways to implement conditional execution:
// check before calling
if (isSaveToOpenWindow())
openWindow();
and
public void openWindow() {
if (!isSaveToOpenWindow())
return;
// open window
}

Do you need AOP here? the Decorator pattern can be a lot simpler and requires a lot less magic. Just wrap the implementation with:
class ProtectedWindowOpener implements WindowOpener {
WindowOpener delegate ...
void openWindow(Window w) {
if (!allowOpen(w)) {
throw new PermissionDeniedException...
}
delegate.openWindow(w);
}
boolean allowOpen(Window w) {
// security logic here
}
}
Which keeps the security logic separate and also has the advantage of not embedding code in a string, which means eclipse can do its business.

How can I simplify testing of side-effect free methods in Java?

Functions (side-effect free ones) are such a fundamental building block, but I don't know of a satisfying way of testing them in Java.
I'm looking for pointers to tricks that make testing them easier. Here's an example of what I want:
public void setUp() {
myObj = new MyObject(...);
}
// This is sooo 2009 and not what I want to write:
public void testThatSomeInputGivesExpectedOutput () {
assertEquals(expectedOutput, myObj.myFunction(someInput);
assertEquals(expectedOtherOutput, myObj.myFunction(someOtherInput);
// I don't want to repeat/write the following checks to see
// that myFunction is behaving functionally.
assertEquals(expectedOutput, myObj.myFunction(someInput);
assertEquals(expectedOtherOutput, myObj.myFunction(someOtherInput);
}
// The following two tests are more in spirit of what I'd like
// to write, but they don't test that myFunction is functional:
public void testThatSomeInputGivesExpectedOutput () {
assertEquals(expectedOutput, myObj.myFunction(someInput);
}
public void testThatSomeOtherInputGivesExpectedOutput () {
assertEquals(expectedOtherOutput, myObj.myFunction(someOtherInput);
}
I'm looking for some annotation I can put on the test(s), MyObject or myFunction to make the test framework automatically repeat invocations to myFunction in all possible permutations for the given input/output combinations I've given, or some subset of the possible permutations in order to prove that the function is functional.
For example, above the (only) two possible permutations are:
myObj = new MyObject();
myObj.myFunction(someInput);
myObj.myFunction(someOtherInput);
and:
myObj = new MyObject();
myObj.myFunction(someOtherInput);
myObj.myFunction(someInput);
I should be able to only provide the input/output pairs (someInput, expectedOutput), and (someOtherInput, someOtherOutput), and the framework should do the rest.
I haven't used QuickCheck, but it seems like a non-solution. It is documented as a generator. I'm not looking for a way to generate inputs to my function, but rather a framework that lets me declaratively specify what part of my object is side-effect free and invoke my input/output specification using some permutation based on that declaration.
Update: I'm not looking to verify that nothing changes in the object, a memoizing function is a typical use-case for this kind of testing, and a memoizer actually changes its internal state. However, the output given some input always stays the same.

If you are trying to test that the functions are side-effect free, then calling with random arguments isn't really going to cut it. The same applies for a random sequence of calls with known arguments. Or pseudo-random, with random or fixed seeds. There's a good chance are that a (harmful) side-effect will only occur with any of the sequence of calls that your randomizer selects.
There is also a chance that the side-effects won't actually be visible in the outputs of any of the calls that you are making ... no matter what the inputs are. They side-effects could be on some other related objects that you didn't think to examine.
If you want to test this kind of thing, you really need to implement a "white-box" test where you look at the code and try and figure out what might cause (unwanted) side-effects and create test cases based on that knowledge. But I think that a better approach is careful manual code inspection, or using an automated static code analyser ... if you can find one that would do the job for you.
OTOH, if you already know that the functions are side-effect free, implementing randomized tests "just in case" is a bit of a waste of time, IMO.

I'm not quite sure I understand what you are asking, but it seems like Junit Theories (http://junit.sourceforge.net/doc/ReleaseNotes4.4.html#theories) could be an answer.

In this example, you could create a Map of key/value pairs (input/output) and call the method under test several times with values picked from the map. This will not prove, that the method is functional, but will increase the probability - which might be sufficient.
Here's a quick example of such an additional probably-functional test:
#Test public probablyFunctionalTestForMethodX() {
Map<Object, Object> inputOutputMap = initMap(); // this loads the input/output values
for (int i = 0; i < maxIterations; i++) {
Map.Entry test = pickAtRandom(inputOutputMap); // this picks a map enty randomly
assertEquals(test.getValue(), myObj.myFunction(test.getKey());
}
}
Problems with a higher complexity could be solved based on the Command pattern: You could wrap the test methods in command objects, add the command object to a list, shuffle the list and execute the commands (= the embedded tests) according to that list.

It sounds like you're attempting to test that invoking a particular method on a class doesn't modify any of its fields. This is a somewhat odd test case, but it's entirely possible to write a clear test for it. For other "side effects", like invoking other external methods, it's a bit harder. You could replace local references with test stubs and verify that they weren't invoked, but you still won't catch static method calls this way. Still, it's trivial to verify by inspection that you're not doing anything like that in your code, and sometimes that has to be good enough.
Here's one way to test that there are no side effects in a call:
public void test_MyFunction_hasNoSideEffects() {
MyClass systemUnderTest = makeMyClass();
MyClass copyOfOriginalState = systemUnderTest.clone();
systemUnderTest.myFunction();
assertEquals(systemUnderTest, copyOfOriginalState); //Test equals() method elsewhere
}
It's somewhat unusual to try to prove that a method is truly side effect free. Unit tests generally attempt to prove that a method behaves correctly and according to contract, but they're not meant to replace examining the code. It's generally a pretty easy exercise to check whether a method has any possible side effects. If your method never sets a field's value and never calls any non-functional methods, then it's functional.
Testing this at runtime is tricky. What might be more useful would be some sort of static analysis. Perhaps you could create a #Functional annotation, then write a program that would examine the classes of your program for such methods and check that they only invoke other #Functional methods and never assign to fields.
Randomly googling around, I found somebody's master's thesis on exactly this topic. Perhaps he has working code available.
Still, I will repeat that it is my advice that you focus your attention elsewhere. While you CAN mostly prove that a method has no side effects at all, it may be better in many cases to quickly verify this by visual inspection and focus the remainder of your time on other, more basic tests.

have a look at http://fitnesse.org/: it is used often for Acceptance Test but I found it is a easy way to run the same tests against huge amount of data

In junit you can write your own test runner. This code is not tested (I'm not sure if methods which get arguments will be recognized as test methods, maybe some more runner setup is needed?):
public class MyRunner extends BlockJUnit4ClassRunner {
#Override
protected Statement methodInvoker(final FrameworkMethod method, final Object test) {
return new Statement() {
#Override
public void evaluate() throws Throwable {
Iterable<Object[]> permutations = getPermutations();
for (Object[] permutation : permutations) {
method.invokeExplosively(test, permutation[0], permutation[1]);
}
}
};
}
}
It should be only a matter of providing getPermutations() implementation. For example it can take data from some List<Object[]> field annotated with some custom annotation and produce all the permutations.

I think the term you're missing is "Parametrized Tests". However it seems to be more tedious in jUnit that in the .Net flavor. In NUnit, the following test executes 6 times with all combinations.
[Test]
public void MyTest(
[Values(1,2,3)] int x,
[Values("A","B")] string s)
{
...
}
For Java, your options seem to be:
JUnit supports this with version 4. However it's a lot of code (it seems, jUnit is adamant about test methods not taking parameters). This is the least invasive.
DDSteps, a jUnit plugin. See this video that takes values from appropriately named excel spreadsheet. You also need to write a mapper/fixture class that maps values from the spreadsheet into members of the fixture class, that are then used to invoke the SUT.
Finally, you have Fit/Fitnesse. It's as good as DDSteps, except for the fact that the input data is in HTML/Wiki form. You can paste from an excel sheet into Fitnesse and it formats it correctly at the push of a button. You need to write a fixture class here too.

Im afraid that I dont find the link anymore, but Junit 4 has some help functions to generate testdata. Its like:
public void testData() {
data = {2, 3, 4};
data = {3,4,5 };
...
return data;
}
Junit will then thest your methods will this data. But as I said, I cant' find the link anymore (forgot the keywords) for a detailed (and correct) example.

Refactoring advice and tools

I have some code that consists of a lot (several hundreds of LOC) of uggly conditionals i.e.
SomeClass someClass = null;
if("foo".equals(fooBar)) {
// do something possibly involving more if-else statments
// and possibly modify the someClass variable among others...
} else if("bar".equals(fooBar)) {
// Same as above but with some slight variations
} else if("baz".equals(fooBar)) {
// and yet again as above
}
//... lots of more else ifs
} else {
// and if nothing matches it is probably an error...
// so there is some error handling here
}
// Some code that acts on someClass
GenerateOutput(someClass);
Now I had the idea of refactoring this kind of code something along the lines of:
abstract class CheckPerform<S,T,Q> {
private CheckPerform<T> next;
CheckPerform(CheckPerform<T> next) {
this.next = next;
}
protected abstract T perform(S arg);
protected abstract boolean check(Q toCheck);
public T checkPerform(S arg, Q toCheck) {
if(check(toCheck)) {
return perform(arg);
}
// Check if this CheckPerform is the last in the chain...
return next == null ? null : next.checkPerform();
}
}
And for each if statment generate a subclass of CheckPerform e.g.
class CheckPerformFoo extends CheckPerform<SomeInput, SomeClass, String> {
CheckPerformFoo(CheckPerform<SomeInput, SomeClass, String> next) {
super(next);
}
protected boolean check(String toCheck) {
// same check as in the if-statment with "foo" above"
returs "foo".equals(toCheck);
}
protected SomeClass perform(SomeInput arg) {
// Perform same actions (as in the "foo" if-statment)
// and return a SomeClass instance (that is in the
// same state as in the "foo" if-statment)
}
}
I could then inject the diffrent CheckPerforms into eachother so that the same order of checks are made and the corresponding actions taken. And in the original class I would only need to inject one CheckPerform object. Is this a valid approach to this type of problem? The number of classes in my project is likely to explode, but atleast I will get more modular and testable code. Should I do this some other way?
Since these if-else-if-...-else-if-else statments are what I would call a recurring theme of the code base I would like to do this refactoring as automagically as possible. So what tools could I use to automate this?
a) Some customizable refactoring feature hidden somewhere in an IDE that I have missed (either in Eclipse or IDEA preferably)
b) Some external tool that can parse Java code and give me fine grained control of transformations
c) Should I hack it myself using Scala?
d) Should I manually go over each class and do the refactoring using the features I am familiar with in my IDE?
Ideally the output of the refactoring should also include some basic test code template that I can run (preferably also test cases for the original code that can be run on both new and old as a kind of regression test... but that I leave for later).
Thanks for any input and suggestions!

What you have described is the Chain of Responsibility Pattern and this sounds like it could be a good choice for your refactor. There could be some downsides to this.
Readability Because you are going to be injecting the the order of the CheckPerformers using spring or some such, this means that it is difficult to see what the code will actually do at first clance.
Maintainence If someone after you wants to add a new condition, as well as adding a whole new class they also have to edit some spring config. Choosing the correct place to add there new CheckPerformer could be difficult and error prone.
Many Classes Depending on how many conditions you have and how much repeated code within those conditions you could end up with a lot of new classes. Even though the long list of if else its very pretty, the logic it in one place, which again aids readability.

To answer the more general part of your question, I don't know of any tools for automatic refactoring beyond basic IDE support, but if you want to know what to look for to refactor have a look at the Refactoring catalog. The specific of your question are covered by replace conditional with Polymorphism and replace conditional with Visitor.

To me the easiest approach would involve a Map<String, Action>, i.e. mapping various strings to specific actions to perform. This way the lookup would be simpler and more performant than the manual comparison in your CheckPerform* classes, getting rid of much duplicated code.
The actions can be implemented similar to your design, as subclasses of a common interface, but it may be easier and more compact to use an enum with overridden method(s). You may see an example of this in an earlier answer of mine.
Unfortunately I don't know of any automatic refactoring which could help you much in this. Earlier when I did somewhat similar refactorings, I wrote unit tests and did the refactoring step-by-step, manually, using automated support at the level of Move Method et al. Of course since the unit tests were pretty similar to each other in their structure, I could reuse part of the code there.
Update
#Sebastien pointed out in his comment, that I missed the possible sub-ifs within the bigger if blocks. One can indeed use a hierarchy of maps to resolve this. However, if the hierarchy starts to be really complex with a lot of duplicated functionality, a further improvement might be to implement a DSL, to move the whole mapping out of code into a config file or DB. In its simplest form it might look something like
foo -> com.foo.bar.SomeClass.someMethod
biz -> com.foo.bar.SomeOtherClass.someOtherMethod
baz -> com.foo.bar.YetAnotherClass.someMethod
bar -> com.foo.bar.SomeOtherClass.someMethod
biz -> com.foo.bar.DifferentClass.aMethod
baz -> com.foo.bar.AndAnotherClass.anotherMethod
where the indented lines configure the sub-conditions for each bigger case.