The Odd Couple (Anti-pattern)

If you haven't heard about the Unification Church (aka The Moonys) you may be surprised to hear about their mass weddings.  They'll fill a stadium with perfect strangers and in one stroke marry the lot of 'em.

Considering the divorce rate for romantic marriages (~50% in the US), I shouldn't criticize.  It's just an unexpected way of approaching matchmaking.  I'd be really interested to learn about the success rate of these marriages.  After all traditional, arranged marriages work out more often than romantic ones, boasting a divorce rate of only ~4%.

In coding, I sometimes come across another kind of unlikely pairing.  I thought it an obvious anti-pattern but as we'll see there are tools in some languages that make it all too easy a choice.

For those of you who've spent some time with C++ "passing by reference" will be familiar.  C++ allows you to do cool stuff like:

Pass by Copy
int doSomething(int y)
A separate copy of y made for use in doSomething

Pass by Reference
int doSomething(int &y)
y may be altered directly in doSomething and the caller can see the result

Pass by Constant Reference
int doSomething(const int &y)

The memory space of the caller's y is accessed directly within doSomething but may not be changed.  This allows the caller to save the space in memory by eschewing the copy operation

C# shares a similar concept with the 'out' keyword.

One of the most uncomfortable things about moving from C++ to Java was only being able to return one value.  With practice though, the intent and genius of this subtle difference occurred to me and improved the quality of my code.  It increases the cost of coupling, making the right decision just  appealing enough that you'll probably pick it.

When the developer can return multiple values there's a tendency to couple independent logic in a single method.  Particularly when you're under the gun, it's tempting to throw together an unlikely pair.  The balance between speed and accuracy is ever present and all too often speed wins, producing tech debt.


------------------------------------------------------------------------------------

public class OddCouple {
   private boolean bald;
   private Money averageNFLSalary2017;

   public OddCouple(boolean bald, Money salary) {
      this.bald = bald;
      this.averageNFLSalary = salary;
   }

   ...

}

...

pubic OddCouple matchEm(int year, double geneScore) {
   Money salary = new Money($1,000,000);
   boolean bald = false;

   if (year == 2017) {
          salary = new Money($1,250,000);
   } else if (year < 1975) {
      if (geneScore % MAGIC_NUMBER == 0) {
         bald = true;
      } else {
        bald = false;
      }
   } else {
      if (geneScore % MAGIC_NUMBER == 1) {
         bald = true;
      } else {
         bald = false;
      }
   }

   return new OddCouple(bald, salary);
}
------------------------------------------------------------------------------------

Obviously, this is a contrived example but you'd be surprised what you find out there.  Mixing unrelated logic is NOT two birds with one stone.  It's "先送り" meaning procrastination (where someone else likely pays the price).


Despite what's been said above, it's of course okay to return a complex object from a method.  However, if the object is a Nonce or contains unrelated members or methods, you may have an Odd Couple.