I have been to an interview for a financial programming job, and I could not answer to one question for sure. I thought about it again, but I really cannot find a good answer.
They asked me to design the UML diagram for a class Instrument (financial instrument, such as bond or stock), which has a price, a type which can only be "Forex" or "Rate", and a notional which can either be a double or a double + array of object.
The price is not a problem, it's just a double.
But I'm stuck on the type : I thought to an enum and to a boolean, but I'm really not sure it's the best way to do it
and on the notional : I designed another class for that, with a double attribute and an optional array of object attribute. But this is also really ugly.
What would be the good way of solving this problem?
Thank you for your help
Best Answer
The presence of a type attribute is a bit of a concern for me. The fact that there can be different types of Instruments implies that there should be an abstract Instrument interface, with common methods declared, and multiple concrete implementations (stock, bond, etc.). The forex/rate type may fall into this category, or it may not. I don't know enough about financial instruments to make a good choice here. Perhaps the question was really seeking to prompt you to ask more about the domain?
In general, giving objects type attributes is something I try to avoid. If you put them in, then you presumably will have code outside the class that behaves differently depending on the type of the object being used. This violates the idea that in OOD you let the object do the work (passing in any extra information needed), not the code that uses the object. In other words, type attributes defeat the purpose of polymorphism. In any event, the compiler usually provides type information automatically for all objects. Can you use that?
Sometimes type attributes make sense, for example if you want to gather some statistics on a collection of polymorphic objects (20% stocks, 35% bonds, 40% forex, 10% rate, etc.).
Not knowing much about what a "notional" is, I think your solution to have a class with a double and optional array is a reasonable choice. I see no reason why the degenerate case of a notional with an empty array is any less valid than one with a nonempty array.
If you absolutely have to have a type attribute for forex and rate, I would go with an enum. First, just because it can only be one of two things now does not mean that more things won't be needed later (what about options, derivatives, credit default swaps, etc.?). Second, if you go with a boolean, where true means forex and false means rate, then you are implicitly saying that an Instrument which is "not forex" is a rate Instrument. This is not quite the same thing as explicitly saying an Instrument is a rate Instrument. By conflating "not forex" and rate, you prevent the concepts from being separate in the future.
The conclusion I am coming to is that the overarching Instrument class should be a weak one. There is so much variation in the specializations of it that it makes little sense to push much functionality and attributes into the superclass. It's kind of like putting cars, planes, boats, and trains into a Vehicle class. There's not much you can put there beyond carrying capacity and weight, and the fact that instances of each are all Vehicles. Better to let the individual Instrument types stand on their own, loosely collected under the Instrument class.