Learning

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.

The last post rounded off the contribution to the discussion around the problems of designing software. A new chapter means a new topic, and chapter 6, titled "Working Classes", deals with tips on, and the issues around, creating classes in your program. First up is the topic of Abstract Data Types: what they are, why you should be interested, and how you should use them.

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.

Ok, so this is my first post on Code Complete for a little while; it turned out the busy period at work lasted a good couple of weeks longer than I thought it would! It was a quite a while back that I made these notes (mid-June, in fact), so if the post seems less coherent or I've got something obviously wrong, please leave a comment. Here be dragons.

This post deals with design heuristics. We've already touched on what heuristics are in the Software Development Metaphors post, so you might want to refresh your understanding before reading on. Inside, I will cover McConnell's description and critical evaluation of the most common design heuristics. These can be viewed as smaller steps in a larger process, or as individual methods to use at different stages of the design process.

Note: this is a long post!

Chocolate Heuristics: Copyright © 2006 maadmob

Design is essentially an exercise in managing complexity, and it is incredibly important to manage correctly. Dijkstra (1989) stated that a single person working on a software development project needs to grapple with anything from one bit to a few hundred megabytes: this is 9 orders of magnitude. Given that software is always increasing in complexity, McConnell posits that this figure could be as much as 15 orders of magnitude or more today.

This post covers in some depth the issues around managing complexity, ways to attach it, and the importance of doing so. It will also cover desirable characteristics of design, and the different levels of design.

Note: this is a long post!

This is a relatively short post, covering the key construction decisions Steve McConnell highlights in his book Code Complete.