wood burning stoves 2.0*
The moose likes Java in General and the fly likes How to handle return types semantically correct and still adhere to OO design princip Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "How to handle return types semantically correct and still adhere to OO design princip" Watch "How to handle return types semantically correct and still adhere to OO design princip" New topic
Author

How to handle return types semantically correct and still adhere to OO design princip

Chris Jones
Greenhorn

Joined: Feb 18, 2008
Posts: 12
Although I have strived to be succinct in my question, I know the following has become a little long and already thank you for your patience reading it. The questions are not so much about how to implement a particular use case, but rather how to adhere to good OO design principles when it comes to return types and use of exceptions.

I understand the OO principles etc, but are somewhat new to the pragmatic requirements of real-world programming and sometimes find it hard to comply with all design principles.

Like for instance in the example below where the method's returntype only makes sense if the method completes successfully: here i have a 2D Object array, and it only makes sense to return the index if there is a match between the string passed in and one of the [n][0] elements in the matrix (

I have TWO related questions:

QUESTION ONE:
What shall i do with regards to return type? Ideally I should not require the client methods to know of any implementation details, like know that if they get -1 back it means that there wasn't a mach. That is; even require the client to check for the -1 occurence that otherwise would never be normal range when asking for an index of an array.

The way I have solved it here is to have the method throw an exception in case of no match. I am using an exception here as a - well, no so exceptional - branch of the control flow. Basically using it to flag that the outcome of the method was different than the integer, and thus forcing the caller to take appropriate action (prompt the user for a different key or something). Is that good?


QUESTION TWO: In case the way of using exceptions here is ok, I can run into some semantic problems when I try and use it in different contexts:

Use Case A: get item out of the matrix based on a key.
- Here the innate semantic of complementaryIndex makes sense: it returns the matching index to a certain String key, throws an exception if no match is found.

Use Case B: insert item into the matrix.
- this usecase controller could reuse the code in complementaryIndex to check that the key isn't already in the Matrix. Here the semantics break down: complementaryIndex is called for its side effect, namely the NoSuchFieldException to see if its okay to insert my element in the matrix based on the key. In other words, the essential code implementing usecase B is actually placed within a catch block like this:

void insertItem(String key, Object item) {
try { complimentaryIndex(key); // called for its side effect, the NoSuchFieldException
} catch (NoSuchFieldException nsfe) {
// code to insert the item at the end of the array
}
}

Placing the main succes scenario for the use case within a catch block looks a bit like we are handling an error, rather than solving the main use case scenario. So although I avoid duplicating code by reusing the complementaryIndex() method, It is not semantically very clear in its second use. How should I solve this and code it in a meaningful and sensible way?
Nitesh Kant
Bartender

Joined: Feb 25, 2007
Posts: 1638

chris: I should not require the client methods to know of any implementation details, like know that if they get -1 back it means that there wasn't a match. That is; even require the client to check for the -1 occurence that otherwise would never be normal range when asking for an index of an array.

I would say returning -1 is not a part of implementation details but a part of the contract of the method. You may choose to throw an exception or return -1 based on what you think is more appropriate but I feel that there is nothing wrong in doing either. You just have to make that clear in the documentation of the method.

chris: Here the semantics break down: complementaryIndex is called for its side effect, namely the NoSuchFieldException to see if its okay to insert my element in the matrix based on the key.

This is something that i feel is not correct definetly. So, there must be a separate method in your class like containsKey() that returns a boolean. One can check for the key existance using this method. Throwing an exception here does not do justice to the caller.

If you do not want to return -1 from your public method, then you can do the following:
  • Write the main logic in a private method that returns -1 if the key is not present.
  • In your public method, throw an exception when the private method returns -1.
  • Write another method containsKey() that returns a false if the private method returns -1.


  • I saw this question in the comments in your code,
    chris:/*
    the following statement is NEVER reached, although the compiler don't notice as the actual
    return/exception is packed within the conditional statement above. Why can't the compiler see this?
    */


    Return/exception packed within the conditional statement will not be executed if the length of the array underlyingMatrix is 0. So, the compiler needs to make sure that the method return something in that case.


    apigee, a better way to API!
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Note that your for loop is *never* executed more than once - for the very first iteration, it will either return, or throw an exception. This is probably not what you want...


    The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
    Chris Jones
    Greenhorn

    Joined: Feb 18, 2008
    Posts: 12
    Nitesh Kant, thank you so much for taking the time to consider the questions. It was great to have someone's opinion on those issues. Thanks for commenting!
    Chris Jones
    Greenhorn

    Joined: Feb 18, 2008
    Posts: 12
    Nitesh: really good advice in fact!

    Ilja: I'll look into your point.

    Thanks again to both of you
     
    It is sorta covered in the JavaRanch Style Guide.
     
    subject: How to handle return types semantically correct and still adhere to OO design princip
     
    Similar Threads
    June Newsletter Puzzle
    Sun Cirtification
    using [] operator with an array
    Null pointer Exception