"自分が仕事の上で学んだことや，ぶつかった問題について，私自身のためにも，他の人たちのためにも記録しておきたいのです。" スエーデンで.NETプラットフォームのWeb開発を手掛けるAndras Nemes氏は，ブログ記事を書く理由についてこう説明する。氏はSOLID設計原則について，さらにはオブジェクト指向プログラミングと設計を通じて興味を持った他のデザインパターンについて，ブログ記事をシリーズで書き続けている。
氏はSOLID設計原則を，オブジェクト指向ソフトウェア設計に関わるガイドラインの集合だと説明する。そのひとつひとつが，理解しやすくメンテナンスの容易なコードベースのための有用なガイドラインであると同時に，オブジェクト指向スタイルを促進するという効果もある。相互依存性が高まってコードベースが複雑化し，デバッグや拡張が困難になるような事態を防止するのだ。
ただし，それらの原則がいかに優れたツールセットであろうとも，コードの陳腐化を防ぐためのメンテナンスやリファクタリングといった作業に取って代わるものではない，という指摘も忘れてはいない。
SOLIDとは５つの設計原則の頭字語である。氏の簡潔な説明を借りれば：
- 単一責務の原則(Single Responsibility Principle) すべてのオブジェクトは唯一の責務を持たなければならない。すなわち，実行することはただひとつでなければならない。
- 開放/閉鎖の原則(Open-Closed Principle) クラスは拡張に対しては開いて(Open)，修正に対しては閉じて(Close)いなければならない。
- Liskovの置換原則(Liskov Substitution Principle) 派生クラスは親クラスの置換として使用可能でなければならない。なおかつ，同じ振る舞いをしなければならない。
- インターフェイス分離の原則(Interface Segregation Principle) 使用しないインターフェースへの依存をクライアントに強制してはならない。
- 依存関係逆転の原則(Dependency Inversion Principle) 具体的な実装よりも抽象に依存するべきである。これはコードの分離に有効だ。
それぞれの原則について氏は，それをいつ，どのような場面で使うべきかというパターンを説明する。次にそのパターンを使って，最初はパターンを使用せずに実装し，リファクタリングでパターンを適用してコードを改善する，というデモを行う。さらには，最初の設計のどこが問題だったのか，リファクタリングによってどのように設計が改善されたのか，という話題にも言及する。
SOLID原則以外にCommandやBuiler, Visitor, Bridge, Observerなどいくつかのパターンについても，これと同じ方法で説明している。