Thursday’s “Ignite Your Coding” Webcast: “Composable Applications FTW” with Glenn Block

Ignite Your CodingThis Thursday, my fellow Developer Evangelist John Bristowe and I will host another live Ignite Your Coding webcast, where we’ll interview another high-profile software developer and pass along some of your questions.

This week’s guest is Glenn Block, a Program Manager for .NET FX at Microsoft. Glenn’s one of the go-to guys on Prism, Unity, MEF and ways of building maintainable and reconfigurable applications out of pieces that you can assemble and rearrange in general. We’ll talk with him about building composite applications, design patterns, the “alphabet soup” of SOLID, DI and IoC and whatever questions you ask him.

blocks.png(We don’t have a photo of Glenn Block, but we do have the image to the right, which is the symbol for MEF – that’s Managed Extensibility Framework – which is one of Glenn’s projects. It’s a lucky coincidence that Glenn’s last name is also featured prominently in the image.)

If You Want to Catch the Live Webcast on Thursday and/or Ask Glenn Questions…

You’ll need:

If You Want to Listen to a Recording of the Webcast Later…

We’ll make it available in MP3 format soon. Watch this site for details!

What’s Ignite Your Coding All About, Anyway?

It’s all about helping you, the software developer, find ways to stay on top of the technological, economic and social changes that affect you and your work every day. We got our hands on some of the biggest thinkers and doers in our field and asked them if they’d like to chat about the industry, how they got started, where they see the opportunities are, how they deal with change and how to be generally awesome. We got some big names from the Microsoft/.NET world, but we also went farther afield and got some people from beyond that world as well, because a different perspective is often helpful.

This article also appears in Canadian Developer Connection.


DimeCast.Net’s SOLID Screencasts

This article also appears in Canadian Developer Connection.

Brick with the word "SOLID" beneath it

Following up on the previous article about the SOLID principles for object-oriented design, Steve Bohlen pointed me to a series of screencasts on covering each SOLID principle:

The screencasts are each about 12 minutes long, a perfect length for a “learning snack”.


The SOLID Principles, Explained with Motivational Posters

This article also appears in Canadian Developer Connection.

SOLID Seems to be Everywhere These Days


Robert C. “Uncle Bob” Martin first gathered the object-oriented design principles that would eventually go under the acronym SOLID almost fifteen years ago, but the SOLID principles have been making the rounds lately.

Before I talk about the SOLID principles, let me show you where the concept has been popping up in the past few months…

SOLID at Conferences

At the Microsoft TechEd conference in May, Steve Smith gave a presentation on applying the SOLID principles to developing applications with the ASP.NET MVC framework. At around the same time, the GeeCon conference in Krakow, Poland had a couple of presentations on SOLID: Bruno Bossola gave a talk on the SOLID principles and  Lee Brandt gave a talk on spotting SOLID code “in the wild”.

SOLID at User Groups

A number of user groups have had recently presentations on SOLID, such as:

Stack Overflow on SOLID

SOLID was the topic of a recent argument that took place over a series of podcasts earlier this year:

SOLID in Blogs

SOLID has also been spotted in a number of blogs:

Will There be a Presentation on SOLID at TechDays Canada 2009?


And Now, The Principles and Posters

The folks at have created a series of Creative Commons-licenced posters that illustrate the SOLID principles. I took the posters, cleaned up the typography a little and posted them below under the same Creative Commons licence. Below each poster is an explanation of the corresponding SOLID principle. Enjoy!

Single Responsibility Principle


The “S” in SOLID is for Single Responsibility Principle, which states that every object should have a single responsibility and that all of its services should be aligned with that responsibility. “Responsibility” is defined as “a reason to change”, and Wikipedia does a pretty good job of explaining it:

As an example, consider a module that compiles and prints a report. Such a module can be changed for two reasons. First, the content of the report can change. Second, the format of the report can change. These two things change for very different causes; one substantive, and one cosmetic. The single responsibility principle says that these two aspects of the problem are really two separate responsibilities, and should therefore be in separate classes or modules. It would be a bad design to couple two things that change for different reasons at different times.

Open-Closed Principle


The “O” in SOLID is for Open-Closed Principle, which states that software entities – such as classes, modules, functions and so on – should be open for extension but closed for modification. The idea is that it’s often better to make changes to things like classes by adding to or building on top of them (using mechanisms like subclassing or polymorphism) rather than modifying their code.

Liskov Substitution Principle


The “L” in SOLID is for Liskov Substitution Principle, which states that subclases should be substitutable for the classes from which they were derived. For example, if MySubclass is a subclass of MyClass, you should be able to replace MyClass with MySubclass without bunging up the program.

Interface Segregation Principle


The “I” in SOLID is for Interface Segregation Principle, which states that clients should not be forced to depend on methods they don’t use. If a class exposes so many members that those members can be broken down into groups that serve different clients that don’t use members from the other groups, you should think about exposing those member groups as separate interfaces.


The “D” in SOLID is for Dependency Inversion Principle, which states that high-level modules shouldn’t depend on low-level modules, but both should depend on shared abstractions. In addition, abstractions should not depend on details – instead, details should depend on abstractions.

Bonus Reading Material on SOLID

In addition to the posters, they’ve also produced a book covering the SOLID principles in detail. Go and download Pablo’’s Solid Software Development [1.4 MB PDF] now!