none
One object or two? RRS feed

  • Question

  • Hello,

     

    High-level design thought, looking for feedback.  I have an object that represents a financial entity.  Each entity has several factors that determine how the overall entity is priced.  The entities are represented with composition and interfaces, so each "entity" is represented by several nested objects.  Once an entity is instantiated and all of its data is populated, it will have a price which is made up of a the sum of each of the entity's nested objects prices.  Can any arguments be made for or against "price" simply being another property on each nested object vs. "price" as its own separate object?

     

    Thanks,

    Scotty

    Tuesday, August 3, 2010 5:45 AM

All replies

  • If price is one "field" that defines how much is charged for the entity, then it seems like it would be a property.

    If there is more to price than that, then it might be worth making it its own object.

    Hope this helps.


    www.insteptech.com ; msmvps.com/blogs/deborahk
    We are volunteers and ask only that if we are able to help you, that you mark our reply as your answer. THANKS!
    Monday, August 9, 2010 5:56 AM
  • Your price determination sounds like it is a market. The price is assigned based on certain characteristics of the entity. The Entity should not be responsible with the rules to price itself. What if the rules for pricing change or vary from entity to entity?

    If you need say Price.EvaluationDate for a bond, then you could make it a class but in all my experience with modeling financial instruments, price has always been a float or decimal, it was never a seperate class. Rather, it was a property on an entity class, which signaled that entity's price at some point in time, along with some other measures, like trade date or convexity.

    I would build the Entity with all the different properties including price as a property. Then have a seperate object for pricing, which takes an entity, and depending on the type, sets the price property using the passed entity's other characteristics. Change the rules? No problem, change the seperate mechanism.

    If you want the entity to be responsible for its own pricing, then make it a property and in the getter, simply return the summation of the other prices. This doesn't sit well with me though.

    Tuesday, August 17, 2010 7:22 PM