This article explains the difference between dynamic dispatch (late binding) and static dispatch (early binding). We'll also touch on the differences in language support for virtual and static methods, and how virtual methods can be circumvented.
I'm currently refactoring a huge method into smaller parts. It is stock full of nested loops, maintains a complex state machine with more variables than I have fingers, and is the kind of code where I have to ask myself how I could ever think this would have been a good idea. So obviously, I'm splitting that function into smaller, independent chunks with the Extract Method refactoring technique.1 Since the control flow is now simplified, the code has also become easier to test – as long as I'm comfortable with testing private methods. Why?
The number of test cases needed for full path coverage corresponds directly to the McCabe complexity of the code under test. Since many simple functions often have lower total complexity than one convoluted function, the overall required testing effort is reduced. As this reduction can be substantial, there is a strong incentive to test the extracted methods directly, instead of testing only through the public interface.
What is reasonable code? In an article on The Whiteboard, a fellow software developer under the pen name “Jimmy Hoffa” thinks about reasonability as a measure of code quality. He arrives at six exemplary properties of reasonable code:
He makes a good case for continuous self-improvement and a focus on code quality in our development process. It is well worth the read, especially for beginning professionals. And not quite by chance, it seems to be a subtle advertisement for functional programming and static typing: anything else would have a hard time meeting his characteristics of reasonable code.
A few days ago, I was trying to split a data set into various files according to their type, but it was terribly slow. I saved an hour by taking a step back and thinking about my algorithms. Because algorithms matter. But not terribly much.
Global dependencies make it difficult to properly test a piece of code. By extracting all dependencies into a single manageable object, we can easily mock the necessary services and avoid a large-scale refactor.