Larman says (p. 22) that as the system goes through more iterations it converges “towards final requirements and design” and draws a wavy graph with the size of the waves diminishing with time. My experience seems to disagree with that. As long as the system is “alive” there is no such thing as ‘final requirements’: new features and requests are invented all the time. Occasionally they are just incremental, but frequently they change significant portions of existing functionality.

I bought Larman’s “Applying UML and Patterns” about a month ago, but had hard time getting to actually read it. This is my first note for a long time – I hope there will be more to follow.

He is promoting the [Rational] Unified Process (UP), but he is quite good in avoiding holy wars. He says (p. 18-19) that the UP is only an example, and you need to use some process to illustrate the techniques. Also, he says that the UP “combines commonly accepted best practices” and that the author “encourages clients to understand and adopt a blend of useful techniques from several methods, rather than a dogmatic ‘my method is better than your method’ mentality”.

This may be just a way to sweet talk opponents and play down the disagreements, but I do like it.

C# coding style conventions

I like how the main body of the book is divided into 9 chapters, and Chapter 9 is followed by Chapter A. Some would consider it an appendix, others – a sequential hexadecimal numbering. Pretty neat.

As for the coding conventions, they don’t match my coding conventions, and therefore of course I don’t like them. I support or at least don’t mind most of the conventions specified, but there are some I specifically don’t accept. For starters, the curly braces are put like in Java:

[read more...]

Common Design Patterns

A number of “design patterns” are described in this section. I put the words “design patterns” in quotation marks, because the patterns are not described in a standard manner established by the GoF book.
[read more...]

This is part three of the series.

Type Design (continued…)

p 89: Struct design: DO ensure that a state where all instance data is set to zero … is valid. This sounds reasonable, until they give an example. They consider a structure

[read more...]

This is a second portion of my comments on the “Framework Design Guidelines” book. See also Part I. This post is devoted to the following recommendation we find on page 81 of the book:

DO favor defining (abstract) classes over interfaces

This is an often quoted guideline, that can be found in MSDN and elsewhere. It is probably the most controversial guideline in the book, especially given its near-mandatory strength (“DO”) as opposed to more lenient “CONSIDER”. The book itself contains descending opinions ranging from “I agree in general, but…” (Jeffrey Richter) to “you can see interfaces coming back” (Chris Anderson).

The author demonstrates this guideline on an example of the Stream class. “The System.IO.Stream abstract class shipped in version 1.0 of the framework without any support of timing out pending I/O operations. In version 2.0, several members were added to
Stream to allow subclasses to support timeout-related operations.”

public abstract class Stream
{
    public virtual bool CanTimeout { get { return false; } }

    public virtual int ReadTimeout
        { get { throw new NotSupportedException(); } }
        { set { throw new NotSupportedException(); } }
}

It’s been a long time – New Year, small vacation, etc…

Getting back to the blog. By the recommendation of my colleagues I took the Framework
Design Guidelines book in the library. This is an interesting book. Unlike some other books where “evangelists” throw at you empty slogans about things they hardly understand, the guys that wrote this book seem to know very well what they are talking about. Even if you don’t agree with everything they say, the book provides an insight into the philosophy behind the .NET framework. [read more...]