That's a good thing to be curious about. This kind of thing often comes down to the responsibilities of each class. When you have to do something to an object, think about asking each object to do the work for you. The car should probably be able to access its wheels so maybe the car should already have the wheels in some member variable.
Your model with mechanic is maybe too close to the real world. Real life - the mechanic removes the wheel, repairs the tire, checks it in a water tank, puts the wheel back on - doesn't always translate well to software. Code might look more like:
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Nov 24, 2004
Nice to see reply from you..yep u are correct, but wat i was intending was a little different.so let me define it in someother way..
a class SAMPLE have some methods and i want to replace methodA by methodC dynamically this methodC is in vector.
so now the class should parse class SAMPLE to find some methodA and replace it with methodB which is in vector.
my client program uses another object which does this for him
my client program
should call modifier by sending sample and vectorr to it to do the work for him. what i feel is 3 alternatives
1st alternative to call modifier
modifier m = new modifier(); m.modify(SAMPLE,vectorr);
2nd alternative to call modifier modifier m = new modifier(sample); m.modify(vectorr);
3rd alternative modifier m = new modifier(sample,vectorr); m.modify();
as you see the constructor and method parameters are different.
my question is which one is better alternative and which one should be used and why..
There is no general answer to your query as it depends very much on the situation. All three versions would work fine. By the way, there's a fourth option: pass vector to constructor and sample to the method call.
However, think about what Stan wrote. In object oriented software, objects typically operate on themselves. It's certainly true that sometimes it makes more sense to have an "outside" utility object that operates solely on other objects as in your example, but I find that to be a symptom of procedural thinking more often than not.