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

[Alec Lee]

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]

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]

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]

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]

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]

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]

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]

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]

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:

public void testConstructor()
{
   String[] args = new String[] { "-o+", "-alAntEater", "12", "-t-" };
   Parms parms = new Parms( args );
   assertEquals( "Alive",  12L,        parms.alive );
   assertEquals( "Animal", "AntEater", parms.animal );
   assertEquals( "One",    true,       parms.one );
   assertEquals( "Two",    false,      parms.two );
}

and ...

class Parms extends CmdLineArgs
{
   public long alive;
   public String  animal = "animal";
   public boolean one    = false;
   public boolean two    = true;
   public List    some   = new ArrayList();
 
   public Parms( String[] args )
   {
      super( args );
      parse( );
   }
 
   public void preParse()
   {
      add( new Positional( "First positional", "alive" ) );
      add( new Switch( "Some strings", "some", "s" ) );
      add( new Switch( "What kind of animal", "animal", "al" ) );
      add( new Switch( "Is it one?", "one", "o" ) );
      add( new Switch( "Is it two?", "two", "t" ) );
      add( new Rule( "alive must be more than 10" )
      {
         public void validate()
         { assertTrue( alive > 10 ); }
      } );
      add( new Rule( "one must not equal two" )
      {
         public void validate()
         { assertTrue( one != two ); }
      } );
   }
}