- PR -

サブクラスのサブクラスのサブクラスの構造体

«前のページへ 1|2
投稿者投稿内容
きくちゃん
ぬし
会議室デビュー日: 2003/08/01
投稿数: 854
お住まい・勤務地: 都内某所
投稿日時: 2006-02-15 19:31
Ｒ・田中一郎さん、こんばんは。

引用:

大きな処理をさせようとした時に、それが独立性が高くて汎用性が低い場合に非公開

Friend（internal） Class にしてます。
じゃんぬねっと
ぬし
会議室デビュー日: 2004/12/22
投稿数: 7811
お住まい・勤務地: 愛知県名古屋市
投稿日時: 2006-02-15 19:38
まず、DataGridView と印刷はクラスという単位で見れば関係がありません。
一緒に使うからといって同じ名前空間である必要もないですし、
本当に「独立」しているならば、内包してはいけないくらいです。
モジュール結合度が強くなるような設計をしていませんか?

削除と編集等のアクションですが、これはメソッドにすべきでしょう。
どうしても何かの都合でアクションが複雑なのであれば、Command 系のクラスになるハズです。
この場合はインターフェイスを上手に使います。

印刷クラスの中のインナークラスなども同じです。
そのクラスの財産と動作手段などをしっかりと分けましょう。
何でもかんでもクラスにしてはいけません。

# 私的には、インナークラスは 1 インデントのみですね。
# もちろん、たいていが非公開。

_________________
C# と VB.NET の入門サイト
じゃんぬねっと日誌
一郎
ぬし
会議室デビュー日: 2002/10/11
投稿数: 1081
投稿日時: 2006-02-15 20:04
引用:

Ｒ・田中一郎さんの書き込み (2006-02-15 19:28) より:
表を処理するためだけの機能です。

"機能"なんですね。
じゃあクラスにはならないですね。
引用:

表コントロールクラスの中で、行の削除に関する部分を下請けするためのクラス
です。

処理を委譲する理由はどのようなものでしょうか。
状態によって処理内容が変わるということでしょうか。それなら"Stateパターン"(？)を使えば良いと思います。
そうでないのであれば
引用:

大量の非公開メソッドを表コントロールクラスに置くのも混乱しそうです。

混乱とおっしゃっていますが、これが正しいんじゃないですかね。非公開だからこそ混乱しないで済むのでは？
表コントロールの機能は表コントロールが持つ。自然じゃないですか。
Ｒ・田中一郎
ぬし
会議室デビュー日: 2005/11/03
投稿数: 979
投稿日時: 2006-02-15 20:12
引用:

きくちゃんさんの書き込み (2006-02-15 19:31) より:

Friend（internal） Class にしてます。


そうですね。
Friend や Protected などの検討をもう少ししてみようと思います。
ありがとうございました。

引用:

じゃんぬねっとさんの書き込み (2006-02-15 19:38) より:

まず、DataGridView と印刷はクラスという単位で見れば関係がありません。
一緒に使うからといって同じ名前空間である必要もないですし、
本当に「独立」しているならば、内包してはいけないくらいです。


表コントロールの内部機能として、Private な Class にしていたのですが、
じゃんぬねっとさんに言われて、よくよく考えてみればDataGridViewにおいても、
渡すだけで、その内容が印刷できる訳ですから、めちゃめちゃ汎用性があるもの
でした。

引用:

じゃんぬねっとさんの書き込み (2006-02-15 19:38) より:

削除と編集等のアクションですが、これはメソッドにすべきでしょう。


例えば、編集クラスでは、セルの編集が開始された時点の値を記録し、編集が終了
された時点で内容を判定して、セルの内容が変更されたイベントを発行させるため
の細工や、複数のセルが選択されていた場合に、それらのセルに対して一度に値を
設定するための下請けメソッドがまとめられています。

なのでメソッドにするよりは、

引用:

じゃんぬねっとさんの書き込み (2006-02-15 19:38) より:

どうしても何かの都合でアクションが複雑なのであれば、Command 系のクラスになるハズです。
この場合はインターフェイスを上手に使います。


になるかと思われます。

引用:

じゃんぬねっとさんの書き込み (2006-02-15 19:38) より:

印刷クラスの中のインナークラスなども同じです。
そのクラスの財産と動作手段などをしっかりと分けましょう。
何でもかんでもクラスにしてはいけません。


なるほど、インナークラスが深くなるのは設計の問題で、通常は、そうならない
ように書くのが正しかったのですね。
アウトラインの開閉ができる環境に甘えて、つい筆の進むまま書き連ねてしまい
ました。
今は、悪い夢を見ていたような、清清しい気持ちです。

引用:

じゃんぬねっとさんの書き込み (2006-02-15 19:38) より:

# 私的には、インナークラスは 1 インデントのみですね。
# もちろん、たいていが非公開。


今後も、この教えを守って行きたいと思います。
じゃんぬねっと
ぬし
会議室デビュー日: 2004/12/22
投稿数: 7811
お住まい・勤務地: 愛知県名古屋市
投稿日時: 2006-02-16 12:34
引用:

Ｒ・田中一郎さんの書き込み (2006-02-15 20:12) より:

例えば、編集クラスでは、セルの編集が開始された時点の値を記録し、編集が終了
された時点で内容を判定して、セルの内容が変更されたイベントを発行させるため
の細工や、複数のセルが選択されていた場合に、それらのセルに対して一度に値を
設定するための下請けメソッドがまとめられています。

> 表を処理するためだけの機能です。

と仰ってましたが、実はデータも含まれるんですね。
ただ、渡したデータを動的に何かするつもりがないのであれば、
引数で渡して直接 "機能" させても良いと思います。

説明を見ると、データについては別のデータクラスという扱いができそうですが...
データの集積自体をどのような形態でやっているかにも因りますね。
DataGridView そのものの参照を渡しているのであれば断固反対しちゃいます。(^-^;)

引用:

今後も、この教えを守って行きたいと思います。

全部そうしろというわけではなく、適材適所でという意味です。
というよりは、そんな場面は私の経験からすると希少です。
たいていが Item に対しての Collection という関係でしか使いません。

System.Windows.Forms.ListView クラスと、System.Windows.Forms.ListViewItem クラスを眺めてみてください。

_________________
C# と VB.NET の入門サイト
じゃんぬねっと日誌
Ｒ・田中一郎
ぬし
会議室デビュー日: 2005/11/03
投稿数: 979
投稿日時: 2006-02-16 14:22
引用:

じゃんぬねっとさんの書き込み (2006-02-16 12:34) より:

説明を見ると、データについては別のデータクラスという扱いができそうですが...
データの集積自体をどのような形態でやっているかにも因りますね。
DataGridView そのものの参照を渡しているのであれば断固反対しちゃいます。(^-^


断固反対されてしまったので、早速書き直します(^-^
«前のページへ 1|2

スキルアップ／キャリアアップ（JOB@IT）