What if you were to not pass the car when the engine was built but instead
enforce that relation at the creation of the engine object? You could do this
either by passing it through the constructor ..
public class Engine {
public Engine(Car _Car) {
//save the Car I belong to
}
}
you could then later push a call back out to the car if need be ...
another similar method would be to use events on the engine object that the
car object listens to for its children.
public class Car {
public void setEngine(Engine _Engine) {
//remove events from current engine
//subscribe to events on new engine
}
}
public class Engine {
public event BuildHander Build;
}
Either way in your client code you would simply say, Engine.Build() .. the
engine would then notify its parent of the building ... I personally prefer
event based example in many cases because it allows for many subscribers to
the build event but if this is a case where you are trying to hide that
information, the first may be more useful.
Cheers,
Greg
"Nick" wrote:
Hello,
This isn't specific to C#, but that is what I am using to develop my app. I
am trying to figure out how to organize my code and I'm not sure what the
best way of doing it is. For the sake of simplicity let's say I have three
classes - car, engine, and body. The car class has an instance of engine and
body.
Each class has a "build" method. The car build method calls engine.build and
body.build. I have an interface that has a visual representation of the car.
When a property is modified in the engine I call engine.build. However, I
have to pass it a reference to the car object.
I don't want to build the entire car everytime a property is modified.
Should I move the build methods into the car class? So I would have
BuildEngine and BuildBody? Or what is the best way to approach this?
Thanks for any help, I really appreciate it.
Thanks,
Nick
