1

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

  • 1
    I did my best to answer given the information in the original question, but knowing more about the type (forex/rate) and notional would help, as I'm not a financial expert. Also, is the stock/bond distinction orthogonal to the forex/rate type, or are they all potential types of instrument? – Randall Cook May 19 '15 at 20:11
  • Thanks a lot for your answer. The stock/bond distinction is not part of the problem. That was just to show what a financial instrument is, because we are not in a financial forum. The instrument can only be forex or rate, you can forget I talked about stocks and bonds The notional is the amount that we hold if we use that instrument. For example, if you buy a rate (which is a short name for an interest rate swap, I guess), how many contracts you hold when you purchase one instrument. It's just like a multiplier of the price. And I did not really got why they want to let it be an array also – MarinD May 20 '15 at 7:07
2

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.