トップへ

正誤表はこちら。

.NET のクラスライブラリ開発チームが使用しているガイドラインを詳細に解説し、またそれに対するさまざまな意見（注釈）を載せた『Framework Design Guidelines』の和訳になります。ライブラリを使いこなしたい方、オブジェクト指向のライブラリを作成する機会のある方などにお勧めします。

ご質問、ご意見、ご感想等ありましたら、以下のいずれかでどうぞ。

また、論評や感想などをブログ等に掲載された方は、ご一報いただけると助かります。さまざまな意見のご紹介として、掲載していきたいと考えています。

関連リンク集

公式

感想・論評など

論評や感想などをブログ等に掲載された方は、メールいただければ幸いです（yfakariya{_at_}gmail.com）。
ガイドラインをより深く理解し、上手に採用していくには賛否両論の議論が不可欠です！

補足

別に私が書き下ろしたものではありませんので、あくまで読み込んだ読者の見解として受け取っていただければ……

どこまでガイドラインを守るべきか

「ガイドライン」というと、絶対守らなければならない戒律のように掲げる方もいらっしゃいますが、 本書では、「DO/DO NET」と「SHOULD/AVOID」で明確にその準拠度合いを分けています。

基本的には、以下のスタンスでとらえるのが良いのではないかと考えています。

「知らないから守らない」のと「理由があって守らない」では全然違うことですよね。

MSDN のガイドラインとどこが違うのか

大まかな内容は同じです。原著の内容を元にして、MSDN の「クラス ライブラリ開発のデザイン ガイドライン」が記述されているためです。

違いとしては以下のようなものになります。

一部コードに VB が混ざっている件

付録 C に合わせるために、原著でもわざとそうなっていましたので揃えました。

Interlocked が列挙体で使えない件

Jeffrey Ritcher のコメントですね。本当はサンプルコードを出そうと思ったのですが、「長い」と編集のさんからダメだしを食らったので（笑）、ここに書きます。

enum SampleEnum : long
{
    ...
}

class Foo
{
    private long m_rawSampleEnum;

    public SampleEnum SampleEnum
    {
        get { return (SampleEnum)Interlocked.Read(ref m_rawSampleEnum); }
        set { Interlocked.Exchange(ref m_rawSampleEnum, (long)value); }
    }
}

ポイントは 2 つです。

  1. 列挙体の基になる型を使用していること。
    結局、Interlocked はプリミティブ型と参照型（これはスタックメモリ上の値としてはポインタサイズになります）のみをサポートします。
    なので、基になる型としてフィールドに持つことになります。
  2. 列挙体の基になる型が int でも uint でもないこと。
    .NET Framework は 32 bit か 64 bit で動作します（Mono についてはわかりませんが、だいたい 32 bit と 64 bit だと思います）。
    32 bit の値の読み書きは原子的（アトミック）なので、そもそも排他制御が必要ありません。
    （ただし、キャッシュメモリの整合性を確保するため、フィールドを volatile にする必要はあります。もちろん、パフォーマンスをそれほど気にしないのであれば、Interlocked を使用してもかまいません）。
    short などの場合は、32 bit として操作されると思われます（ランタイムや JIT の実装依存なので、同じように Interlocked しておいた方が確実ですが）

      3. 裏話

      • 例外のメッセージについて、原著の第 1 版では Jeffrey Ritcher はかなり過激な発言をしていましたが、本書の原著である第 2 版では削除されています。
        内容は「プログラマーはエンドユーザーじゃないんだから、例外のメッセージなんてローカライズする必要ないんだよ」というような内容でしたw

Designed by CSS.Design Sample