Levels of use

By Tony Marston

1st December 2017

Introduction
Levels of use
Examples

Introduction

In this article I am going to concentrate on the different levels of the word "use", when utilised in such phrases as "should use" or "should not use", in order to show how not understanding the correct level can lead to confusion and the wrong use of a practice or principle. When somebody says "You should not use X when ..." it later gets converted into "you should not use X". This means that the "when" has now been translated into "always". People who then repeat this statement do not realise that they are making a mistake, that they are acting as an echo chamber for a wrong idea.

Levels of use

When someone says "I am using X" they could be employing "X" at one of the following levels:

  1. Use: - this is where a principle or practice is used in the circumstances for which it was designed, when appropriate conditions or circumstances have been met, or where there are no viable alternatives.
  2. Over-use: this is when someone does not have the brain capacity to work out what "when appropriate" means, or they cannot recognise the relevant conditions or circumstances, so they use that principle or practice outside of the circumstances for which it was designed.
  3. Mis-use: - this is where a principle or practice is utilised in entirely the wrong circumstances, or with an implementation which is completely wrong.
  4. Ab-use: - this is a combination of levels #2 and #3. It results in a combination of principles being used in entirely the wrong circumstances and with questionable implementations. The developer cannot understand that employing the wrong principles in the wrong way results in wrong code, where "wrong" in this context means more complicated than it should be, difficult to read, difficult to follow, and therefore difficult to maintain. All he can say in his defence is "I have implemented that principle, so how can it be wrong?"

Examples

A typical example is where an inexperienced developer implements too many design patterns just because "design patterns are good", so he thinks "the more the merrier". Too many design patterns result in a large number of small classes with small methods, which has the effect of producing a system which is too fragmented and which demonstrates low cohesion. Trying to follow a code path through 100 objects is far more difficult then when dealing with a dozen.

Another example is the over-use of the Dependency Inversion Principle (DIP). If you look at what Robert C. Martin, the author of this principle, originally wrote at The Dependency Inversion Principle (PDF) you will see that he provides an example in a "Copy" program which explains the circumstances in which the application of this principle would be of benefit. Yet far too many people seem to think that this principle must be applied in all circumstances instead of appropriate circumstances. My arguments against this stupidity are given in Dependency Injection is EVIL.


© Tony Marston
1st December 2017

http://www.tonymarston.net
http://www.radicore.org

counter