mercredi 26 octobre 2016

Two-way OOP design-pattern

This is kind of a general question, let me formulate it in a particular scenario. I am coding a pricing system. In one hand there are several "engines", on the other, several "instruments". I created class hierarchies for both of them.

My problem comes now that I want to implement a pricing mechanism. Given a specific engine AND an a specific instrument, together they determine the algorithm to calculate a price. It would be nice to code it in 2-entries table. Both instances contain vital information, none seems more important than the other. In OOP methods belong to one class, so I see no decent design to deal with this: the "pricing" method should be in the Instruments class, or the Engines?

Whatever way I go I have the same problem. Suppose I decide it should be in the engines. Then, inside the pricing methods I should have an 'if-then-else' instruction dealing with each possible InstrumentClass? This seems way too ugly (and tight coupling!), specially if I am going to have to check it with something like

isinstance(inst, InstrClass1)

I can imagine similar situations arise in many contexts. What is the best design-pattern to deal with them?

Aucun commentaire:

Enregistrer un commentaire