File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

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

 
Chris Jones
Greenhorn
Posts: 12
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1638
IntelliJ IDE Java MySQL Database
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
     
    Ilja Preuss
    author
    Sheriff
    Posts: 14112
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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...
     
    Chris Jones
    Greenhorn
    Posts: 12
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Posts: 12
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Nitesh: really good advice in fact!

    Ilja: I'll look into your point.

    Thanks again to both of you
     
    I agree. Here's the link: http://aspose.com/file-tools
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic