Can't decide which design pattern to use on a problem.

I have a system that does some stuff - and among other things it gets info about products from osCommerce's (famous web store software) database.

The trick is that I need to make sure system can easily take that data from other sources if needed. Obviosly data is more or less the same wherever I get it from - but in diferent format.

Specificly first thing to be added to the system is product management - in case someone doesn't already have osCommerce.


As I've been reading "Design Patterns Explained" book and I came to conclusion that number of patterns could be used to tackle this problem. Adapter, Bridge, Strategy or most likely Abstract Factory.


To sum it up. My plan is to write a "driver" for each type of data source that would all output the data in same format - format that application would understand.

Is this the right aproach? Is Abstract Factory right match for that?


PS. Asked this question in Perl forum, but no answer so far - so if some admin decides this is double post. Please move one from Perl forum into this one, or delete ones in Perl forum - thanks.

The Factory pattern: You want to use it when creating (like) objects and don't want to expose the recipient to managing a mess of dependencies. Think of it as having a class that maintains the necessary configuration info, so 10 distinct classes don't need to get it as well and can focus on their business logic. You generally use factories with constructor dependencies, rather then setter injected ones.

The Strategy pattern: Its good when you are passing back an object with the SAME interface. The recipient doesn't need to know how its being done to effect their business logic and its determined at run time where you get to choose what is most appropriate. Imagine writing a chess game, where the computer competitor was trying to tune itself to be challenging (but not impossible). As it analyzed your moves, it determined on the fly what expert personalities to use against you and how good of a player you are. This strategy changes repeatedly at run time, but maintains a constant interface. (Sorry, this is a bit of a tough one to find a great example for)

The Bridge pattern: This one is tough to get your head around. Its all about allowing the abstraction and implementation to vary independantly. I like the example of a household switch (the abstraction) and the light/fan/etc (the implementation). The switch can be implemented in many ways, from a two-position to a dimmer to a clapper. However, it does need to have a reference to the implementator to tell it what to do. However, that's a standard interface (perhaps just a "On/Off" signal or a hard cut to the power). What it drives doesn't matter and can change over time. Some day you decide to switch from a two-position to a voice activated one and later have it change from turning on the closet light to the indoor spa (you renovated). This is the same pattern, but in software.

The Adapter pattern: This one just acts as, well, an adapter. It converts from a U.S. power socket to a European one. It lets your VGA monitor plug into the DVI port. It lets two software systems (with similar intents) share information without having to know how the other handles data. For example, both may maintain student records, but have different views on what a "student" is. It can be as trivial as one maintaining rank as "freshman" and the other by year. Neither need to know about the existance of the other and screw with its business logic. An adapter is the only one knowing both and handles the conversion process.

***
It sounds to me as if you want an Adapter pattern. Depending on what format it gets, it converts it to a standardized one. When looking at patterns, try to distill what their intent is and then try to match it to your own. Many are only subtly different, but that's because the intent (goal) has only slightly changed.

Thanks for clarifying the things. And from your explanation I also concluded that Adapter seems like best pick.