Passing Classes as Arguments to Functions of Other Classes

[crouse]

Is it bad programming practice to pass a class as an argument to a
function of another class in order to access the functions of the
passed class within the other class. Outside of the typical get and
set methods which I believe are typical .For example,

class A {
func1 ( B b ) {
b.func1();
}
}

class B {
func1 ()
}

.....

a call is made at some point to -> a.func1( B b );

Thanks a Million,

EVAC

 

[jmcgill]

Is it bad programming practice to pass a class as an argument

You are passing an Object of type B in your example, not a "Class" as I
read your question. (It is possible and fairly common in some
situations to pass a Class Object).

You are passing an object to a method which performs operations on that
object. There's nothing wrong with this. Would you expect people to
criticize a method that takes a String argument, for doing String
operations on that argument?

class A {
func1 ( B b ) {
b.func1();
}
}

class B {
func1 ()
}

Depending on what you're doing, I might call that either a Delegate or a
Decorator.

 

[crouse]

Yes, indeed it is an object, wrong use of terminology on my part. I'm
going to need to take a look at the Delegate pattern. If that is what
I'm using it was totally unitentional. Anyways, I guess my concern is,
if we look at this a little deeper, suppose we have two classes A & B
again. We then instantiate an object of class A. Suppose there is a
function from class A ( func1 ) that calls another function from class
B ( func1 ) so we must pass an object of class B as argument to the
function in class A. Now say for instance the function of class B turns
back around and calls a function from class A ( func2 ) and does
something in turn on the original class A object using the keyword this
as an argument to func1 of class B. Is this methodology sound. It seems
as though the indirect nature of function calls in this situation isn't
good design, but for whatever reason I can't see any other way around
it. The reason is because there are many class B's derived from an
abstract class type that knows how to handle the function call func1
polymorphically and we can handle the manipulation of an object
instance of class A accordingly.

class A {
func1 ( B b ) {
b.func1( this );
}
func2() { };
}

class B {
func1 ( A a ) {
func2( a );
}
}

 

[Bill Medland]

Yes, indeed it is an object, wrong use of terminology on my part. I'm
going to need to take a look at the Delegate pattern. If that is what
I'm using it was totally unitentional. Anyways, I guess my concern is,
if we look at this a little deeper, suppose we have two classes A & B
again. We then instantiate an object of class A. Suppose there is a
function from class A ( func1 ) that calls another function from class
B ( func1 ) so we must pass an object of class B as argument to the
function in class A. Now say for instance the function of class B turns
back around and calls a function from class A ( func2 ) and does
something in turn on the original class A object using the keyword this
as an argument to func1 of class B. Is this methodology sound.
Yes

It seems
as though the indirect nature of function calls in this situation isn't
good design,

Why? What makes you feel uncomfortable?

 

[jmcgill]

Is this methodology sound.

Short answer: Yes.

If it makes sense in your design, there's nothing at all wrong with the
way you are passing one object to another, to have an instance method
called on that object.

There might be some tricky inheritance related things if one of these
classes is derived from the other, but that is not the case in your
example.

The only design question I see in your example, is that of using the
same method name in two heterogenous classes, and that is purely a
question of whether it makes sense to do that in your specific
application.

If you asked your question in a form where A and B do not each have
methods named "func1" and "func2", would you still be wondering the same
thing?

Not exactly on topic with your question, but:
I suspect you could benefit from a good solid exercise on the mechanics
of inheritance. Even people who think they know the language really
well, are sometimes surprised by the interactions of the inheritance and
polymorphism rules, particularly when you throw casts and statics into
the mix.

 

[crouse]

Yes

Thanks for looking at it and determining it is indeed sensible.

Why? What makes you feel uncomfortable?

I wasn't sure. Mainly lack of experience and doubt in OOD skills caused
me to distrust it. However I feel much better now!

 

[crouse]

Short answer: Yes.

Awesome! As I mentioned above, wasn't certain.

If it makes sense in your design, there's nothing at all wrong with the
way you are passing one object to another, to have an instance method
called on that object.

There might be some tricky inheritance related things if one of these
classes is derived from the other, but that is not the case in your
example.

The only design question I see in your example, is that of using the
same method name in two heterogenous classes, and that is purely a
question of whether it makes sense to do that in your specific
application.

No. I think you may have read too much into that particular example. I
threw that example together very fast without even realizing that. If
they are two heterogenous classes, it shouldn't matter... right? Like
if you define a print() member function for each class??? I can see it
being a source of confusion nevertheless, if that was your point.

If you asked your question in a form where A and B do not each have
methods named "func1" and "func2", would you still be wondering the same
thing?

Not exactly on topic with your question, but:
I suspect you could benefit from a good solid exercise on the mechanics
of inheritance. Even people who think they know the language really
well, are sometimes surprised by the interactions of the inheritance and
polymorphism rules, particularly when you throw casts and statics into
the mix.

The application I'm currently working is exactly that exercise.
Seemingly the more you figure out the more you can get confused about
those mechanics. Don't mention casts.

 

[Alex Hunsley]

You are passing an Object of type B in your example, not a "Class" as I
read your question. (It is possible and fairly common in some
situations to pass a Class Object).

You are passing an object to a method which performs operations on that
object. There's nothing wrong with this. Would you expect people to
criticize a method that takes a String argument, for doing String
operations on that argument?


Depending on what you're doing, I might call that either a Delegate or a
Decorator.

It could also match the pattern known as Listener (also known as
Publisher/Subscriber)