Make the object smart, or the collection manager?

[Burt]

I'm designing a C# app with Security and Portfolio objects. The goal is
to value all the Securities in the Portfolio. There are four security
types, and each is valued a different way, but all use the same
Portfolio level market data for valuation. For each security, data is
passed to a 3rd party assembly which returns a value.

Question: Do I put the Value method in the Security or the Portfolio
object? The app should be multithreaded.

I know this is more a generic OOP Q, but i know the gurus here could
offer some sage advice.

Thanks,

Burt

 

[VJ]

Portfolio is a collection of securities. You would put the value method in
security that computes value of each security, then a aggregator method in
the collection class that basically loops the items and calculates/add them
to a single value. You also never mentioned whether these objects are UI or
non-UI. The reason I ask is because in multi-threaded applications, you have
to be careful about cross-communication between threads. So you could
consider this point to decide where to keep the value method

VJ

 

[Burt]

There is a client side Windows GUI, but the valuations will happen on
an non-UI dll on the server. The 3rd party assembly is not thread safe-
have to create a new instance with each deal. I'll keep analyzing this.
Thanks again.

Burt

 

[DeveloperX]

Slightly off topic, and bear in mind I'm not entirely sure of the scope
of your application, but it might be worth considering issues like
weighted values, i.e. what percent of the portfolio's value is
represented by a particular security. From a design perspective it
means either the security has to know about its portfolio (bad imo), or
the portfolio has to calculate that percentage.

On topic, you might want to consider a valuation class which can
coordinate the valuation of the assets in the portfolio, This would
also resolves the issue above. Just a thought.