Resistentialism

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. So what does resistentialism mean? And what does it have to do with code?

• "Resistentialism is a jocular theory in which inanimate objects display hostile desires towards human beings."
  Wikipedia
  


• "The theory that inanimate objects demonstrate hostile behavior toward us."
  A Word A Day
  


• "The belief that inanimate objects have a natural antipathy toward human beings, and therefore it is not people who control things, but things which increasingly control people."
  Word Spy
  

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) that nurture a sense of resistentialism.
  


• Uncohesive objects suffering from scope creep and overeducation. They seem to know 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 - no validating constructors and no methods that encapsulate common usage or reflect the actions and queries of the domain. 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.