Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Programming Style - How to Return A Set of Objects to Caller  RSS feed

 
Alec Lee
Ranch Hand
Posts: 569
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I know the return type of a method could return a single primitive/object type to caller. What about if I have a set of Objects+ primitives to return?

I dont think Map is a good return type here if the objects are of different types. Also we can't do a C style pointer argument and have the callee modified the data directly. Using array as an argument isn't a good strategy neither.

It seems that we have to define a class just for the purpose of returning values from a method. Is there a simplier way to do this?
 
Rusty Shackleford
Ranch Hand
Posts: 490
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For what you need a custom class will be required or you might be able to wrap the primitives into their wrapper classes, and store them all in a ArrayList or whatever as Objects. Not sure if the last is workable and if it is, it is probably bad design.

IMO, returning all those different types in a single method is bad design. A method should really only do one task. Returning each type would be seperate tasks.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, if a method returns more than one thing, that either means that,

- those things really belong very close together and therefore *should* be encapsulated in a class, or

- as Rusty indicated, your method is doing too much, and therefore you would likely benefit from rethinking your design.

Can you give a concrete example where you are encountering this problem that we could discuss?
 
Alec Lee
Ranch Hand
Posts: 569
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ilja,

An example, I have a method to verify the command line arguments passed to the main(String[] args) - parse the array and transform them to the required data types. So the method is doing one thing but need to return different data types.
 
Ramen Chatterjee
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Alec

Perhaps you could describe what the client is asking for. The point being, why should a client want disparate information all one call? In the example you give, if it is reasonalbe for the client to have all this data, why not pass the args String[] and let the client do the conversion?

Describe your problem in more general terms and it may help find the correct solution. Alternatively post some code, so we can see what you are trying to do.

Regards

Ramen
 
Eitan Levi
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ironically enough, I came to this forum right now with the same question, and found this older thread. I was hoping that maybe there was some quick tip/trick that I wasn't aware of. I think this is one of cases where the statically typed object oriented paradigm reaches its limits. It would be convenient to simple return a tuple, as in Perl, Python or other high-level scripting languages.

Unfortunately you can't get away with that. You could return an array of type Object, but then you'd have to go through a messy process of casting the individual elements and you'd have to make sure that everything's in the right order.

Your safest bet, and what some people in the other thread called "the right way", is to just create a class that holds your values, and get*() methods to access them. That approach perfectly adheres to OOP, and you can easily extend it later by adding more fields to the class, which is somewhat cleaner than appending an element to an Object[] and adding another cast -- at least with your own class you can be type-safe and not worry about ClassCastExceptions.
 
Eitan Levi
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Since you're trying to parse command line arguments, you should take a look at this article by Robert C. Martin: http://www.objectmentor.com/resources/articles/Clean_Code_Args.pdf

He describes a command line parser in Java and a number of the design decisions he made while writing it, the reasons behind them, and walks you through the refactoring to get there.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Eitan Levi:
Your safest bet, and what some people in the other thread called "the right way", is to just create a class that holds your values, and get*() methods to access them. That approach perfectly adheres to OOP, and you can easily extend it later by adding more fields to the class, which is somewhat cleaner than appending an element to an Object[] and adding another cast -- at least with your own class you can be type-safe and not worry about ClassCastExceptions.


I don't agree that it's the safest bet and perfectly adheres to OOP. It very much depends on the context.

Introducing a Method Object from which you can ask the values one by one instead of in one big chunk simply is more appropriate for some situations.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
See that code sample for building a command line parser. The "command line arguments" are a reasonable abstraction, ie a decent class to have around.

I made my own parser for something to do. I made an object that represents the command line syntax and a parser that populates it from a command line. The syntax object can spew out help. Just as a hint here's a sample from the unit tests:

and ...
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!