Jim_Found wrote:Simply start with polymorphism. You have an Order interface. There is a DeliveryOrder implementation and a CarryOutOrder implementation. Perhaps some common code can be refactored out into either OrderHelper (delegation) or AbstractOrder (inheritance). If you really really want to jam a pattern onto that, use AbstractFactory.
kevin, i know. this is an oversimplified toy situation for the sake of brevity. ultimately what I am trying to get at is what pattern should/can i use when there are many different configuration options.
coming from a rather structural programming background, i know many things can be solved easily with a bunch of if's and case statements, and i do have a habit of doing so, but this is not real oop. so i am trying to figure out what patterns work (may not be efficiently at first) for certain situations.
Jim_Found wrote:Patterns are, IMO, primarily for communication. I should be able to say, "we need some kind of a bridge between those two systems, or those five different tasks look like a strategy to me, or see if we can use an abstract builder and an interface to hide all those implementations." I don't expect to see someone run off and code FooStrategy and BarStrategy. It's more a useful way of thinking and communicating about problems. Most non-trivial solutions for a component use multiple patterns, mainly subconsciously. But I would never start out by trying to jam a pattern into a problem.
saish, thanks for the suggestions. i know you are trying to get me onto the right track, but coming from a structural background, it is sometimes difficult to think in terms of abstractions etc.
i hear people making fun of "big block of if statements" all the time, but i do that quite frequently. so i try to squeeze myself into the design patterns realm to do away from those laughable big block of if statements. but on the other hand, i think patterns are making things more complicated because all they do is adding a layer of indirection. in fact, with some IDEs, navigation of pattern codes is quite annoying because the IDE only takes the (inter)face value of the code and tends to jump into the abstract level code that is either an abstract class or an interface, so i actually have trouble understanding why many people are saying using patterns make things easier...