クラスライブラリ開発者向けのデザインガイドライン

ライブラリを担当している方、読んでください。
その後で、貴方しか理解しがたいものになっていないか、確認してください。

クラスライブラリ開発者向けのデザインガイドライン
http://www.microsoft.com/japan/msdn/library/default.asp?
url=/japan/msdn/library/ja/cpgenref/html/cpconnetframeworkdesignguidelines.asp

全部従えとは言いません。
しかし、1 度くらい目を通してください。

ホントおながいします。(泣)

投稿日時 : 2005年5月12日 12:00

コメントを追加

# re: クラスライブラリ開発者向けのデザインガイドライン 2005/05/12 13:21 Elfaria

> 貴方しか理解しがたいものになっていないか、確認してください。
自分のクラスライブラリを、見直してみました。
自分しか理解できないものなっていました。orz

反省。

# re: クラスライブラリ開発者向けのデザインガイドライン 2005/05/12 14:52 じゃんぬねっと

常駐先にいる人、おながいしますから見てください。
それ、激しく考え方間違ってますからー!!

# re: クラスライブラリ開発者向けのデザインガイドライン 2005/05/12 19:06 ロキ１９７４

どこかで話題になってたかもしれませんが、
フィールドを公開するためのプロパティ名って
みなさんどうしていますか？

私の場合同じ名前でCamelかPascalかの違いなんですけど、
これってやっぱよくないですよね？
でもアンダーバーとかつけたくないし、違う名前にも
したくないんです、なんとなく。

private string userName;

public string UserName
{
get
{
return this.userName;
}
set
{
this.userName = value;
}
}

# re: クラスライブラリ開発者向けのデザインガイドライン 2005/05/12 19:15 じゃんぬねっと

# どこかで見たことのある名前ですね。(^^)

> これってやっぱよくないですよね？

ガイドラインを見ても良くないとありますね。
VB.NET だと通用しませんし。

やはり、

Private _UserName As String

Public Property UserName() As String
　　Get
　　　　Return _UserName
　　End Get

　　Set(ByVal value As String)
　　　　_UserName = value
　　End Set
End Proeprty

アンダーバーには、元来より

　「使わないでくださいね」

の意味合いがあるので、これがシックリきます。

# re: クラスライブラリ開発者向けのデザインガイドライン 2005/05/12 20:26 石坂＠日本ベーレー

名前大事。

作った人しか使えないのはライブラリじゃないよね。

最初からローカルルールのコーディング標準とか作ればいいのにって、無いからこうなっているんでしょうけど。
チーム内でコンセンサスを作っていくような雰囲気でもないんだろうな。

# re: クラスライブラリ開発者向けのデザインガイドライン 2005/05/13 9:13 じゃんぬねっと

ですね。(^^)

一例を挙げると、何でもかんでも「継承」に頼ろうとしたり...
まったく、バカのひとつ覚えじゃあないんですから。
インターフェイスも知らないし。

また、何でもかんでも「便利関数」のようなライブラリを詰めまくったり、
オーバーロードで何でもかんでも解決しようとしたり。

お友達がたくさんいて、クラスが独立してなかったり、
って、それ、クラスとは言えないや (^^)

# re: クラスライブラリ開発者向けのデザインガイドライン 2005/05/13 17:02 なちゃ

クラスは関数の集合です。
…
いや多いんです。

# re: クラスライブラリ開発者向けのデザインガイドライン 2005/05/13 17:07 じゃんぬねっと

# これまた、有名な方が来られましたね。

集合にされちゃった... のが多いんですね。(^^)
関数の集合というか、static だらけなクラスが存在するのは問題ないんですが、
何故、Common なんて安易な名前をつけて分類しないんでしょう?

static なメソッドであるべきなのに、インスタンスメソッドだったりとか。
かなり、萎えました。

# re: クラスライブラリ開発者向けのデザインガイドライン 2005/05/16 9:45 ロキ１９７４

＞アンダーバーには、元来より
＞「使わないでくださいね」
＞の意味合いがあるので、これがシックリきます。

そうだったんですかぁ。知らなかった（汗）
そうですよね、VB]じゃ使えないですもんね。
なんだか納得いったのでアンダーバーつけることにします！

＞何故、Common なんて安易な名前

うぉ、付けてる。。。（涙）

# re: クラスライブラリ開発者向けのデザインガイドライン 2005/05/16 18:01 ロキ

> それは、モジュールです。

おっしゃる通りで（汗）

VB6時代の名残というか、標準モジュール扱いしちゃってます。
良くないと自覚しつつ。。。

ついでに名前空間なんて、「企業名.システム名」で
ぜーんぶ同じです。クラス設計なんてやってませんから（恥）

いま1.Xというバージョンで開発していますが、2.Xでそのへん
を整理する為に「クラスライブラリ開発者向けのデザイン
ガイドライン」を一生懸命読んでます。

# re: クラスライブラリ開発者向けのデザインガイドライン 2005/05/20 11:37 じゃんぬねっと

GDNJ での質問が妙な方向へも盛り上がってますね。(^^)

# re: クラスライブラリ開発者向けのデザインガイドライン 2005/05/26 22:38 88Kouji

　おはつです。

確かにガイドラインってだいじですね。特にＶＢ６しかやったことのない人は、．ＮＥＴでも結構引きずりますよね。　特に、メソッド名にFnc_DataCheck、ローカル変数にstrWork,intDataなんて平気でつけますしね。あと、１メソッドに数百ステップなんてざらだし・・・全ての処理をＦｏｒｍクラスに記述するし・・・もうかなしいです。

# re: クラスライブラリ開発者向けのデザインガイドライン 2005/05/27 14:50 じゃんぬねっと (C#, VB.NET)

> あと、１メソッドに数百ステップなんてざらだし

これは、VB に限らず、どの構造化言語でもダメだと思います。

> 全ての処理をＦｏｒｍクラスに記述するし

その Form を単体で独立させたい場合では、
ビジネスロジックをほおっても良いと思います。
が、static なメソッドでなければなりませんね。
「全ての処理」となると、「表に出ろ」と言いたくなります。(^^)

> 特に、メソッド名にFnc_DataCheck

旧 VB の頃から思ってたんですが、Function と Sub の区別って必要ですかね?
値を返すのであれば「Get～」やら「Is～」やらになるハズですから...
値を返さないものは「Set～」とかになりますよね?

# re: クラスライブラリ開発者向けのデザインガイドライン 2005/05/27 18:17 88Kouji

>旧 VB の頃から思ってたんですが、Function と Sub の区>別って必要ですかね?
>値を返すのであれば「Get～」やら「Is～」やらになるハ
>ズですから...
>値を返さないものは「Set～」とかになりますよね?

そうですね。
わたしも、.NETでは、Boolean型は,Trueを省略しても意味が通じるように名前をつけています。 IsRight～とか・・・

VB6には社内規約があるのでFnc_～,Sub_～葉強制ですので,Fnc_IsRight～と長くなってもかまわず付けています。

>「全ての処理」となると、「表に出ろ」と言いたくなりま>す。(^^)
　うちなんて、論理１層レイヤ分割ですから（涙）

早く.NETだけやりたい。

タイトル
名前
URL
コメント
名前をブラウザに記憶する