Some Amazon Reviews
'If you have 7+ years of java development dont buy it... Most of what he has said took me some time to work out for myself' - Clean Code
'A lot of common sense and stuff a seasoned programmer probably already know' - Clean Code
'What little it does say has been said several times before' - Pragmatic Programmer
I have also found this to be the case, however I do not necessarily consider that this detracts from the work. Having been programming for several years you tend to pickup common patterns, smells and designs, they tend to 'fall out' of the code and into use over time. Implicitly forming in your monkey brain, however there is a risk that they may become malformed in their formation in isolation from wider discussion. There is a danger of developing bad habits and you know what they say about old dogs, never mind old programmers.
'The limits of my language means the limits of my world' - Wittgenstein
Covering these topics can serve to cement your understanding and formalise definitions of concepts or patterns of which perhaps you have already have grasped by a thread, but have not fully unwound in a deeper analysis. Indeed, formalisation is an important process, having a common language and nomenclature is an important prerequisite for effective discussion and deeper analysis. Also many of the most important truths that merit discussion are self-evident ones, like tests are good and duplication is bad.
The Bit In Which I Try and Justify The Slightly Erotic Title
Cohesion and coupling are two such concepts, I have found that a good understanding of these topics, alongside their conscious application can help you to write more extensible and maintainable software. Since we spend the vast majority of our time maintaining rather than creating, optimising for maintenance can save you a lot of hassle down the line.
Coupling
In the Pragmatic Programmer, a helicopter's controls is used as an example of a tightly coupled system, indeed helicopters are considered considerably more difficult to fly than aeroplanes as constant action is required to keep them in the air, left to their own devices, they will, quickly plummet, sound like any software systems you know? Every control creates a side effect that requires the application of another control in order to resolve and so using the second control requires more corrections and so on, ad infinitum.'I never liked riding in helicopters because there's a fair probability that the bottom part will get going around as fast as the top part' - Lt. Col. John Wittenborn, USAFR
Coupling is frequently expressed in terms of orthogonality, a term derived from mathematics, but essentially a grown up synonym for de-coupled, you too can use this term to befuddle new developers.
Working with a non-orthogonal (tightly coupled) system, any change can lead to a host of side effects, reducing confidence in your ability to make changes, this can result in inertia and paralysis, as you do not fully comprehend the full effects of potential changes. This is exacerbated by the fact that such a system is likely not well tested. This is because the coupling is tight, and prohibitively so, rendering isolation of components for unit testing difficult. The resultant dirth in test coverage further contributes to a deeper, more pungent rot. Maintaining such a system is akin to some some sort of feverish festive nightmare in which you are trapped in an eternal game of jenga, but you are alarmed to discover that your hands have turned into claws.
'Talk to friends not strangers' - Clean Coder
Orthogonality is often also expressed in reference to the 'Law of Demeter', which outlines design guidelines useful for designing a non-orthogonal system:
- Each unit should have only limited knowledge about other units: only units "closely" related to the current unit.
- Each unit should only talk to its friends; don't talk to strangers.
- Only talk to your immediate friends.
Something most developers have at least some understanding of are train wrecks, in addition to being generally bad practice, the presence of train wrecks, are frequently a sign of a breach of the law of demeter. Train wrecks are long chained calls, symptomatic of overly friendly objects, that have no respect for each other and are privy to each others dirty implementation details.
To borrow an example from Clean Coder:
final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath()
Again, experienced developers will have certainly encountered this 'code smell', and will likely have realised that it is a rotten one. Now, this example may benefit from being broken into several lines, but our code here should certainly not have intimate knowledge of the implementation of scratchDir. Suppose this code is run on a test system that does not have access to the production file structure, our code is tightly coupled to the implementation of scratchDir and any change to the interface of scratchDir will necessitate changes here and to the multitude of other distantly related callers.
The Model, View, Controller (MVC) design pattern is a well known method for increasing maintainability via decoupling and the breaking out of responsibilites.
Christmas Trees
Imagine if you never threw away a christmas decoration, if instead you hung them all on your christmas tree, you featured on one of those Hoarders TV shows on Channel 5, it's the christmas special. So you kept all the crappy decorations made out of tissue paper that you made in primary school and the top of your tree shared angelic congestion issues the envy of heaven. Under the layer upon layer of decaying tinsel, the poor old tree strains under the additional weight of your magpie like compulsion.You may have had the displeasure of encountering an object or class that bears a resemblance to such a tree, one where every bauble of information is pinned onto this object, until it begins to creak and strain under the complexity. Every time you receive a request to add extra functionality in this area, you groan, hold your breath, do it, wince, stack the technical debt higher, defer the refactor and try really hard to forget.
The Single Responsibility Principle
It is likely that such an overburdened class has many responsibilities and is in violation of SRP (Single Responsibility Principle), this states that a class should only have one responsibility and thus generally only one reason to change, this rule helps us keep class size reasonable. So, our class should have one over-arching high level responsibility but complex logic should be embodied in sub classes composed upon or utilised in conjunction to our class. The SRP helps us reason in terms of the language agnostic concept of responsibilities in contrast to line count. This deserves its own post.
Low Cohesion and its Effects
The presence of tight coupling and low cohesion are usually a good indicator of the benefits of a refactor and represent technical debt, but the subject of refactoring also deserves its own post! For now let's try and define cohesion. Cohesion is a measure of how well an object hangs together as a logical whole. In our christmas tree example we note that the parts bare little relevance to each other, colours and styles clashing garishly. Technically, cohesion is defined as being inversely proportional to the number of instance variables and methods a class has. A class having methods that only utilise a small subset of its variables is said to have low cohesion, a class where each variable is used by every method is said to be maximally cohesive. Note that maximum cohesion is rarely a goal, but low cohesion undesirable.
Similarly to a tightly coupled class, in an uncohesive class it is often difficult to make changes with confidence, fully aware of the knock on effects and to have comprehensive tests. The difficulty in testing is apparent if you following a thought exercise.
Take an uncohesive class, replace a class method with a function call in which each class variable is an argument and the return value is a composite value of all class attributes and the method return value. Now attempt to write exhaustive unit tests for this function over the range of possible inputs and outputs, hard, eh? We can see that the potential for side effects of such methods are large and testing is a combinatoric disaster. In addition, it is likely impossible to keep a full understanding of such a class in your head, thus we can see how low cohesion is detrimental to effective maintenance and extensibility.
Bit of a rambling one, but food for thought, links into some other topics I'd like to discuss. Anwyay, I hope that this can help you to write more maintainable and extensible code, or at the least provoke thought and discussion that does so.
Until next time
No comments:
Post a Comment