I have a function which looks like the following:
public Status execute() {
Status status = doSomething();
if (status != Status.ABORTED) {
status = doSomethingElse();
}
if (status != Status.ABORTED) {
status = doAgainSomethingElse(param1, param2);
}
if (status != Status.ABORTED) {
doSomethingWhichDoesntReturn(param3);
}
//etc.
return status;
}
So basically this function needs to return a Status. This is computed by a first function, and then recomputed by successive functions at the condition that, when those functions are executed, status != Status.ABORTED.
I would like to refactor this code but I don't have any valid idea in my mind.
If it was always status = someFunction(someParam), I would have used a list of Function<TypeInput, Status> and executed that list in loop:
List<Function<TypeInput, Status>> actions = List.of(function1, function2...);
for (Function<TypeInput, Status> f : actions) {
if (status != Status.ABORTED) {
status = f.apply(input);
}
}
The problem though is that each action may be different (sometimes it's a function which returns Status, sometimes there are parameters but not always the same size, sometimes it's just a void function etc.)
Does anyone have any idea?
Note: as soon as the status gets Status.ABORTED, I can return (I don't need to execute the rest of the function as anything is executed only if the status is not Status.ABORTED).
This looks like a good case for a try-catch approach. You could throw an exception in either of the methods e.g. StatusAbortedException and catch that to return the appropriate Status. It could look like this
try {
Status status = doSomethingElse();
status = doAgainSomethingElse(param1, param2);
status = doSomethingWhichDoesntReturn(param3); // this one probably does smth else
return status;
} catch (StatusAbortedException e){
// return Status.Aborted
}
Expanding on dave's idea (I was thinking along the same lines) you could provide a class that represents something like a conditional chain:
//individual "chain links", i.e. elements in the chain
interface ChainLink<V> {
V execute(V v) throws Exception;
}
class ConditionalChain<V> {
private final V initialValue;
private final Predicate<V> condition;
private final Collection<ChainLink<V>> links = new LinkedList<>();
//creates the chain with the initial condition value and the condition
public ConditionalChain(V initialValue, Predicate<V> condition) {
this.initialValue = initialValue;
this.condition = condition;
}
//execute the chain
public V execute() throws Exception {
V v = initialValue;
for( ChainLink<V> link : links ) {
//apply the condition first to test the initial value
if( !condition.test(v) ) {
break;
}
v = link.execute(v);
}
return v;
}
//chain a Callable that returns a new value
public ConditionalChain<V> chain(Callable<V> c) {
links .add(v -> c.call() );
return this;
}
//chain a Runnable that doesn't change the value
ConditionalChainer<V> chain(Runnable r) {
links .add(v -> { r.run(); return v; } );
return this;
}
//helper to get the chain started
public static <T> ConditionalChain<T> start(T initialValue, Predicate<T> condition) {
return new ConditionalChain<T>(initialValue, condition);
}
}
We're using out own (internal) functional interface to allow for returning the status even when using a runnable and to support exceptions being thrown.
This could also be expanded to allow for functions that take the current status as a parameter.
The chain itself could then look like this:
Status status = ConditionalChain.start(Status.RUNNING, s -> s != Status.ABORTED )
.chain(() -> doSomething())
.chain(() -> doSomethingElse())
.chain(() -> doSomethingWhichDoesntReturn(param3))
.chain(() -> doAgainSomethingElse("param1", "param2"))
.execute();
That way you'd be able to reuse the chain with different predicates. You could even return a "chain result" that contains the status as well as the index of the last element that has been executed, e.g. if you're interested that execution stopped after doSomethingElse().
There are several options you can go for. One option is a continuation passing style.
This doesn't look all that good in Java, but you can do something similar.
// This is pseudo code, intended to illustrate the concept.
cpsMethod(Arg... args, ClosureOverFunctionSoItIsNullary continuation) {
// do stuff
continuation.call();
}
So basically, the method gets what's supposed to happen next passed into it. There are some downsides to this approach in Java, namely that you don't have tail-call optimization, so you can get a stack overflow, and perhaps more importantly, it looks very different from normal Java.
// Illustrative pseudo code
return doSomething(() -> doSomethingElse(() -> doAgainSomethingElse(param1, param2, () -> doSomethingWhichDoesntReturn())));
This removes the ifs, or rather, put the test inside every method, which now has to decide if it's going to continue, or if it's going to just return Status.ABORTED.
You could of course make this thing prettier by putting the handling outside and just take the methods as producers, give in a Predicate/hardcode the test, and just offer varargs:
private continuationPasser(Supplier<Status> first, Supplier<Status>... rest) {
Objects.requireNonNull(first);
Status status = first.get();
for(Supplier<T> continuation : methods) {
status = continuation.get();
if(status == Status.ABORTED) {
return status;
}
}
}
Dirt simple code, does exactly what you'd expect, and now your call on top will go from:
public Status execute() {
Status status = doSomething();
if (status != Status.ABORTED) {
status = doSomethingElse();
}
if (status != Status.ABORTED) {
status = doAgainSomethingElse(param1, param2);
}
if (status != Status.ABORTED) {
doSomethingWhichDoesntReturn(param3);
}
//etc.
return status;
}
To something like:
public Status execute() {
return continuationPasser(
this::doSomething,
this::doSomethingElse,
() -> doAgainSomethingElse(arg1, arg2);
() -> doSomethingWhichDoesntReturn(arg3));
Except for, you know, the last one doesn't return anything.
If it's trivial to make it return something, then you could just do that. If that's not trivial, you can just change the type from a Supplier to a Function<Status, T>, and you can pass in the last status if you want.
But that's an option. Take a functional idea and make it work. This has the benefit of being very clear if you know what continuation passing is. You could generalize the idea to take in a predicate too, if you'd like. Another way to do this would be to change the continuationPasser a bit, to make it pass in the previous result, and let the methods themselves decide what they want to do.
Then continutationPasser can look like this:
continuationPasser(Function<Status, Status> first, Function<Status, Status>... rest) {
Objects.requireNonNull(first);
Status status = first.apply(Status.SOME_REASONABLE_VALUE_LIKE_NOT_STARTED);
// You could use some reduce function here if you want to.
// The choice of a loop here is just my personal preference.
for(Function<Status, Status> fun : rest) {
status = rest.apply(status);
}
return status;
}
This makes the continuation passer even simple.
You start off by applying the first function, to get a starting value. Then you just for-each over the rest of them. And they can just start with checking for the ABORTED status and exit early. You'll still have the ifs, but your main running code will look positively neat now.
You can always wrap your methods in something like:
Function<Status, Status> runIfNotAborted(Supplier<Status> supplier) {
return (Status s) -> s == ABORTED? ABORTED : supplier.get();
}
Function<Status, Status> returnPreviousStatus(Runnable code) {
return (s) -> {
code.run();
return s;
}
}
And now you don't even have to change your methods. (But if you were to do this style that might be a better option if it was available.)
public Status execute() {
return continuationPasser(
runIfNotAborted(this::doSomething),
runIfNotAborted(this::doSomethingElse),
runIfNotAborted(() -> doAgainSomethingElse(arg1, arg2)),
runIfNotAborted(returnPreviousStatus(() -> doSomethingWhichDoesntReturn(arg3)));
And now it's quite clear what's going on. We're building functions on top of functions, in what looks a bit like a functional decorator-pattern.
This is a very general idea, and you can do this more specialized or generalize it more if you want to. But be careful or you'll write a framework to not have to write an if/else. Jenkins uses this idea for its pipelines, but has a bit more stuff in it to pass along the environment as well for example.
You could have a closure over the different function signatures, so they all have the same signature, and then iterate over your list like you wanted until the status has changed. Something like this (but using a list, I was just a little lazy since this gets the point across):
https://onlinegdb.com/4JB1flbww
interface StatusInterface {
public String fixStatus();
}
public class Main
{
public static String A(boolean x) {
if (x) {
return "fixed";
}
return "broken";
}
public static String B(boolean x, boolean y) {
if (!x && y) {
return "fixed";
}
return "broken";
}
public static void main(String[] args) {
// Lambda Expression
boolean x = false;
boolean y = true;
StatusInterface AWrapped = () ->
{
return A(x);
};
StatusInterface BWrapped = () ->
{
return B(x, y);
};
// Calling the above interface
String status = "broken";
for (int i = 0; i < 2 && status.equals("broken"); i++) {
if (i == 0) status = AWrapped.fixStatus();
else status = BWrapped.fixStatus();
}
System.out.println(status);
}
Related
For example, I have a method which returns a boolean and I'm creating a new thread there, it's hard to return the boolean in the thread.
Let me show you what I mean with this example:
public boolean test() {
int a = 5;
int b = 3;
new Thread(() -> {
if (a > b) {
return true; //NOT POSSIBLE
} else {
return false;
}
}).start();
}
This is just an example. This would not work, I'd need to do something like this:
private boolean value;
public boolean test() {
int a = 5;
int b = 3;
new Thread(() -> {
if (a > b) {
value = true;
return;
} else {
value = false;
return;
}
}).start();
return value;
}
Now my questions, is there a way which is easier than thies? This could get messy if I have more methods like this in a class.
Regards
What you want is called futures, look at some examples
https://www.baeldung.com/java-future
Or for java 8 and later CompletableFuture https://www.baeldung.com/java-completablefuture , the guide also has an example how to wait for multiple values at once.
Basically you are giving out a promise of a value and the recipient can check whether the background thread has delivered the value already and/or wait until it is done.
Your example might look something like this:
public boolean test() throws Exception {
int a = 5;
int b = 3;
CompletableFuture<Boolean> future = CompletableFuture.supplyAsync(() -> {
if (a > b) {
return true;
} else {
return false;
}
});
return future.get();
}
When you start a new thread, the current method may complete (return value) before the new thread does.
One way to catch the result is to call, from your new thread, some method of a listener instance (typically the actionPerformed of an ActionListener) which you should pass as a parameter in calling your test()-method.
The basic idea of starting a new thread is to allow some time to pass in a lengthy method while your main program does more pressing things.
I have a number of functions:
String first(){}
String second(){}
...
String default(){}
Each can return a null value, except the default. each function can take different parameters. For example, first could take no arguments, second could take in a String, third could take three arguments, etc. What I'd like to do is something like:
ObjectUtils.firstNonNull(first(), second(), ..., default());
The problem is that because of the function call, this does eager evaluation. Where'd I'd like to exit early, say after the second function (because the function calls can be expensive, think API calls, etc). In other languages, you can do something similar to this:
return first() || second() || ... || default()
In Java, I know I can do something like:
String value;
if (value = first()) == null || (value = second()) == null ...
return value;
That's not very readable IMO because of all the == null checks.ObjectUtils.firstNonNull() creates a collection first, and then iterates, which is okay as long as the function gets evaluated lazily.
Suggestions? (besides doing a bunch of ifs)
String s = Stream.<Supplier<String>>of(this::first, this::second /*, ... */)
.map(Supplier::get)
.filter(Objects::nonNull)
.findFirst()
.orElseGet(this::defaultOne);
It stops on the first non-null value or else sets the value which is returned from defaultOne. As long as you stay sequential, you are safe. Of course this requires Java 8 or later.
The reason why it stops on the first occurrence of a non-null value is due how the Stream handles each step. The map is an intermediate operation, so is filter. The findFirst on the other side is a short-circuiting terminal operation. So it continues with the next element until one matches the filter. If no element matches an empty optional is returned and so the orElseGet-supplier is called.
this::first, etc. are just method references. If they are static replace it with YourClassName::first, etc.
Here is an example if the signature of your methods would differ:
String s = Stream.<Supplier<String>>of(() -> first("takesOneArgument"),
() -> second("takes", 3, "arguments")
/*, ... */)
.map(Supplier::get)
.filter(Objects::nonNull)
.findFirst()
.orElseGet(this::defaultOne);
Note that the Supplier is only evaluated when you call get on it. That way you get your lazy evaluation behaviour. The method-parameters within your supplier-lambda-expression must be final or effectively final.
This can be done pretty cleanly with a stream of Suppliers.
Optional<String> result = Stream.<Supplier<String>> of(
() -> first(),
() -> second(),
() -> third() )
.map( x -> x.get() )
.filter( s -> s != null)
.findFirst();
The reason this works is that despite appearances, the whole execution is driven by findFirst(), which pulls an item from filter(), which lazily pulls items from map(), which calls get() to handle each pull. findFirst() will stop pulling from the stream when one item has passed the filter, so subsequent suppliers will not have get() called.
Although I personally find the declarative Stream style cleaner and more expressive, you don't have to use Stream to work with Suppliers if you don't like the style:
Optional<String> firstNonNull(List<Supplier<String>> suppliers {
for(Supplier<String> supplier : suppliers) {
String s = supplier.get();
if(s != null) {
return Optional.of(s);
}
}
return Optional.empty();
}
It should be obvious how instead of returning Optional you could equally return a String, either returning null (yuk), a default string, or throwing an exception, if you exhaust options from the list.
It isn't readable because you are dealing with a bunch of separate functions that don't express any kind of connection with each other. When you attempt to put them together, the lack of direction is apparent.
Instead try
public String getFirstValue() {
String value;
value = first();
if (value != null) return value;
value = second();
if (value != null) return value;
value = third();
if (value != null) return value;
...
return value;
}
Will it be long? Probably. But you are applying code on top of a interface that's not friendly toward your approach.
Now, if you could change the interface, you might make the interface more friendly. A possible example would be to have the steps be "ValueProvider" objects.
public interface ValueProvider {
public String getValue();
}
And then you could use it like
public String getFirstValue(List<ValueProvider> providers) {
String value;
for (ValueProvider provider : providers) {
value = provider.getValue();
if (value != null) return value;
}
return null;
}
And there are various other approaches, but they require restructuring the code to be more object-oriented. Remember, just because Java is an Object-Oriented programming language, that doesn't mean it will always be used in an Object-Oriented manner. The first()...last() method listing is very not-object oriented, because it doesn't model a List. Even though the method names are expressive, a List has methods on it which permit easy integration with tools like for loops and Iterators.
If you are using java 8 you can convert these function calls to lambdas.
public static<T> T firstNonNull(Supplier<T> defaultSupplier, Supplier<T>... funcs){
return Arrays.stream(funcs).filter(p -> p.get() != null).findFirst().orElse(defaultSupplier).get();
}
If you don't want the generic implementation and use it only for Strings go on and just replace T with String:
public static String firstNonNull(Supplier<String> defaultSupplier, Supplier<String>... funcs){
return Arrays.stream(funcs).filter(p -> p.get() != null).findFirst().orElse(defaultSupplier).get();
}
And then call it like:
firstNonNull(() -> getDefault(), () -> first(arg1, arg2), () -> second(arg3));
P.S. btw default is a reserved keyword, so you cannot use it as a method name :)
EDIT: ok, the best way to do this would be to return Optional, then you don't need to pass default supplier separetely:
#SafeVarargs
public static<T> Optional<T> firstNonNull(Supplier<T>... funcs){
return Arrays.stream(funcs).filter(p -> p.get() != null).map(s -> s.get()).findFirst();
}
If you want to package it up into a utility method, you'll have to wrap each function up into something that defers execution. Perhaps something like this:
public interface Wrapper<T> {
T call();
}
public static <T> T firstNonNull(Wrapper<T> defaultFunction, Wrapper<T>... funcs) {
T val;
for (Wrapper<T> func : funcs) {
if ((val = func.call()) != null) {
return val;
}
}
return defaultFunction.call();
}
You could use java.util.concurrent.Callable instead of defining your own Wrapper class, but then you'd have to deal with the exception that Callable.call() is declared to throw.
This can then be called with:
String value = firstNonNull(
new Wrapper<>() { #Override public String call() { return defaultFunc(); },
new Wrapper<>() { #Override public String call() { return first(); },
new Wrapper<>() { #Override public String call() { return second(); },
...
);
In Java 8, as #dorukayhan points out, you can dispense with defining your own Wrapper class and just use the Supplier interface. Also, the call can be done much more cleanly with lambdas:
String value = firstNonNull(
() -> defaultFunc(),
() -> first(),
() -> second(),
...
);
You can also (as #Oliver Charlesworth suggests) use method references as shorthand for the lambda expressions:
String value = firstNonNull(
MyClass::defaultFunc,
MyClass::first,
MyClass::second,
...
);
I'm of two minds as to which is more readable.
Alternatively, you can use one of the streaming solutions that many other answers have proposed.
Just make a class with one function like this:
class ValueCollector {
String value;
boolean v(String val) { this.value = val; return val == null; }
}
ValueCollector c = new ValueCollector();
if c.v(first()) || c.v(second()) ...
return c.value;
The above examples seemed too long for just choosing between 2 variables, I'd go with something like this (unless you've got a longer list of variables to chose from):
Optional.ofNullable(first).orElse(Optional.ofNullable(second).orElse(default));
You can accomplish this via reflection:
public Object getFirstNonNull(Object target, Method... methods) {
Object value = null;
for (Method m : methods) {
if ( (value = m.invoke(target)) != null) {
break;
}
}
return value;
}
I have something that looks like this:
public boolean isValidObject(SomeObject obj){
if(obj.getField() == null){
LOG.error("error code 1");
return false;
}
if(obj.getField().getSize() > 500){
LOG.error("error code 2");
return false;
}
......
if(someCondition()){
log something
return false;
}
return true;
}
What is the cleanest way of writing this in java 8 with lambdas?
Use polymorphism for this. Create a class for every logical validator and chain them in the list. Here is nice answer with something you need:
https://stackoverflow.com/a/23501390/1119473
public interface Validator<SomeObject>{
public Result validate(SomeObject object);
}
implementation:
public class SomeFieldSizeValidator implements Validator<SomeObject> {
#Override
public Result validate(SomeObject obj) {
// or you can return boolean true/false here if it's enough
return obj.getField().getSize() > 500 ? Result.OK : Result.FAILED;
}
}
Calling validation chain:
List<Validator> validators = ... create ArrayList of needed Validators
for (Validator v : validators) {
if (!v.validate(object)) {
... throw exception, you know validator and object here
}
I might return the error but this would still use a few if's
public String isValidObject(SomeObject obj){
if (obj.getField() == null) return "error code 1";
if (obj.getField().getSize() > 500) return "error code 2";
......
if (someCondition()) return "something";
return OK;
}
This way you could unit test this method to see if it return the error you expect for different invalid objects.
I want to get rid of 50 if/else statements.
If you have 50 conditions and they all value different results you will need to do 50 checks. You could change the structure like this.
static final Map<Predicate<SomeObject>, String> checks = new LinkedHashMap<>();
static {
checks.put((Predicate<SomeObject>) o -> o.getField() == null, "error code 1");
checks.put((Predicate<SomeObject>) o -> o.getField().getSize() > 500, "error code 2");
}
public String isValidObject(SomeObject obj) {
for (Predicate<SomeObject> test : checks.keySet())
if (test.test(object))
return checks.get(test);
return OK;
}
However, personally this is not clearer and would be harder to debug e.g. breakpoint.
Use java.util.function.Predicate interface:
Predicate<SomeObject> p1 = (SomeObject so ) -> so.getField()!=null;
Predicate<SomeObject> p2 = (SomeObject so ) -> so.getField().getSize() > 500;
...
SomeObject someObject = new SomeObject();
Predicate<SomeObject> fullPredicate = p1.and(p2).and( ...
boolean result = fullPredicate.test(someObject);
Except this will give you 50 Predicate one-line definitions, they'll just be a bit more compact.
I recommend a solution that uses a different approach: consider using Validator objects. Meaning: instead of putting all your checks into the same method, you put each check in its own class!
You define some Validator interface that provides a validate method. When validation fails, that method is supposed to throw some ValidationException (and that exception could contain an error code + message).
And then you create many small classes, each one implementing that interface.
Final step: you create a list in which you put one object of each impl class. And now your code boils down to iterating that list, and applying each impl after the other.
This decouples your validation steps, and adding new/other checks becomes super easy.
If you specifically wish to use lambdas, they mesh nicely with an enum:
public enum SomeValidators {
E1 (1, o -> o.getField() == null),
E2 (2, o -> o.getField().getSize() > 500)
;
final int code;
final Predicate<SomeObject> predicate;
SomeValidators(int code, int predicate) {
this.code = code;
this.predicate = predicate;
}
}
You can then use it to replicate your if-else if flow as follows:
boolean isValidObject(SomeObject o) {
Optional<SomeValidators> firstError =
Arrays.stream(SomeValidators.values())
.filter(v -> v.predicate.apply(o))
.findFirst();
firstError.ifPresent(e -> LOG.error("error code " + e.code));
return firstError.isPresent();
}
I'm not sure how lambdas can be useful here.
If you are using lot of 'if else' to handle lot of business rules then one option is to try some rule engines. One easy and best option is EasyRules
Easy rules are handy and easy to implement. This will make your business logic code look very clean.
Is it possible to wrap following code in a reusable function?
EDIT: this is just an example, I want a working solution for ALL recursion depths
what I want is that following code is generated:
if (MyObject o == null ||
o.getSubObject() == null ||
o..getSubObject().getSubSubObject() == null /*||
... */)
return defaultValue;
return o.getSubObject().getSubObject()/*...*/.getDesiredValue();
by calling something like
Object defaultValue = null;
Object result = NullSafeCall(o.getSubObject().getSubObject()/*...*/.getDesiredValue(), defaultValue);
The seond code block is just an idea, I don't care how it looks like, all I want is that I, if desired, can avoid all the null checks before calling a deeper function...
Injection could do this propably, but is there no other/easier solution? Never looked at injection before yet...
EDIT2: example in another language: http://groovy.codehaus.org/Operators#Operators-SafeNavigationOperator
Not really, any code you would write this way would look horrible and/or use very slow reflection. Unless you use an actual Java preprocessor that can understand and change the code you've written.
A better (but associated with quite a bit of refactoring) approach would be to make sure that the values in question cannot possibly be null. For example, you could modify the individual accessors (getSubObject(), getDesiredValue()) to never return null in the first place: make them return default values. The accessors on the default values return default values in turn.
Java8 helps to get the closest you'll get to your syntax with decent performance I suspect;
// Evaluate with default 5 if anything returns null.
int result = Optional.eval(5, o, x->x.getSubObject(), x->x.getDesiredValue());
This can be done with this utility class;
class Optional {
public static <T, Tdef, T1> Tdef eval(Tdef def, T input, Function<T,T1> fn1,
Function<T1, Tdef> fn2)
{
if(input == null) return def;
T1 res1 = fn1.apply(input);
if(res1 == null) return def;
return fn2.apply(res1);
}
}
Sadly, you'll need a separate eval() defined per number of method calls in the chain, so you may want to define a few, but compile time type safe and reusable with just about any calls/types.
You can do something like this
public static Object NullSafeCall(MyObject o,Object defaultValue){
if ( o == null || o.getSubObject() == null)
{
return defaultValue;
}
else
{
return o.getSubObject().getDesiredValue();
}
}
Now you can call this method as follows
Object result = NullSafeCall(o, defaultValue);
i would suggest just replace
Object result = NullSafeCall(o.getSubObject().getDesiredValue(), defaultValue);
by the
Object result = (o == null || o.subObject == null) ? defaultVlue : o.getSubObject().getDesiredValue();
Create method only if you can reuse it......
What you want is not possible. It is essential to understand that using this syntax: Object result = NullSafeCall(o.getSubObject().getSubObject() ...); the part of o.getSubObject().getSubObject() will be evaluated before any control passes to the function/method thus throwing the exception.
It is required to have some type of context before executing such code. The closest to this I could think of, can be done using anonymous inner classes like the example below:
// intended to be implemented by an anonymous inner class
interface NullSafeOperation<T> {
public T executeSafely();
};
// our executor that executes operations safely
public static class NullSafeExecutor<T> {
public NullSafeExecutor() {}
public T execute(T defaultValue, NullSafeOperation<T> nso) {
T result = defaultValue;
try {
result = nso.executeSafely();
} catch(NullPointerException e) {
// ignore
}
return result;
}
// utility method to create a new instance and execute in one step
public static <T> T executeOperation(T defaultValue, NullSafeOperation<T> nso) {
NullSafeExecutor<T> e = new NullSafeExecutor<T>();
T result = e.execute(defaultValue, nso);
return result;
}
}
public static void main(String[] args) {
final String aNullString = null;
String result = NullSafeExecutor.executeOperation("MyDefault", new NullSafeOperation<String>() {
#Override
public String executeSafely() {
// trying to call a method on a null string
// it will throw NullPointerException but it will be catched by the executor
return aNullString.trim();
}
});
System.out.println("Output = " + result); // prints: Output = MyDefault
}
I'm writing a method along these lines:
if (hasFoo()) {
return calculateFoo();
} else if (hasBar()) {
return calculateBar();
} else {
return calculateBaz();
}
The getters are rather expensive and the has...() checks would either duplicate a lot of the logic or just have to reuse the getters. I could have the has...() methods store the result of the get...() in a field and make the getter lazy, but it would be nice for has...() not to have any side effects. I could write this with nested try{} catch{} blocks, but that doesn't look elegant. seems like there should be a better solution to this...
EDIT: changed get...() to calculate...() to make it clear that they're expensive.
int result = 0;
if (hasFoo()) {
result = getFoo();
} else if (hasBar()) {
result = getBar();
} else {
result = getBaz();
}
return result;
is the idiom I prefer to use - makes it far easier to inspect variable values while debugging.
I see nothing wrong in doing
Object fooBarBaz = null;
if (hasFoo()) {
foo = getFoo();
} else if (hasBar()) {
fooBarBaz = getBar();
} else {
fooBarBaz = getBaz();
}
return fooBarBaz;
I prefer it this way:
if (hasFoo()) {
return calculateFoo();
}
if (hasBar()) {
return calculateBar();
}
return calculateBaz();
All a matter of taste and convention.
I am not sure if this is your case, but I would try to fully refactor the code. Currently, as far as I understand, your code looks something like this (example):
boolean hasFoo() {
DataObject do = getSomeDataSource().getSomeDataObject();
if (do.getF() != null && do.getO() != null) {
return true;
} else {
return false;
}
}
Foo getFoo() {
DataObject do = getSomeDataSource().getSomeDataObject();
Foo result = new Foo(do.getF(), do.getO());
return result;
}
Basically what happens here is that the same code is used to check if Foo can be returned and to construct the Foo itself too. And I would refactor it to this:
/**
* #returns instance of Foo or null if Foo is not found
*/
Foo getFoo() {
DataObject do = getSomeDataSource().getSomeDataObject();
F f = do.getF();
if (f == null) {
return null; //Foo can not be created
}
O o = do.getO();
if (o == null) {
return null; //Foo can not be created
}
return new Foo(f,o);
}
Now your original code would become similar to this:
Result r;
r = getFoo();
if (r == null) {
r = getBoo();
}
if (r == null) {
r = getDoo();
}
return r;
This is not an "is it OK to do multiple returns" problem - your multiple returns are fine.
This is a refactoring and/or state storage problem.
If you have:
bool hasXXX() {
// do lots of stuff
...
return has_xxx;
}
and
double calculateXXX() {
// do the same lots of stuff
...
// do some more stuff
...
return xxx;
}
then the complexity of the problem depends on whether the hasXXX() calculation produces lots of intermediate values that are necessary for calculateXXX().
You likely need something like:
bool checked_xxx = false;
double xxx_state;
bool hasXXX() {
// do expensive stuff
...
// save temporary state variables
xxx_state = ...
// remember that we've been here
checked_xxx = true;
// send back the required value
return has_xxx;
}
double calculateXXX() {
// make sure that hasXXX was called, and is valid
if (!checked_xxx && !hasXXX()) {
// should never happen - you called calculateXXX when hasXXX() == false
throw new RuntimeException("precondition failed");
}
// use the previously calculated temporary state variables
...
// send back the final result
return xxx;
}
EDIT: If I'm interpreting your comments correctly, it sounds like you actually want something like:
Result result = calculateFoo();
if (result != null) {
return result;
}
result = calculateBar();
if (result != null) {
return result;
}
return calculateBaz();
... where each of the calculate methods returns null if the corresponding has method returns false. Now if null is a valid "real" return value, you could always wrap the result so that calculateFoo returns a value which can basically say, "Yes, I've got a valid value and it's X" or "no, I haven't got a valid value" (a "maybe" type).
Original answer
I would keep your code exactly as it is. I see no problems with having multiple return statements when that's the clearest approach - and in this case I believe it is.
You're making it clear that once you've reached each of the "leaf" parts, you know exactly what the return value is, and the only other code which should be executed before leaving the method is any clean-up code in finally blocks.
Having a single exit point makes sense in languages which don't have try/finally or GC (where you really want to make sure you do all the cleanup in a single place) but in Java, I think returning when you know the result states your intention more clearly than using a separate local variable.
Having said that, another alternative to consider is using the conditional operator, laying out your code so it's obviously going through a series of tests and returning as soon as it finds the first "match":
return hasFoo() ? getFoo()
: hasBar() ? getBar()
: getBaz();
The disadvantage is that this pattern looks a little odd the first time you see it - but once you get used to it, I find it a really neat way of encoding this sort of logic.
Instead of doing hasXXX() and calculateXXX() you could factor those calculations out to separate objects eg
public interface CalculationModel {
Object calculate();
}
public class FooCalculationModel implements CalculationModel {
#Override
public Object calculate() {
// Perform Foo calculations
return result;
}
}
and your if-statement can then be replaced with:
return getCalculationModel().calculate();
You will need some way of deciding the CalculationModel of course, but this would then replace the hasFoo(), hasBar() etc methods.
you could do something like this :
Object bar;
if ((bar = getFoo()) != null) {
return bar;
} else if ((bar = getBoo()) != null) {
return bar;
} else {
return getBaz()
}
this way you only need to call the get methods, but not the has ones
EDIT
this is the same in a more readable format that also elminates the need to call the has methods
Object bar = getFoo()
if (bar == null) {
bar = getBoo()
}
if (bar == null) {
bar = getBaz()
}
return bar;