Self Improvement

So this afternoon I've been attempting the first of The Pragmatic Programmers' kata. This is a modelling-only exercise, designed to get you thinking around a problem. You'll need to be familiar with the kata in order to get the most out of this post, so I'll go get a cup of tea whilst you go read up on it.

Anyone who has ever learnt a musical instrument will tell you of the pain of learning scales and arpeggios. Those that stuck with their instrument will tell you that these are the constructs around which all music is based, defining which notes sound right or good within a given key. The most common keys in classical music are grouped into major ("happy") and minor ("sad"); other musical forms have other scales, such as modes and blues.

This second and final post on high-quality routines will cover good routine names and guidelines for parameter usage, as well as touching on routine length and special considerations for functions vs procedures.

Last time, I rounded off the series-within-a-series on class design and usage, Working Classes. The next topic for dissection is routine design, creation and usage, and this topic will be handled over two posts. This post will form a bit of an introduction and cover design considerations for high-quality routines through the classification of different kinds of routine cohesion. So, without further ado, let's get cracking!

This fourth and final post in the mini-series on Working Classes covers the reasons to create a class. These reasons are many and varied, but fall quite neatly into a number of groups. These groups are: modelling concepts, managing complexity, hiding information, building for the future, and classes to avoid. This post should be rather shorter than the recent ones, and hopefully more digestible as a result.

I'm also experimenting with a new method of writing up my notes that I hope will make this post more coherent; I feel that some of my recent posts in the Code Complete series have been almost a sequence of short paragraphs and possibly haven't hung together too well. I'm interested to know whether you think this post is an improvement, dear reader.

There are a number of design and implementation issues to consider when working with classes, not least dealing with inheritance. This third post in the series of four on "Working Classes" covers my take on Steve McConnell's thoughts on containment, inheritance, member functions and data, and constructors.

This post represents the second instalment taken from chapter 6 of Code Complete, entitled "Working Classes". This post covers the issues to consider when designing class interfaces, illustrated with code samples. An important piece of information to keep in mind when reading this post is that McConnell is talking in terms of the public interface exposed by a class through its public members. While an interface (as defined in Java or C#) also fits this bill, some of the advice given here is specific to the idea of a class interface, and not a standalone interface.

If you're after the executive summary (this is quite a long post, after all), there are only two things you must build into your class interfaces: good abstraction and good encapsulation. Read on to find out more.

Another day, another Code Complete blog post. I might even clear two today, looking at the number of notes I have for this one.

Wow, it's been quite a while since I updated my Code Complete series, and I've got quite the backlog to wade through now! Looking at the last save date on this post, it's been sat around for three months waiting to be written, so I'm sorry for being so slack, and I'll get on with writing it now...

This post covers some key design practices, and is the last post on Chapter 5, Design in Construction.

On Wednesday 28 October 2009, Joel Spolsky and Jeff Atwood brought their Stack Overflow sideshow to London's Kensington Town Hall, and I was lucky enough to be one of the ~1000 people attending.