General design question

[Guest]

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

 

[John Murray]

Just a different way to approach the problem

1) Have an IBuildable interface, of which engine, body and all other
components implement. This could implement a Build method as well as a
Parent property.
2) Have a collection in car that maintains a dynamic list of each
component that has been added, and when the component is added to the
car, the car can set the parent (this) property to the component.
3) If you call build on an individual component, it already has a
reference to it's parent (car) and can use/notify that reference as needed.
4) If the car needs to rebuild all components, it can generically walk
through every IBuildable instance that it knows about calling the
Build() method which allows you to dynamically vary the components that
the car can contain.


But then again, I could be wrong...

 

[Oscar Thornell]

Hi,

What you are looking for is basically the "Factory Pattern" where you
implement a factory class that takes care of the creation of your instances.
IVehicle vehicle = new VehicleFactory().GetVehicle(..);

I suggest that you start looking at this MSDN article to get a feel for it:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/factopattern.asp

After that I would suggest:
http://www.martinfowler.com/articles/injection.html
http://www.springframework.net/

For the organizational part of your code (and not the creation of
objects...)...
The classes you describe are all part of your "domain" so I would put them
in the "Domain" namespace...

<Your Org/Biz name>.<App name>.Domain
Then you could have a "Business" package that takes care of the
flow/security/bla bla of your use cases...

/Oscar

 

[Guest]

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