Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
Say I have a method like so:
public boolean extract(String string)
{
// return true if string can be extracted, false otherwise
}
And a caller
if (!StringUtils.isBlank(myString))
{
boolean isExtracted = extract(myString);
}
// do something else
Does it make more sense to move checking the string is empty or null inside the method? What is the best practice here?
One of the most useful principles in object oriented programming is the Tell-don’t-Ask principle.
In short it remembers us to tell an object what to do and let the object itself do the validation, instead of asking an object it’s state and have the caller do the validation. The caller shouldn’t have knowledge on the inner workings of the method it calls.
So in your example, the null-check should be handled inside the method, but then the ‘extract’ method itself also seems to violate the Tell-don’t-Ask principle. The method is probably called before another operation on the same object, if so, the extract method can be made private and called from the method that really does the work.
In case the extract method is the method that does the work, it violates the CQS principle, by returning a bool. That principle is really useful too, because we can get a quick idea of what a method does by looking at it’s signature. If it returns something, it’s a query, otherwise a command. The name of your extract method sounds like a command, but the signature looks like a query.
extract). We want our abstractions to be useful as well as simple to use.// do something else?extractdo when presented with a blank string? Does it have generally undesirable behaviour (e.g. crash or null pointer exception) or does the function handle it properly but with a result that is not useful for this particular call site?