Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Here is a real live factory from my code base. It's used to generated a sampler class that knows how to sample data from some dataset (it's originally in C#, so excuse any java faux-pas)</p> <pre><code>class SamplerFactory { private static Hashtable&lt;SamplingType, ISampler&gt; samplers; static { samplers = new Hashtable&lt;SamplingType, ISampler&gt;(); samplers.put(SamplingType.Scalar, new ScalarSampler()); samplers.put(SamplingType.Vector, new VectorSampler()); samplers.put(SamplingType.Array, new ArraySampler()); } public static ISampler GetSampler(SamplingType samplingType) { if (!samplers.containsKey(samplingType)) throw new IllegalArgumentException("Invalid sampling type or sampler not initialized"); return samplers.get(samplingType); } } </code></pre> <p>and here is an example usage:</p> <pre><code>ISampler sampler = SamplerFactory.GetSampler(SamplingType.Array); dataSet = sampler.Sample(dataSet); </code></pre> <p>As you see, it's not much code, and it might even be shorter and faster just to do</p> <pre><code>ArraySampler sampler = new ArraySampler(); dataSet = sampler.Sample(dataSet); </code></pre> <p>than to use the factory. So why do I even bother? Well, there are two basic reasons, that build on each other:</p> <ol> <li><p>First, it is the simplicity and maintainability of the code. Let's say that in the calling code, the <code>enum</code> is provided as a parameter. I.e. if I had a method that need to process the data, including sampling, I can write:</p> <pre><code>void ProcessData(Object dataSet, SamplingType sampling) { //do something with data ISampler sampler = SamplerFactory.GetSampler(sampling); dataSet= sampler.Sample(dataSet); //do something other with data } </code></pre> <p>instead of a more cumbersome construct, like this:</p> <pre><code>void ProcessData(Object dataSet, SamplingType sampling) { //do something with data ISampler sampler; switch (sampling) { case SamplingType.Scalar: sampler= new ScalarSampler(); break; case SamplingType.Vector: sampler= new VectorSampler(); break; case SamplingType.Array: sampler= new ArraySampler(); break; default: throw new IllegalArgumentException("Invalid sampling type"); } dataSet= sampler.Sample(dataSet); //do something other with data } </code></pre> <p>Note that this monstrosity should be written each and every time I need me some sampling. And you can imagine how fun it will be to change if, let's say, I added a parameter to <code>ScalarSampler</code> constructor, or added a new <code>SamplingType</code>. And this factory has only three options now, imagine a factory with 20 implementations.</p></li> <li><p>Second, it's the decoupling of the code. When I use a factory, the calling code does not know or need to know that a class called <code>ArraySampler</code> even exists. The class could even be resolved at run-time, and the call site would be none the wiser. So, consequently, I am free to change the <code>ArraySampler</code> class as much as I want, including, but not limited to, deleting the class outright, if, e.g. I decide that the <code>ScalarSampler</code> should be used for array data as well. I would just need to change the line</p> <pre><code>samplers.put(SamplingType.Array, new ArraySampler()); </code></pre> <p>to</p> <pre><code>samplers.put(SamplingType.Array, new ScalarSampler()); </code></pre> <p>and it would work magically. I do not have to change a single line of code in the calling classes, which could number in the hundreds. Effectively, the factory makes me in control of what and how the sampling occurs, and any sampling changes are efficiently encapsulated within a single factory class that is interfaced with the rest of the system.</p></li> </ol>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload