Anti-pattern: Silk-pursing

“You can’t turn a pig’s ear into a silk purse.”

“It’s not a global, it’s a singleton!”

Description:

An “acceptable” design pattern is placed on top of a concept that is generally avoided

Symptoms:

  • Problems associated with a known poor development practice start cropping up. 
  • Problem areas are defended by spouting off the name of the design pattern that they superficially resemble.
  • Patterns are used when the problem that the pattern solves is not demonstrated, but for tangental reasons.

Examples:

The most common form of silk-pursing is singletonitis.  Too often, globals are wrapped up in singletons, because that somehow makes them “okay.”  Inappropriate use of Service Providers seems to be the next version of singletonitis, in that it is often used to propagate globals rather than the actual purposes (extensibility, etc.)

Usage of try/catch/finally to simulate goto is another example.

Silk-pursing is related to cargo-cult-programming.  In both cases, a useful pattern is used inappropriately.  In cargo-cult-programming usually involves adding patterns/structures/algorithms/etc. for no apparent reason whatsoever.  Silk-pursing is different in that the pattern being abused is applied solely for the purpose of hiding a practice that is frowned upon.

Silk-pursing may seem like gold-plating, but it is different.  Gold-plating involves putting extra, unnecessary features into code.  Silk-pursing simply hides poor development practices.

Silk-pursing may or may not be a deliberate attempt to conceal.  In many cases, developers will actively believe that because they are using something they’ve heard is a beneficial practice, that what they are doing is actually better.

Fixing:

Treat the code as if it were the underlying development practice - treat silk-purse singletons as globals, etc.

Educate developers on the purpose of the design patterns that are being abused.

Educate developers on the fact that concealing a bad practice doesn’t make it any better.

Educate developers on ways to design code that doesn’t involve using the poor practice.