Passing Objects as Parameters

[StoogeManiac]

I have been brought into a large application written in Java. The
application utilizes an MVC architecture, which is slightly modified but
still maintains the basic MVC structure.

I'm running into a lot of instances where the developers have passed object
references rather then parameters into methods. For example a method call to
get the Father of a user might pass in the reference to the Child object
rather then just the child's name, which is the only value needed.

Their reasoning behind this is simple, if the implementation needs to change
such as having to look at child name and another piece of information to get
the father then they do not have to modify the message signature. This
allows the application level code to remain untouched.

I have concerns about this since these are shared components/methods between
multiple applications and a desired change in implementation in one
application may not be the same in another.

I would like to see what others think of this practice.

Thanks.

 

[Roedy Green]

I'm running into a lot of instances where the developers have passed object
references rather then parameters into methods. For example a method call to
get the Father of a user might pass in the reference to the Child object
rather then just the child's name, which is the only value needed.

Look at the name of the method. Does it imply any other possible set
of parameters than the very specific ones handed through?

If so, I'd say pass the object. Then the method can take what it
needs, without pestering all the clients about what is essentially a
very local change if that method later needs to be changed.

On the other extreme, if the method were say trimming embedded blanks
from a string, then that method has no business being passed anything
other the string it fiddles with.

This is not what is meant by "information hiding" in the art of
writing unmaintainable code. See http://mindprod.com/unmainnaming.html

I think you have to look at each case.

 

[Ryan Stewart]

I have been brought into a large application written in Java. The
application utilizes an MVC architecture, which is slightly modified but
still maintains the basic MVC structure.

I'm running into a lot of instances where the developers have passed object
references rather then parameters into methods. For example a method call to
get the Father of a user might pass in the reference to the Child object
rather then just the child's name, which is the only value needed.

Their reasoning behind this is simple, if the implementation needs to change
such as having to look at child name and another piece of information to get
the father then they do not have to modify the message signature. This
allows the application level code to remain untouched.

I have concerns about this since these are shared components/methods between
multiple applications and a desired change in implementation in one
application may not be the same in another.

I would like to see what others think of this practice.

Thanks.

My first thought is why isn't getFather() a method of Child?

 

[Ken Ream]

| I have been brought into a large application written in Java. The
| application utilizes an MVC architecture, which is slightly modified but
| still maintains the basic MVC structure.
|
| I'm running into a lot of instances where the developers have passed
object
| references rather then parameters into methods. For example a method call
to
| get the Father of a user might pass in the reference to the Child object
| rather then just the child's name, which is the only value needed.
|
| Their reasoning behind this is simple, if the implementation needs to
change
| such as having to look at child name and another piece of information to
get
| the father then they do not have to modify the message signature. This
| allows the application level code to remain untouched.
|
| I have concerns about this since these are shared components/methods
between
| multiple applications and a desired change in implementation in one
| application may not be the same in another.
|
| I would like to see what others think of this practice.
|
| Thanks.

So you're worried that if the implementation is changed for one application
it may break another application that uses the component?

I think your worrying is backwards. Central to OOP is the concept of
encapsulation. The idea is that an object has an interface that is a
contract for interacting with other objects. In other words an object has
public methods that take some parameter (object references are parameters
too, btw) and return something (or not). Applications that call these
methods should never need to know what happens in the implementation of that
method. If they do something is very wrong with the design. You should be
free to change the implementation of that method anyway your heart desires
as long as when you call it passing parameters of the correct type, you get
returned something of the correct type.

Now on the other hand, say you define that method to return a Father object
to take a String that is the name of the Child and you have a 100
applications that use that method. What happens when someone decides you
must now include the child's SSN to get the correct Father? If you had
defined the method to take a Child object as a parameter you have one place
to fix the code. If you had defined the method to take the name String you
have 101 places to fix code (assuming you can be absolutely sure where all
the uses of that method are.

Please tell me you haven't been brought in as an "architect" or some sort of
"senior programmer". It will help me sleep at night.

 

[Jim]

I have been brought into a large application written in Java. The
application utilizes an MVC architecture, which is slightly modified but
still maintains the basic MVC structure.

I'm running into a lot of instances where the developers have passed object
references rather then parameters into methods. For example a method call to
get the Father of a user might pass in the reference to the Child object
rather then just the child's name, which is the only value needed.

Their reasoning behind this is simple, if the implementation needs to change
such as having to look at child name and another piece of information to get
the father then they do not have to modify the message signature. This
allows the application level code to remain untouched.

I have concerns about this since these are shared components/methods between
multiple applications and a desired change in implementation in one
application may not be the same in another.

I would like to see what others think of this practice.

Thanks.

One possible explanation from the way I code. Given the Father Child

example above. If I have a method that is to determine the Father of a
Child, that is

public Father getFatherOf(Child aChild)

I will pass in the Child reference. Why? If the signature was written

public Father getFatherOf(String aChild)


I am allowing any String anyone would care to create, including of
course correct Child names that are duplicates. How would I find the
Father given the following

(Father, John Smith) --> (Child, Joe Smith)
(Father, Fred Smith) --> (Child, Joe Smith)

Also, using object references is really the only way you have in Java
enforcing type checking, otherwise everything is a String, int, etc.

Jim

 

[Johan Poppe]

StoogeManiac skrev:

I have been brought into a large application written in Java. The
application utilizes an MVC architecture, which is slightly modified but
still maintains the basic MVC structure.

I'm running into a lot of instances where the developers have passed object
references rather then parameters into methods. For example a method call to
get the Father of a user might pass in the reference to the Child object
rather then just the child's name, which is the only value needed.

A little nitpicking: Object references rather than parameters? An
object reference _is_ a parameter. And a String is an object. The
three method signatures
getFather ( int num )
getFather ( String childName )
getFather ( Child child )
all have parameters. Primitives are handled slightly different than
objects, (they are passed by value instead of reference) but in both
the two last ones there's an object reference being passed.

Another thing is that the most logical thing to do with a method to
get the father of a child object is to let it be an object method in
Child.

Their reasoning behind this is simple, if the implementation needs to change
such as having to look at child name and another piece of information to get
the father then they do not have to modify the message signature. This
allows the application level code to remain untouched.

This is good thinking.

I have concerns about this since these are shared components/methods between
multiple applications and a desired change in implementation in one
application may not be the same in another.

And? Exactly how would this be a problem? I don't see any reason why a
change inside the getFather(Child child) method, for example to check
more than just name, should not cause trouble for other components
using Child objects or using the getFather method.

 

[StoogeManiac]

Thanks for everyone's response.



First the question was general and I wanted to see what everyone's feedback
was on the topic. We have a mix of this type of passing in the application
and it needs to be standardized.



Second, I appreciate the time that everyone took in writing their responses.



Finally (this being directed at Ken 'Ass' Ream), while I don't mind comments
that are differing in opinion I don't appreciate sarcasm. I got brought
into a project that has a mix of differing design and coding methodologies
applied to it and has been placed offshore. Classes are not abstracted well
and everything is already tightly coupled. Personally I would sleep better
tonight if I knew "assholes" such as you weren't breathing.

 

[Funny]

I have been brought into a large application written in Java. The
application utilizes an MVC architecture, which is slightly modified but
still maintains the basic MVC structure.

I'm running into a lot of instances where the developers have passed object
references rather then parameters into methods. For example a method call to
get the Father of a user might pass in the reference to the Child object
rather then just the child's name, which is the only value needed.

Their reasoning behind this is simple, if the implementation needs to change
such as having to look at child name and another piece of information to get
the father then they do not have to modify the message signature. This
allows the application level code to remain untouched.

I have concerns about this since these are shared components/methods between
multiple applications and a desired change in implementation in one
application may not be the same in another.

I would like to see what others think of this practice.

Thanks.

 

[Funny]

I have been brought into a large application written in Java. The
application utilizes an MVC architecture, which is slightly modified but
still maintains the basic MVC structure.

I'm running into a lot of instances where the developers have passed object
references rather then parameters into methods. For example a method call to
get the Father of a user might pass in the reference to the Child object
rather then just the child's name, which is the only value needed.

Their reasoning behind this is simple, if the implementation needs to change
such as having to look at child name and another piece of information to get
the father then they do not have to modify the message signature. This
allows the application level code to remain untouched.

I have concerns about this since these are shared components/methods between
multiple applications and a desired change in implementation in one
application may not be the same in another.

I would like to see what others think of this practice.

Thanks.

 

[Andy Hill]

I have been brought into a large application written in Java. The
application utilizes an MVC architecture, which is slightly modified but
still maintains the basic MVC structure.

I'm running into a lot of instances where the developers have passed object
references rather then parameters into methods. For example a method call to
get the Father of a user might pass in the reference to the Child object
rather then just the child's name, which is the only value needed.

Their reasoning behind this is simple, if the implementation needs to change
such as having to look at child name and another piece of information to get
the father then they do not have to modify the message signature. This
allows the application level code to remain untouched.

I have concerns about this since these are shared components/methods between
multiple applications and a desired change in implementation in one
application may not be the same in another.

I would like to see what others think of this practice.

Sounds like excessive coupling, IMHO -- the object being passed the Child object
has to have (unnecessary) knowledge of the Child object. Used on a large
scale, this usually leads to a maintenance nightmare.

 

[StoogeManiac]

That was my thought, there is a great deal of coupling from the domains to
the controllers and then finally back to the brokers.


I want to make something clear to everyone here. I am very greatful for any
input people provide. I don't appreciate people making comments such as:

Please tell me you haven't been brought in as an "architect" or some sort of
"senior programmer". It will help me sleep at night.

I don't believe I've been this pissed or offended by a comment in a long
time and personally I wish I could meet Ken in person. From what I see Ken
you seem live on forums, why not come out from behind your PC and talk to
someone face to face? It would help me sleep at night.

 

[Ken Ream]

| That was my thought, there is a great deal of coupling from the domains to
| the controllers and then finally back to the brokers.
|
|
| I want to make something clear to everyone here. I am very greatful for
any
| input people provide. I don't appreciate people making comments such as:
|
| Please tell me you haven't been brought in as an "architect" or some sort
of
| "senior programmer". It will help me sleep at night.
|
| I don't believe I've been this pissed or offended by a comment in a long
| time and personally I wish I could meet Ken in person. From what I see
Ken
| you seem live on forums, why not come out from behind your PC and talk to
| someone face to face? It would help me sleep at night.

Hey sorry. I've seen enough "architects" who couldn't spell MVC or OOP.
If you're just a newbie then don't take offense. If you are in a lead
position and you don't understand simple OOP concepts or that objects are
parameters too then I stand by my disgust at what I've seen too often.
Either way I wouldn't wish you weren't breathing like you wished on me.



|
| | > >I have been brought into a large application written in Java. The
| > >application utilizes an MVC architecture, which is slightly modified
but
| > >still maintains the basic MVC structure.
| > >
| > >I'm running into a lot of instances where the developers have passed
| object
| > >references rather then parameters into methods. For example a method
call
| to
| > >get the Father of a user might pass in the reference to the Child
object
| > >rather then just the child's name, which is the only value needed.
| > >
| > >Their reasoning behind this is simple, if the implementation needs to
| change
| > >such as having to look at child name and another piece of information
to
| get
| > >the father then they do not have to modify the message signature. This
| > >allows the application level code to remain untouched.
| > >
| > >I have concerns about this since these are shared components/methods
| between
| > >multiple applications and a desired change in implementation in one
| > >application may not be the same in another.
| > >
| > >I would like to see what others think of this practice.
| > >
| > Sounds like excessive coupling, IMHO -- the object being passed the
Child
| object
| > has to have (unnecessary) knowledge of the Child object. Used on a
large
| > scale, this usually leads to a maintenance nightmare.
|
|

 

[StoogeManiac]

I apologize for my comments, no one deserves to be spoken to in such a
manner and I truly am sorry. Stress will do wonderful things to your ego
and personality.

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. At the domain level
that makes extremely good design sense because if I need to modify how
Parent is used inside of GetChildren() then I don't disturb any applications
using it. But what is happening in the domain is the implementation is
being changed and the results set is being altered. In this example I might
be getting back all of the children in the original method. Then along
comes Joe and his new application needs to get all of the Children also, he
sees the GetChildren() method and decides he can use it. But then he sees
his business rule is also looking at some other attribute of Parent that
isn't currently being considered. He changes the implementation and since
it is encapsulated no one notices and it roles out. Other applications that
are dependent on this method start returning inproper result sets. 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.

The question was what is everyone else doing to deal with this. I've posted
this question in a number of locations and I'd say that I've gotten a 60-40
split in return with utilizing the reference as being the favorite.

I'm also faced with the fact that many classes are not abstracted correctly.
For example lets take a Parent. The Parent holds a reference to a
DriversLicense and currently it only the ability to handle one license. We
need to allow for multiple license to be held, that's pretty simple to
implement. But then you notice that the licenseFee, licenceRenewalDate and
several other attributes that are really part of the DriverLicence are
attached to the Parent. Now you have a problem because applications are
implementing the Parent and using those attributes that I need to move back
to the DriverLicence class or really do a stupid thing and load mulitple
Parents.

These are just a few of the things that I'm dealing with. The classes are
all tightly coupled. If I went based on what I know as a good practice and
placed all tightly coupled classes into the same package you would end up
with only a couple of packages. Inheritence in some cases is as deep as 5
or 6 levels. While I like to prescribe by a Gandolf's "He who breaks a
thing to find out what it is, has left the path of wisdom.", I need to
figure out what to do with all of this.

I'm not Super Architect, but I have designed systems and all have been
extremely successful.

While I really feel bad for my comments (worse then you probably realize) I
also think that you should have just left your last comment off completely.
It didn't provide any value to what you had previously written, which was
valuable. It just added to the stress that I already have of dealing with
this design. We work in an industry (and world for that matter) where
conceded attitudes seem to be the rule, I find it refreshing when someone
can provide good advice and not degrading in the process.

Again I apologize for the harsh comments...

 

[Ken Ream]

First off sorry for the editorial comment. You obviously know more than your
original post led me to believe. I shouldn't have vented my pet peeve
frustration on you. Hey "when you assume...."

| I apologize for my comments, no one deserves to be spoken to in such a
| manner and I truly am sorry. Stress will do wonderful things to your ego
| and personality.
|
| 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. At the domain level
| that makes extremely good design sense because if I need to modify how
| Parent is used inside of GetChildren() then I don't disturb any
applications
| using it. But what is happening in the domain is the implementation is
| being changed and the results set is being altered. In this example I
might
| be getting back all of the children in the original method. Then along
| comes Joe and his new application needs to get all of the Children also,
he
| sees the GetChildren() method and decides he can use it. But then he sees
| his business rule is also looking at some other attribute of Parent that
| isn't currently being considered. He changes the implementation and since
| it is encapsulated no one notices and it roles out. Other applications
that
| are dependent on this method start returning inproper result sets. 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.

OK I see what your concerns are. It may sound obvious but you need to limit
access to who can change implementation of such shared components. Next
look at implementing a pattern like Factory or AbstractFactory where you can
have a factory object return an object that implements a Parent interface
with an implementation of GetChildren() that uses the business rules that
apply to a specific need.



| The question was what is everyone else doing to deal with this. I've
posted
| this question in a number of locations and I'd say that I've gotten a
60-40
| split in return with utilizing the reference as being the favorite.
|
| I'm also faced with the fact that many classes are not abstracted
correctly.
| For example lets take a Parent. The Parent holds a reference to a
| DriversLicense and currently it only the ability to handle one license.
We
| need to allow for multiple license to be held, that's pretty simple to
| implement. But then you notice that the licenseFee, licenceRenewalDate
and
| several other attributes that are really part of the DriverLicence are
| attached to the Parent. Now you have a problem because applications are
| implementing the Parent and using those attributes that I need to move
back
| to the DriverLicence class or really do a stupid thing and load mulitple
| Parents.

Yeah, that's bad. Bite the bullet and refactor before it gets any bigger.

| These are just a few of the things that I'm dealing with. The classes are
| all tightly coupled. If I went based on what I know as a good practice
and
| placed all tightly coupled classes into the same package you would end up
| with only a couple of packages. Inheritence in some cases is as deep as 5
| or 6 levels. While I like to prescribe by a Gandolf's "He who breaks a
| thing to find out what it is, has left the path of wisdom.", I need to
| figure out what to do with all of this.
|
| I'm not Super Architect, but I have designed systems and all have been
| extremely successful.
|
| While I really feel bad for my comments (worse then you probably realize)
I
| also think that you should have just left your last comment off
completely.
| It didn't provide any value to what you had previously written, which was
| valuable. It just added to the stress that I already have of dealing with
| this design. We work in an industry (and world for that matter) where
| conceded attitudes seem to be the rule, I find it refreshing when someone
| can provide good advice and not degrading in the process.
|
| Again I apologize for the harsh comments...
|
|
|
|
| | >
| > | > | That was my thought, there is a great deal of coupling from the
domains
| to
| > | the controllers and then finally back to the brokers.
| > |
| > |
| > | I want to make something clear to everyone here. I am very greatful
for
| > any
| > | input people provide. I don't appreciate people making comments such
| as:
| > |
| > | Please tell me you haven't been brought in as an "architect" or some
| sort
| > of
| > | "senior programmer". It will help me sleep at night.
| > |
| > | I don't believe I've been this pissed or offended by a comment in a
long
| > | time and personally I wish I could meet Ken in person. From what I
see
| > Ken
| > | you seem live on forums, why not come out from behind your PC and talk
| to
| > | someone face to face? It would help me sleep at night.
| >
| > Hey sorry. I've seen enough "architects" who couldn't spell MVC or OOP.
| > If you're just a newbie then don't take offense. If you are in a lead
| > position and you don't understand simple OOP concepts or that objects
are
| > parameters too then I stand by my disgust at what I've seen too often.
| > Either way I wouldn't wish you weren't breathing like you wished on me.
| >
| >
| >
| > |
| > | | > | > >I have been brought into a large application written in Java. The
| > | > >application utilizes an MVC architecture, which is slightly
modified
| > but
| > | > >still maintains the basic MVC structure.
| > | > >
| > | > >I'm running into a lot of instances where the developers have
passed
| > | object
| > | > >references rather then parameters into methods. For example a
method
| > call
| > | to
| > | > >get the Father of a user might pass in the reference to the Child
| > object
| > | > >rather then just the child's name, which is the only value needed.
| > | > >
| > | > >Their reasoning behind this is simple, if the implementation needs
to
| > | change
| > | > >such as having to look at child name and another piece of
information
| > to
| > | get
| > | > >the father then they do not have to modify the message signature.
| This
| > | > >allows the application level code to remain untouched.
| > | > >
| > | > >I have concerns about this since these are shared
components/methods
| > | between
| > | > >multiple applications and a desired change in implementation in one
| > | > >application may not be the same in another.
| > | > >
| > | > >I would like to see what others think of this practice.
| > | > >
| > | > Sounds like excessive coupling, IMHO -- the object being passed the
| > Child
| > | object
| > | > has to have (unnecessary) knowledge of the Child object. Used on a
| > large
| > | > scale, this usually leads to a maintenance nightmare.
| > |
| > |
| >
| >
| >
| >
| >
| >
| >
|
|

 

[Sudsy]

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.

<snip>

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
defence.
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!

 

[Tony Morris]

I have been brought into a large application written in Java. The
application utilizes an MVC architecture, which is slightly modified but
still maintains the basic MVC structure.

I'm running into a lot of instances where the developers have passed object
references rather then parameters into methods. For example a method call to
get the Father of a user might pass in the reference to the Child object
rather then just the child's name, which is the only value needed.

Their reasoning behind this is simple, if the implementation needs to change
such as having to look at child name and another piece of information to get
the father then they do not have to modify the message signature. This
allows the application level code to remain untouched.

I have concerns about this since these are shared components/methods between
multiple applications and a desired change in implementation in one
application may not be the same in another.

I would like to see what others think of this practice.

Thanks.

This is a perfect example of separating "what you are going to do" from "how
you are going to do it".
Let's suppose you have an operation: getFather which returns a String (the
father's name). In order to achieve this operation (what you are going to
do), you must decide what information is required. Is it the Child or the
child's name ? Make efforts to think independantly of your intended
implementation. What makes more sense in your given scenario (any
suggestions would be pure speculation) ?

Once you have decided (let's assume you decide that only the Child's name is
required), define the interface:

// "what you are going to do"
interface FatherNameRetriever
{
String retrieveFathersName(String childName);
}

If time comes to implement your interface (how you are going to do it) and
you don't have enough information, it is because you didn't define your
operation correctly (what you are going to do). This generally indicates a
flaw in your design methodology, rather than the design itself (which is a
mere symptom) i.e. it *shouldn't* happen.

Making this distinction is generally a successful methodology of thought,
rather than ad hoc decisions based on misinformation or lack thereof (since
the information you provided doesn't allow any reasonable suggestions
regarding your query).

Side Note:
"I'm running into a lot of instances where the developers have passed object
references rather then parameters into methods."
This doesn't make any sense.
Java has only two types: object references and primitives.
There are only 8 (a finite set) primitive types (int, char, boolean, byte,
short, long, double, float).
Everything else (an infinite set) is an object reference (Child, Father,
String, etc.).

Good luck.

--
Tony Morris
(BInfTech, Cert 3 I.T., SCJP[1.4], SCJD)
Software Engineer
IBM Australia - Tivoli Security Software
(2003 VTR1000F)

 

[Johan Poppe]

StoogeManiac skrev:

In this example I might
be getting back all of the children in the original method. Then along
comes Joe and his new application needs to get all of the Children also, he
sees the GetChildren() method and decides he can use it. But then he sees
his business rule is also looking at some other attribute of Parent that
isn't currently being considered. He changes the implementation and since
it is encapsulated no one notices and it roles out. Other applications that
are dependent on this method start returning inproper result sets. Now
everyone is trying to figure out what has happened.

Hmm. I'm not quite sure I understand you, but I see this more as a
question of having proper documentation, and about respecting current
code, than about design choices.

The first getChildren()-method must have a doc comment stating what it
is supposed to do.

People who comes along on a later stage and want a method that is
supposed to do something else, must make another method.

And this is regardless of whether the getChildren() method is passed a
Parent object or a String object or whatever.