The Nonce Class and Anemic Domain Models




The Nonce


The English language is immensely flexible.  Perhaps one of the reasons it's been adopted as a global language for business is its versatility.  We've got words like thingamajigger and cattywumpus.  We even celebrate our Xtreme freedom by naming things after our made up words.


Particularly here in America, where things aren't so formal, one can see great liberties being taken.  Sometimes bad grammar is actively sought out in order to grab the audience's attention.

It's said that art imitates life, and even upon the canvas of the IDE one can observe this phenomenon.  A coder doesn't know how to get from A to B so they just shoehorn the thing in, plucking qualities that seem okay-ish from context.  This is the Nonce class, like its English sibling, an object "coined or used only for one particular occasion."  An improvisation.  An expedient.

If applied with discipline, this may appear in the form of an anonymous class, function, or even the Command pattern.  Alas, discipline is the requisite quality of a soldier, not the typical untucked foosball table attendee.

As with its linguistic cousin, while it adds great convenience the Nonce brings with it some problems.
  • It's intent is ambiguous
  • It's imprecise, open for interpretation
  • It's crude and its nuance is untested

Symptoms

How do you distinguish a Nonce from a benign POJO?
Classes that may call for further consideration can come in many forms:
  • A class that doesn’t appear to do anything
      • a POJO with no data layer representation
      • a POJO, above the data layer that has no behavior
    • A class that does too much
        • a class that combines potentially unrelated member data
        • combines disparate behaviors
        • could easily be broken into 2+ mutually exclusive concepts

      Solutions

      A litmus test as to whether your system contains this problem is to check how many POJO-like classes or service contracts you have that don't correspond to an object in the data layer.  If your system is built atop a normalized DB, you typically will have a table that matches one to one with your class or contract.

      There are several benefits to this:
      • symmetry between the data layer and business layer.
      • it's generally indicative of strong encapsulation and single responsibility
      • encourages a system wide tendency towards lexicon classes aka ubiquitous language.
      Sticking to classes and contracts with data layer equivalents establishes a lexicon for your application.  Developers, external teams, and even product can share the same vocabulary and avoid misunderstanding or wasted time due to ambiguity of terms.  App developers will be learning the data layer while they work and data engineers can gain a strong sense of what the application is doing without ever touching the code.

      Further Consideration

      https://www.martinfowler.com/bliki/AnemicDomainModel.html
      https://en.wikipedia.org/wiki/Anemic_domain_model

      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 market, somet
      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 over time."  Th
      Read more