The Converter


The Converter

Looks like this:

 public static class Converter {

    public static Product toProductFromWidget(Widget widget) {
      return toProduct(widget.getLength(), widget.getHeight());
   }
   public static Product toProductFromThing(Thing thing) {
      return toProduct(thing.getA(), thing.getB());
   }

    private static Product toProduct(int x, int y) {
      return new Product(x, y);
   }
}

What does it do?

The converter is useful when you need a uniform treatment for disparate inputs.  One example would be if you're receiving data from multiple vendors but need to assure that regardless of upstream, the treatment and output must be the same.

 In this way, a converter rather resembles an inverse Factory pattern.  Whereas a factory takes a uniform input with variance in its values and produces a range of disparate outputs based on those values, a converter takes disparate inputs and produces a uniformly formatted output.

Why is this useful?

There are numerous ways to accomplish what the Converter does, but the benefit we get from its application is a single, co-located, intuitive representation of transformation logic.  Rather than having to search your codebase for how you get from A to B, it's all in one place.

An alternative would be to push the mapping behaviors into their respective sources, Widget and Thing above. However, by doing so you risk the uniformity of your toProduct implementation.  In time, what started the same may diverge.  Even if the behavior stays identical, you may get differing implementations causing undue complexity.

To address this problem, you could have Widget and Thing each inherit from a class implementing a single toProduct method.  However, there are cases where you may not wish to or may not be able to share classes across modules.  An example would be when Widget, Thing, and Product each have their own micro-service.  Pushing the toProduct method into Widget and Thing would again risk divergence.

If your "toProduct" method shouldn't have multiple implementations and you want to minimize coupling across source classes a Converter may help.

No accessors?

Since the output of a converter is the singular Product instance, we should avoid opening it up by introducing accessors such as getX() and getY() in the above example.  Why not?  The Converter's responsibility is to provide a mapping from N+ classes to our Product class, nothing else.  Having access to anything other than Product makes the Converter's purpose ambiguous.  A future developer may be tempted to add behavior better located somewhere else.

No mutators?

All the input we need for our conversion is in the source classes.  There really should be no state in the Converter.  Adding mutators again introduces ambiguity into purpose of the class.

Since we have no mutators and no accessors we have no state.  The class is thus static.  However, there may be more complex cases where state may be necessary.  I've simply provided a simple example here.  That said, if no state is necessary, no state should be allowed.  This is a form of Principle of Least Privilege.

Comments

Post a Comment

Popular posts from this blog

Engineering Truisms

This is a brief collection of quotes, laws, and truisms that I've gathered over the years.  I've kept those that have consistently proved themselves across organizations and projects during my career.
Read more

The Telescoping Constructor (Anti-Pattern)

Image
The Telescoping Constructor Looks like this: Widget(varA) {...} Widget(varA, varB) {...} Widget(varA, varB, varC) {...} or Widget widget = new Widget(x); widget.setVarA(...) widget.setVarB(...) widget.setVarC(...) There are both shared and specific problems for each variety.  Let's talk about both. The 1st case, supernumerary constructors. What's wrong with this? Well, the good news is you provide  quiet consumption since there's a bespoke constructor for every use case.  Rather than have noisy construction, where the consumer must fill in a bunch of nulls, you move the noise into the implementation.  We shouldn't make assumptions on how many times the class will be used, so keeping the complexity to ourselves is generous and will lead to a more maintainable macro system. However, one problem here is that the end consumer is not restricted in their choice of constructors.  Like shopping at the super ...
Read more

A Strategic Approach to Precision Process Automation

Image
The global tech labor arbitrage trade has matured since its start in the Clinton era.  We've witnessed real estate in places like Mumbai and Singapore appreciate to levels rivaling NY and London.  The rising tide lifts all boats.  As global tech labor costs have flattened somewhat, software has gotten more expensive to produce and maintain.  The market is betting that AI will largely alleviate this by supplanting much of software engineering as a practice.  However, until this plays out, being judicious about when and how to use software is more important than ever.   While it's constructive to build software systems as "black boxes," it's folly to view them as crystal balls.  Increasingly, software is operations .  That engineer who knows the code like the back of his hand is your foreman.  Code is not static, it's constantly evolving to meet business demands and improve efficiency.  "Software Engineering is programming integrated ov...
Read more