Passing Classes as Arguments to Functions of Other Classes

Thread view:

crouse@physics.wm.edu - 09 Aug 2006 23:39 GMT

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

Reply to this Message

jmcgill - 10 Aug 2006 00:42 GMT

> 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 ) {
[quoted text clipped - 5 lines]
> func1 ()
> }

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

Reply to this Message

crouse@physics.wm.edu - 10 Aug 2006 03:23 GMT

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 );
}
}

> > Is it bad programming practice to pass a class as an argument
>
[quoted text clipped - 19 lines]
> Depending on what you're doing, I might call that either a Delegate or a
> Decorator.

Reply to this Message

Bill Medland - 10 Aug 2006 18:39 GMT

> 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
[quoted text clipped - 7 lines]
> 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?

> 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
[quoted text clipped - 38 lines]
>> Depending on what you're doing, I might call that either a Delegate or a
>> Decorator.

Signature

Bill Medland

Reply to this Message

crouse@physics.wm.edu - 11 Aug 2006 02:42 GMT

> > 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
[quoted text clipped - 9 lines]
>
> Yes

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

> > It seems
> > as though the indirect nature of function calls in this situation isn't
> > good design,
>
> 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!

> > 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
[quoted text clipped - 38 lines]
> >> Depending on what you're doing, I might call that either a Delegate or a
> >> Decorator.

Reply to this Message

jmcgill - 10 Aug 2006 18:57 GMT

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

Reply to this Message

crouse@physics.wm.edu - 11 Aug 2006 02:51 GMT

> > Is this methodology sound.
>
> 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
[quoted text clipped - 8 lines]
> 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
[quoted text clipped - 6 lines]
> 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.

Reply to this Message

Alex Hunsley - 12 Aug 2006 03:08 GMT

>> Is it bad programming practice to pass a class as an argument
>
[quoted text clipped - 19 lines]
> 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)

Reply to this Message

Passing Classes as Arguments to Functions of Other Classes

Free Magazines