C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[8]: クラスファイルの記述に関して

分類:[ご意見]　

柊です。

クラスファイルを作っていくうちに、
１つのファイルにクラスがごちゃごちゃしてきまして。

目的別に分ければいいんだ！と分け始めると、
どうも見づらくなってきてしまい。う～んと悩んでます。

例えばマスタの名称参照するクラスを作った場合に

-----------------------------
public static string 得意先名参照(string str得意先コード)
{
string sqlTxt = "SELECT * FROM M得意先 WHERE 得意先コード="+str得意先コード;
データベース接続～参照手続き･･･
return 得意先名
}
-----------------------------

こんな感じのクラスを他のマスタの参照クラスと一緒に１つのファイルにまとめるのがいいか
クラスファイル１つにクラスを１つだけいれるのか。

こういうのに決まりごとっていうのはないと思いますが
みなさんのご意見を伺いたく投稿しました。

ご意見よろしくお願いします。

■No12020 (柊さん) に返信

> クラスファイルを作っていくうちに、
> １つのファイルにクラスがごちゃごちゃしてきまして。

クラス？メソッド？

記載されているサンプルはメソッドですよ。

■No12020 (柊さん) に返信
サンプルを見ただけではごちゃごちゃしてる感が伝わってきませんが？
>public static string 得意先名参照(string str得意先コード)
のようなメソッドが、クラス内に複数存在していることを指していますか？
それとも、このメソッド内の処理が冗長なことを指していますか？

なにがごちゃごちゃしているのか、具体的に言葉にしてください。
そうしないと、第３者が助言するのは難しいです。

>データベース接続～参照手続き･･･
は、SQLを引数に渡して結果セットを取得するような、別関数に
する方法があると思います。

■No12021 (じゃかるたさん) に返信
> ■No12020 (柊さん) に返信

> クラス？メソッド？
>
> 記載されているサンプルはメソッドですよ。

説明不足、失礼しました。

次のような感じにしたほうがいいのか
-------------------------
class 名称参照
{
public string 得意先名参照() { ･･･ }
public string 商品名参照() { ･･･ }
public string カテゴリ参照() { ･･･ }
････その他いろいろ
}
-------------------------

このような感じでクラスをわけて
１ファイル１クラスにするかを悩んでます。
-------------------------
class 得意先名参照
{
public string 参照() { ･･･ }
}

class 商品名参照
{
public string 参照() { ･･･ }
}
-------------------------

■No12023 (柊さん) に返信
> ■No12021 (じゃかるたさん) に返信
>>■No12020 (柊さん) に返信
>
>>クラス？メソッド？
>>
>>記載されているサンプルはメソッドですよ。
>
> 説明不足、失礼しました。
>
> 次のような感じにしたほうがいいのか
> -------------------------
> class 名称参照
> {
> public string 得意先名参照() { ･･･ }
> public string 商品名参照() { ･･･ }
> public string カテゴリ参照() { ･･･ }
> ････その他いろいろ
> }
> -------------------------
>
> このような感じでクラスをわけて
> １ファイル１クラスにするかを悩んでます。
> -------------------------
> class 得意先名参照
> {
> public string 参照() { ･･･ }
> }
>
> class 商品名参照
> {
> public string 参照() { ･･･ }
> }
> -------------------------

class 得意先
{
public string 名称() { ... }
}

ではないですかね。
メソッドかプロパティかと言うのは置いといて。

何に依存させるか。DBを意識させるか。とか。

テーブル.メソッド()は「テーブル」に依存しています。そして利用者はDBを意識することになります。
この場合、業務仕様の重みは利用者側の実装にあります。

項目名メソッド()は「項目名」という業務仕様に依存しています。利用者の意識としてデータがDBにあるとかないとかはあまりありません。
この場合、数が増えます。

お書きになった例を含めてシステムの性質にマッチしているものを検討することになります。

2007/12/27(Thu) 15:28:40 編集(投稿者)

私の場合、基本的に後者です。

但し、共通処理などはベースとなるクラスを作って継承してます。

class ベース
{
protected bool 接続処理などなど() { …; }
}

class なにか : ベース
{
public データセットとかなんかの処理() { …; }
}

あと、クラスを #region ～ #endregion でくくって見やすいようにしてます。
http://msdn2.microsoft.com/ja-jp/library/9a1ybwek(VS.80).aspx

■No12023 (柊さん) に返信
> このような感じでクラスをわけて
> １ファイル１クラスにするかを悩んでます。

時と場合と人と外部要因に拠りけりで、なんとも言えません。
どのように変更しても利点と欠点があるでしょう。

どんなパターンが「アリ」でどんなパターンは「ダメ」なのか、
そういった引き出しをどれだけ持っているのかも技量です。
いろいろ試して自分なりにまとめておくのをオススメします。

■No12024 (シャノンさん) に返信
> class 得意先
> {
> public string 名称() { ... }
> }
> ではないですかね。

これはDB内の「得意先」というデータをオブジェクトとして取り出す場合です。
こうコーディングできるなら理想ですが、
DB内のデータのメタデータをソースコードに落とす、O/Rマッピングが必要です。
手間がかかりますし、パフォーマンス的にも劣る場合が多くなります。

>class 名称参照
>{
>public string 得意先名参照() { ･･･ }
>public string 商品名参照() { ･･･ }
>public string カテゴリ参照() { ･･･ }
>････その他いろいろ
>}

これはDBを参照するという機能を1つのクラスにまとめるただけで、
論理的凝集されたクラスです。
あまりよいとはされていませんが、便利な場合も多くあります。

一方

>class 得意先名参照
>{
>public string 参照() { ･･･ }
>}
>class 商品名参照
>{
>public string 参照() { ･･･ }
>}

これは参照する機能をそれぞれクラスとして定義するスタイルですね。
オブジェクト指向的にはある意味正しいですが、
煩雑になる場合が多々あります。

#この場合は
#interface ICodeResolver
#{
# public string 参照() { ･･･ }
#}
#としておいて
#class 得意先名参照 : IResolveCode
#class 商品名参照 : IResolveCode
#とするべきですね

どれも利点と欠点があり、場合によってはどれも有用になりえます。
経験がたまればある程度見通しも立ちます。

関連する話題としては、
「O/Rマッピング」「凝集度」「デザインパターン」などがあります。
Wikipediaや検索エンジンなどで調べ、
どんな設計法があるのか知った上で再度検討してみるとよいでしょう。

> 時と場合と人と外部要因に拠りけりで、なんとも言えません。

御意。

とある業務アプリを１から全部自分で作ろうとしているのか、それとも一部（ＤＢアクセス部分？）だけを取りまとめるよーにと指示されて作業しているのかなどなど。

前者であれば、元投稿者の人が例示した区分けは全部×です。
すでに存在するテーブル構成を眺めて、テーブル・列レベルでの値の抽出・更新しか考えていなさそうなにほいがします。

設計はトップダウンであるべきですが、例示されたクラス設計はことごとくボトムアップな発想で起こされたものにみえます。

テーブル設計は土台となるものが既にあるとしても、まずはそれらのテーブルに対して「どんな操作を行うか」「それらの操作はどのような区分で分類されるべきか」という方向で考えをまとめ、それを設計に落としていく方がよいと思います。

その上で、「お道具」として OR マッピング的なクラスを自作するのがよいのか、LINQ を使うのがよいかとかを決めていけばいいのではないかと。

■No12031 (渋木宏明(ひどり) さん) に返信
> 設計はトップダウンであるべきですが、例示されたクラス設計はことごとくボトムアップな発想で起こされたものにみえます。

１行だけ引っこ抜きで横槍失礼します。

常にこうトップダウンである方が確かに望ましいとは思うのですが、現場では中々そうはいかないのが世の常…(？)orz
もしかして、(色々な)設計から何から全部ＰＧがやってるのは、うちくらいなのかしら…

■No12032 (Algol さん) に返信
> ■No12031 (渋木宏明(ひどり) さん) に返信
>>設計はトップダウンであるべきですが、例示されたクラス設計はことごとくボトムアップな発想で起こされたものにみえます。
>...
> 常にこうトップダウンである方が確かに望ましいとは思うのですが、現場では中々そうはいかないのが世の常…(？)orz
> もしかして、(色々な)設計から何から全部ＰＧがやってるのは、うちくらいなのかしら…

ボトムアップな設計をしているということは、
ロケットを作るのにネジから作ってるというのと同じで。

ロケットを作るときには
いろんなネジを在庫として確保しておくものです。

手元にあるネジが少ないと、
それだけでロケットを作れないかもしれません。
本当は全部のネジを把握してるといいのですが、ネジにはたくさん種類がありますから、なかなか難しいです。

いくつネジの在庫を確保しているかというのが
プログラマや設計者、クリエーター、会社などの能力の指標の一つで、
足りないうちは何回も設計をやりなおさないといけないかも知れませんね。

> 常にこうトップダウンである方が確かに望ましいとは思うのですが、現場では中々そうはいかないのが世の常…(？)orz
> もしかして、(色々な)設計から何から全部ＰＧがやってるのは、うちくらいなのかしら…

全部一人でやってるなら、何も迷うことなくトップダウンで設計できるんじゃないですか？

2007/12/27(Thu) 18:28:33 編集(投稿者)

■No12032 (Algol さん) に返信
>(色々な)設計から何から全部ＰＧがやってるのは、うちくらいなのかしら…
全部やるかどうかは関係なくて、順番と内容反映の方向だと思いますが。

ＰＧとしての立場で、プログラムに都合のいいような仕様を作っているということ？？？
お客さんは、それでお金を払ってくれるの？？？

やる時点で上流工程からやらないと、手戻りが発生するのでは？

>全部一人でやってるなら、何も迷うことなくトップダウンで設計できるんじゃないですか？
確かにｗ

■No12023 (柊さん) に返信
脱線しそうなので話を戻すと、前スレ
http://bbs.wankuma.com/index.cgi?mode=al2&namber=11926
を見ると
>DataGridViewを利用した一覧表を表示し
と書いてあります。で、今回の検索のため(？)の SQL は
>string sqlTxt = "SELECT * FROM M得意先 WHERE 得意先コード="+str得意先コード;
* で取ってきてます。
(フィールドの順番は保証されてないし、必要なフィールドの情報のみ取得するべきなので
フィールドを指定すべきところでもありますが)

その結果が
>class 名称参照
>{
>public string 得意先名参照() { ･･･ }
>public string 商品名参照() { ･･･ }
>public string カテゴリ参照() { ･･･ }
>････その他いろいろ
>}
は合っていませんよね。
表示するなら検索結果(DataTable)を丸ごと表示すれば良いだけで、得意先名が
必要なら、検索結果(DataTable)から特定のレコードを参照すればいいはずです。

つまり、サンプルに示されたクラスは丸々必要ありません。

百歩譲って、検索の前段階として、各マスタに登録されている名称の
一覧を取得したいのだとしましょう。(多分こっちが目的に近いと思ってますが)
すると WHERE 句の条件が必要ありません。

つまり、サンプルに示されたクラスは丸々必要ありません。

特定の得意先コードに対する、得意先名を１つだけ取得する目的があるなら
構いません。でも、今のところ無いような気がします。
必要ないコードをウンウン唸って作ったところで、『必要ないよ』の
一言でばっさりカットされて終了ですよ。作業時間？成果０です。

そんな事はしたくないと思うんですよ。

2007/12/27(Thu) 21:52:04 編集(投稿者)

# 一部語句訂正しました。

まず始めに、とぴ主の柊さん、トピの主題と離れた質問になってしまい申し訳ないです。

そして、皆様、回答ありがとうございます。

ダメダメな癖を直さねばと思いつつ、ハマっていく自分がイヤになってる今日この頃です…orz

■No12034 (渋木宏明(ひどり) さん) に返信
>>常にこうトップダウンである方が確かに望ましいとは思うのですが、現場では中々そうはいかないのが世の常…(？)orz
>>もしかして、(色々な)設計から何から全部ＰＧがやってるのは、うちくらいなのかしら…
>
> 全部一人でやってるなら、何も迷うことなくトップダウンで設計できるんじゃないですか？
>

ごもっともです。
確かに、お客さんへ営業、概要設計、機能の折衝は上役達がやっていますが、画面、ＤＢ、プログラム設計、作成、リリースは私が行っています。
というか、やれる人員が確保できなくてマルマルナンデモ屋をやっているのが現状というか…
(出来ればチームでやりたい案件が多数…

■No12035 (特攻隊長まるるうさん) に返信
> 全部やるかどうかは関係なくて、順番と内容反映の方向だと思いますが。
>
> ＰＧとしての立場で、プログラムに都合のいいような仕様を作っているということ？？？
> お客さんは、それでお金を払ってくれるの？？？
>
> やる時点で上流工程からやらないと、手戻りが発生するのでは？

自分の都合のいいようにプログラムしやすい初期設計にすることが多いです。
大体の場合、お客さん的に機能を満たしているので初期設計の時点で問題が起こることは稀です。

ただし、ある程度作成した時点で、お客さんの都合等で手戻りが発生しますが…
プロトタイプ以降修正が少なければいいのですが、修正が多くなると、よくあるやっていはいけない問題をよくやらかしてしまいます。

言い訳的には、時間の都合で…(以下略

■No12033 (れいさん) に返信
> ボトムアップな設計をしているということは、
> ロケットを作るのにネジから作ってるというのと同じで。
>
> ロケットを作るときには
> いろんなネジを在庫として確保しておくものです。
>
> 手元にあるネジが少ないと、
> それだけでロケットを作れないかもしれません。
> 本当は全部のネジを把握してるといいのですが、ネジにはたくさん種類がありますから、なかなか難しいです。
>
> いくつネジの在庫を確保しているかというのが
> プログラマや設計者、クリエーター、会社などの能力の指標の一つで、
> 足りないうちは何回も設計をやりなおさないといけないかも知れませんね。

たしかに、.NET系に限らず、ネジとなるコモンユニット等はある程度保有してます。(他人から見れば、多数ではないかもですが…(^^;
そのユニットを使ったり、新たに追加したりアップデートしたりして工数削減に勤しんでます…(^^;
決まりきったモノならば、頼まれたその場で組み終わって設計というか書き物が後回しとか…
まぁ、それがいけないんですけども…

＃話の都合上、返答順番が後回しになってしまい申し訳ない

---------
◇よくある書類(設計?)後回しプロセス (自虐の種)

営業、折衝、概要設計などなど(上役
↓
あとはよろしく(引継ぎ
↓
概要設計に基づき詳細設計(画面、DB、PGなど
↓
プロトタイプ作成
↓
お客さんにプレビュー(ここで運命が決まる
↓(大量の修正がある場合とか…
常駐
↓
お客さんにインタビューしつつ修正
(時がたつにつれボトムアップになってきます…場合によっては、デスマーチに…orz
＃突然言ってることが変わったり…ってのもアリで…インタビューログが残ってても(以下略
↓
リリース(仮納品
↓
書類作成(設計書等
↓
納品

まぁ、こんな感じの日々です。orz

■No12040 (Algol@自虐モードさん) に返信
> ◇よくある書類(設計?)後回しプロセス (自虐の種)

それは、引き継ぎ段階で受注仕様を固めていない上役が悪い。

元質問者さんへ

SQL Injection の危険がありますよ

C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[8]: クラスファイルの記述に関して

過去ログには書き込み不可