Re: Passing Objects as Parameters

From: Sudsy (
Date: 05/09/04

Date: Sat, 08 May 2004 18:20:14 -0400

StoogeManiac wrote:
> Let me explain my position. While I agree that what you are saying is sound
> OOD principle I also am experiencing the exact opposite of what it is
> supposed to do. Let me give you an example using fictious names but the
> principle is the same. A method called GetChildren() takes a Parent object
> as a parameter and returns a collection of Children.<snip> Now
> everyone is trying to figure out what has happened.
> So rather then creating a new method that is more cohesive to what the
> developer is wanting to do they assume that their new business rule should
> be implemented within the existing method. This is what I am dealing with
> right now.

Thanks for the clarification. Having faced a comparable situation myself
(who doesn't?) I'd recommend creating a new method.
To use your example, the getChildren() method (note no arguments) should
remain as is. If someone wants to perform additional processing prior to
returning a List or Vector of results then it only makes sense to take
the selection criteria as an argument to the method. So perhaps you end
up with something like this:

    public final Collection getChildren();
    public Collection getChildren( String critereon );

The method with the argument could even invoke the no-argument method
and then perform post-processing before returning. I've also specified
the final qualifier for the no-argument method for obvious reasons. It
should give someone pause and perhaps compel them to read the
documentation before trying to extend the class.
That being said, an environment where multiple programmers have their
fingers on common core code is scary to me. The normal approach is that
it's okay to enhance a class if needs be, but you should NEVER change
the methods already written unless you're in debug or development mode.
Altering an existing method without a complete understanding of the
implications goes against all standards and is unforgivable. It's
essentially a "breach of contract" and updating the javadocs is no
As to how to deal with this scenario, take a tip from existing large-
scale development projects. Source code classes are "owned" by
individuals. Direct modifications to the source can only be performed
by the owner. Other programmers can submit patches to the code owner.
The owner can then choose whether or not to incorporate those changes.
Take a look at how some of the open-source projects work. Also check
into the various source code control systems (term used generically
here) and how they can be configured.
Finally, good luck!