Design Pattern for using different implementations of a class/method

Sometimes we design more than one algorithm to get the same results. For instance, I have written a class which stores my data in trees, and another class that stores roughly the same data in, say, linked lists.

I will publish an interface (abstract class) called ThingStore, and I'll subclass it to TreeThingStore and ListThingStore, each respectively using trees or linked lists.

However, since I'm publishing an abstract class, I have to have someone to decide which implementation to use (EDIT: so the caller won't care about this), and I have no problem in having this hardcoded. I have needed this more than once, but I have looked at GoF and other Design Patterns catalogues unsuccesfully. The most si开发者_如何学编程milar pattern is the "Strategy" one, but it achieves diverse goals.

So, is there a Design Pattern for this intent? If not, someone can create one or tell me why this should not be done (or better ways to achieve the same results)?

It's a bit odd that you would specify implementation like that. Why does your caller care how you implement a particular feature? All he should care about is that your data store stores the data correctly and not really be concerned about the underlying data structure you use. But, let's say the implementation was expressed externally as different features of the data store (one is better for lots of inserts and one is better for lots of reads for example). Then, it would be up to the caller to specify which concrete class they wanted to instantiate. As the class designer, it's a bit presumptuous for you to assume you somehow know best. :)

Given that, you could definitely wrap creation of the object into a Factory and allow your user to specify to the Factory which features are important. You could go even further and use an Inversion of Control pattern where you allow your caller to instantiate and hand you a storage mechanism to use, but that seems overkill for what you are trying to do.

I suggest you checking the Bridge pattern. It intent is to decouple an abstraction from its implementation so that the two can vary independently.

The collections class framework in the Java API provides several examples of use of the bridge pattern. Both the ArrayList and LinkedList concrete classes implement the List interface. The List interface provides common, abstract concepts, such as the abilities to add to a list and to ask for its size. The implementation details vary between ArrayList and LinkedList, mostly with respect to when memory is allocated for elements in the list.

Using the Bridge pattern with a Factory to obtain the concrete implementation your client is interested in seems like a suitable approach to your problem.

Check out the Factory Pattern or the Adapter Pattern (depending on what you are looking for). Adapter is more for wrapping an exitsting implementation where factory is for creating from a tree of subclasses, or composite classes.

The factory is probably your closest pattern as it allows designs similar to:

ThingStore theThingStore = ThingStoreFactory.GetStore("tree");