Title: Rise of the Machines

Author: Martin Moene

Date: 01 February 2011 20:36:31 +00:00 or Tue, 01 February 2011 20:36:31 +00:00

Summary: Sometimes the world really is out to get you. Kevlin Henney identifies some culprits.

Body: 

In the space of a few syllables, the word resistentialism is packed with humour, rhythm, profound insight, philosophy, multilingual wordplay and astute commentary on much irksome code. Formed from res (the Latin for thing), resistance and existentialism, what exactly does it mean? And what does it have to do with code?

In a nutshell, it’s about objects. Especially the ones that seem to thwart our efforts and intentions:

• The stateful and pervasive singleton object that increases the stealth coupling of a system.

  Complicated unit tests, reduced thread safety and tsunami rebuilds are just a few of the symptoms. Although undoubtedly introduced with the best of intentions – along with the multitude of other singletons in your application clamouring for your attention, initialisation and coordination – most singletons are short cuts and band-aids (and band-aids for short cuts, and band-aids for band-aids for...) that nurture a sense of resistentialism.

• Uncohesive objects suffering from scope creep and over-education.

  They seem to know too much and do too much, greedily pulling in as many responsibilities and dependencies as they can. For example, value objects that also have service-like behaviour accessing an external such as the file system, a database or the network. Or classes that amass statics as well as instance-specific members, so there is an implied and missing object responsibility, such as an aggregating concept that collects or manages instances of the class. Sleepwalking into a state of resistentialism, one feature at a time.

• Anaemic objects, strangely free of any useful behaviour: constructors that result in meaningless and yet-not-usable objects; methods that fail to encapsulate common usage or reflect the actions and queries of the domain; a type vocabulary that barely drags its knuckles above strings, integers and collections. What you get instead is a public method interface that is little more than a pass-through for the private fields – for every field a get, for every get a set. You cannot understand the system by looking at these objects – they offer little more than object-oriented assembler. Although trivial (even pointless) to test, they are incomplete and free of meaning. Their behaviour is displaced and scattered around the codebase, often holed up in large procedural or controller classes, too difficult to test or to change with any confidence or comfort. Resistentialism is the proclaimed and upheld belief system of the code and those who work on it.

Perhaps the best thing about resistentialism is that you now have a blame-free philosophical framework whose name you can call on in times of code distress. And in those times of need you also have a word you can use in polite company. Of course, in a well-crafted system, resistentialism is futile.

References

[AWordADay] A Word a Dayhttp://wordsmith.org/words/resistentialism.html

[Wikipedia] http://en.wikipedia.org/wiki/Resistentialism

[WordSpy] Word Spy http://www.wordspy.com/words/resistentialism.asp

Notes: 

More fields may be available via dynamicdata ..