My education as a programmer recently took another unexpected turn as quite by accident I discovered the difference between types and classes. Whilst I was aware there was a difference I had never felt that my skills as a programmer were sufficiently impaired to feel the need to go out and discover the answer proactively.
This serendipitous moment came by way of a link in a tweet to a StackOverflow question written way back in 2012. It involved a comment made by James Coplien about the book Design Patterns and asked “Are there any patterns in GoF?” [SO]. The accepted answer, which finally came some 18 months later from James Coplien himself, caused me to go back and read the “Introduction” chapter of the seminal Design Patterns book [GoF]. When I reached Section 1.6, “How Design Patterns Solve Design Problems”, I found the difference between class and type described clear as day under the subsection “Class versus Interface Inheritance”:
“It’s important to understand the difference between an object’s class and its type…The class defines the object’s internal state and the implementation of its operations. In contrast, an object’s type only refers to its interface…”
It turns out Section 1.6, which is only 16 pages long, is an absolute goldmine of information on the object-orientated (OO) paradigm, containing such gems as the sections: Programming to an Interface, not an Implementation, Inheritance versus Composition, Delegation, Inheritance versus Parameterized Types and Designing for Change.
In some respects I find this sudden gain in clarity a little disturbing because I know I read that section for (at least) a second time, as I always read my books from cover-to-cover (eventually). So why did I not remember this particular nugget within the book, even if it was 20 years ago, as I do so many other gems in other books? For example, the discussion of noumena and phenomena and the essence of objects in the weighty tome on OLE by Kraig Brockschmidt [KB] is far more tenuous, and yet apparently far more memorable.
I think Emyr Williams probably hit the spot in his recent “Becoming a Better Programmer” blog post “Concepts Not Syntax” [EW]. At the start of your professional programming career you just don’t have the capacity to take in everything that you consume, especially when you’re being paid to write code. And unless you come from a Computer Science background in the first place you need to make a choice about what you focus on. I now realise I unconsciously chose to focus on learning the technology –platforms and programming languages – which means I’m now paying catch up to understand what it all means.
This isn’t the first time either. My career is littered with examples of where I finally really managed to grok something just as it goes out of fashion, e.g. COM, batch files, etc. With functional programming grabbing the headlines and object-orientation being given its last rites it’s somewhat apt that now is the time I start to discover what I probably should have known 20 years ago.
Irrespective of whether James Coplien is right or not on whether they are really idioms, and not patterns as Alexander intended, the book still contains some thoroughly useful knowledge about learning the principles behind OO.
[EW] http://becomingbetterdotnet.wordpress.com/2014/04/26/concepts-not-syntax/
[GoF] Design Patterns: Elements of Reusable Object-Orientated Software – Gamma, Helm, Johnson & Vlissides
[KB] Inside OLE – Kraig Brockschmidt
[SO] http://stackoverflow.com/questions/12981021/are-there-any-patterns-in-gof
13 August 2014
Bio
Chris is a freelance developer who started out as a bedroom coder in the 80’s writing assembler on 8-bit micros; these days it’s C++ and C#. He also commentates on the Godmanchester duck race and can be contacted via gort@cix.co.uk or @chrisoldwood.