This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I think the return object is better than a collection of values as the meaning is in the code. With the collection approach, you have to know what the order is and enforce it manually. The return object approach is clear, more readable and gives gyou compile time safety.
i would say it depends..... On a number of factors. But most importantly, does the resulting object mean anything?
If you already have an object which has the two values, then it is fine.
Always remember, you are affecting readability by such a method. Side effects should be a biproduct, not the sole product as much as possible. The methods with sideeffects should exist for the sole purpose and should exist because thats how it is. I am sure most of the designs can be refactored to accomodate individual returns. But there are some places where objects are required as the others have shown.
Where to do what.
Ask yourself what seems to be the natural answer. Not the simpler, natural answer. Ask yourself what should this method return if i just read it aloud.
assume your method name is getPoint(). Then it may return an integer or a Point class object. If your method reads set or adjust point. It may have reference variables.
This being said, you can find a lot of books OOAD which advocate the use of returns instead of side effect based reference variables. There are a few people who feel otherwise. Both have their advantages.
I personally believe most of the times, you can refactor your code to suit the no side effect rule. However, this might not be the case always.
This being said, if the method is returning a value, make sure it is not having too many side effects. The thumb rule says method objectives should be atomic. So if it is doing 1 thing, it should ideally not be doing another thing unless it is required and cannot be avoided.
It's really the only programming practice. After all, you can only return one thing from a method. If you need to return 'two things' or 'two variables' as you say, they need to be returned as an object. Whether that object is created in the method, or passed into the method, it all depends. There is nothing wrong with a method that takes no arguments but returns an object.