Reputation: 93
I received a homework assignment. I am not able to decide which design pattern to use.
I have currently implemented strategy pattern. But some of my friends are implementing factory design pattern. I just need validation for the same.
This is the problem:
Suppose you are working at a new startup where you have created a collection of specialized algorithms. Interface of each algorithm is well defined in terms of input and output of the algorithm. For example:
// Class: AlgorithmFn1 public java.util.List compute(java.util.Map<String, Float> data) // Class: AlgorithmFn2 public java.util.Map<String, Integer> compute(java.util.Collection data)
and so on…
The startup plans to sell these specialized algorithms as libraries (.jar file) to its client organizations for use in their software applications. Internal implementation of these algorithms keep evolving without affecting the interfaces of algorithms.
You need to implement suitable set of classes (in Java) which can be used by the client organizations to:
Obtain new instances of concrete classes that implement the respective algorithms.
Shield the client’s code from the future changes in your implementations of the algorithms. That is, you need to design suitable classes which will exploit the object oriented programming principles for creating families of related objects without specifying the names of concrete classes of such objects.
Upvotes: 1
Views: 144
Reputation: 40894
A factory produces something that conforms to an interface (or superclass) but with an implementation that can vary. This seem to match the idea of "implementations keep evolving".
Upvotes: 1
Reputation: 1074395
Strategy would be for picking between multiple different algorithms with the same API at runtime, but this assignment doesn't sound like that. A couple of things argue for Factory:
The APIs of the algorithms are different
This
Obtain new instances of concrete classes that implement the respective algorithms.
And this:
That is, you need to design suitable classes which will exploit the object oriented programming principles for creating families of related objects without specifying the names of concrete classes of such objects.
So yes, Factory with a public interface per algorithm, a non-public concrete class per algorithm, and a public factory for each algorithm. (There are various ways to spin that in terms of implementation, but conceptually that's what your'e looking for.)
Upvotes: 4