プロパティについて

«前のページへ 1|2|3

投稿者

投稿内容

餅宮餅吉: ベテラン; 会議室デビュー日: 2005/03/04; 投稿数: 57; お住まい・勤務地: 月餅のうまい店の隣

投稿日時: 2005-08-22 14:38

こんにちわ、餅宮です。

ごめんなさい、まだ理解できないです｡

引用:

Anthyhimeさんの書き込み (2005-08-22 12:26) より:
引用:

「生産性と品質」が純粋なオブジェクト指向で作成されたものより、DataSetやRowSetでコーティングするほうが向上するのはどうしてですか？

基本的にプログラミングレスなのですから、バグの件数が減り、生産性が向上するのは当然です。当然顧客の要求が複雑なビジネス処理やビジネスルールを適用するのであれば、オブジェクト指向を利用するのがいいと思います。あまりないとは思いますが。

　確かにコーティング量が減るのであれ、「バグの件数が減り、生産性が向上」すると思いますが、DataSetやRowSetを用いたほうがコーティング量が減るのですか？

引用:

引用:

　又、スレ主さんがDataSetを使う理由としてあげているのは、メソッドの引数が多くなる場合であると認識していますが、そのレベルでも「顧客の用件」が入ってくるのでしょうか？

無駄な「オブジェクト指向のため」のコードは基本的に顧客は要求しません。

　前提としての確認、ここでいう顧客は何を指しますか？顧客は、システムの発注者と考えよいでしょうか？
　それなら顧客は、システムを用いての利益の向上か、コストの削減が目的であり、コーティングレベルには立ち入らないと思うのですが？
　
　処で、Anthyhimeさんはオブジェクト指向言語で開発する優位点を何とお考えですか？
　因みに、私は変更の容易さだと思っておりますので、Anthyhimeさんからは「無駄なオブジェクト指向のためのコード」に見えるかも知れませんが、変更すること前提として考えるなら必要なことだと思っています。

さる: ぬし; 会議室デビュー日: 2005/07/14; 投稿数: 276; お住まい・勤務地: 実家戻ったｗ

投稿日時: 2005-08-22 14:54

脱線かつ横槍ですみません。
どうしても疑問に思ったので質問です。
(私の知識がないだけなのだろうけど)

引用:

Anthyhimeさんの書き込み (2005-08-22 12:26) より:
基本的にプログラミングレスなのですから、バグの件数が減り、生産性が向上するのは当然です。当然顧客の要求が複雑なビジネス処理やビジネスルールを適用するのであれば、オブジェクト指向を利用するのがいいと思います。あまりないとは思いますが。

複雑な処理だとオブジェクト指向を利用するのが良いのはなぜですか？

一郎: ぬし; 会議室デビュー日: 2002/10/11; 投稿数: 1081

投稿日時: 2005-08-22 15:26

>C#であれば、DataSetに値をつっこんで、それだけをプロパティに渡してしまえば良いと思うのですが、邪道ですか？

私はAnthyhimeさんとは反対の考えで、問題ないどころか大有りだと思います。

DataSetでなくてHashtableですが、つまり以下のソースのようなことですよね。
KensakuClassというクラスを扱う場合です。

コード:

//扱うメソッド
private void button1_Click(object sender, System.EventArgs e)
{
  KensakuClass kc = new KensakuClass();
  Hashtable ht = new Hashtable();

  ht["kubun"]=3;
  ht["code"]="EX-226";
  ht["partOfName"]="簡易";

  kc.Jyouken=ht;
  kc.Kensaku();
}

//KensakuClassの定義
public class KensakuClass
{
  private int kubun;
  private string code;
  private string partOfName;

  public Hashtable Jyouken
  {
    set
    {
      kubun = (int)value["kubun"];
      code = (string)value["code"];
      partOfName = (string)value["partOfName"];
    }
  }

  public void Kensaku(){}
}

型の情報が失われているじゃないですか。
ht["kubun"]に3ではなくて"3"を入れてしまうというバグがありえそうですよね。
ht["code"]ではなくht["Code"]に値を入れてしまったりもしそうですよね。
codeがint型に変更になっても、コンパイルエラーにはならないので、修正の抜けが出そうですよね。
button1_Click()内でhtに値を設定している所を見ても、HashTableを作っていることくらいしか分からないため、何をしているのか直感的に読み取れませんしね。

KensakuClassクラス内ではもちろんですが、使う側でも、
"どのキーの値（index何番）は何型で何の値"
というのを知っていないといけないため、使う側に余計な知識と注意を要求します。

cedman: 会議室デビュー日: 2004/06/21; 投稿数: 13

投稿日時: 2005-08-22 15:44

型付のデータセットじゃないんですか？

VIM: ベテラン; 会議室デビュー日: 2003/11/14; 投稿数: 76

投稿日時: 2005-08-22 15:48

アスペクト指向と関係ありますか？
# AOPについては、まったくわからないですが
# なんとなくそういったのを指しているような気がする。

一郎: ぬし; 会議室デビュー日: 2002/10/11; 投稿数: 1081

投稿日時: 2005-08-22 16:50

引用:
未記入さんの書き込み (2005-08-22 15:44) より: 型付のデータセットじゃないんですか？

あ～、なるほど。
それなら"ちょい悪"くらいじゃないですかね。

生成されるソース見てみましたけど、長いですね。
例えば値を6個7個保持するというだけのオブジェクトを作るんでも、何百（千行く？）行もソースができますよね。
DataSetに慣れてない人は修正するのも大変そうだなぁ。ほんのちょっとの変更でもxmlから再生成するという決まりにしてもいいんでしょうけど。

あと列挙型が使えない。

オーバーロードが表現できない。例えば
f(int, string, int)
f(int, string, bool)
f(int, int)
f(int, bool)
という場合int, string, int, boolという4つのカラムを作るんですか？
オーバーロードの数だけDataSet型を作るっていう手もありますけどね。

MessageBox.Show()がDataSetで値を渡さないのはなぜでしょうか・・・。

cedman: 会議室デビュー日: 2004/06/21; 投稿数: 13

投稿日時: 2005-08-22 17:54

私の前のコメントの「型付の～」というのは、
単に一郎さんの「型の情報が失われる」とのご発言へのツッコミです。
（すみません、舌足らずで）

コードの量・手間に関しては、Visual Studioでチョイチョイと
GUI経由で作れるので問題にはならないと思います。
（当然生成されるコードが理解できることが必要で、
別の問題ですがたまに意図通りのコードが生成されない場合もありますが）

列挙型が使えないのはその通りですが、それで不便を感じたことはないです。
（列挙型を定義する際に、必要に応じて数値→列挙型変換の関数を用意するので）
オーバーロードに関しては必要ならばオーバーロードの数だけデータセット作ります。

スレッドの本題（プロパティの扱い）については、よほどのことがなければ
プロパティとしてクラス・構造体を持たせればいいんじゃないでしょうか？

Anthyhime: ぬし; 会議室デビュー日: 2002/09/10; 投稿数: 437

投稿日時: 2005-08-23 09:25

引用:
確かにコーティング量が減るのであれ、「バグの件数が減り、生産性が向上」すると思いますが、DataSetやRowSetを用いたほうがコーティング量が減るのですか？

単純な要件であれば間違いなく減るでしょうね。

引用:
前提としての確認、ここでいう顧客は何を指しますか？顧客は、システムの発注者と考えよいでしょうか？それなら顧客は、システムを用いての利益の向上か、コストの削減が目的であり、コーティングレベルには立ち入らないと思うのですが？

通常システムはコスト削減が目的なのですから、そのシステム開発も低コストを心がけるのが当然であるといえます。
アーキテクトは顧客要件を踏まえて複数の技術要素を組み合わせて品質、コスト、機能、性能、保守性を最高の状態でトレードオフできる方式設計をするのが仕事だと思っています。
我々が技術的要素が理解できない顧客やアナリストになりかわって細かい技術的要素までプログラマに指示しコスト削減をもたらそうとするのは当然です。

引用:
処で、Anthyhimeさんはオブジェクト指向言語で開発する優位点を何とお考えですか？因みに、私は変更の容易さだと思っておりますので、Anthyhimeさんからは「無駄なオブジェクト指向のためのコード」に見えるかも知れませんが、変更すること前提として考えるなら必要なことだと思っています。

そうですね、オブジェクト指向言語で開発する優位点は、手続き型で解決するのが困難な複雑な問題をさっさとクラス構造とパターンで解決して残業しないで早く帰って、家でのんびりできるところでしょうかね。
私はJavaが普及し始めてから8年ほどオブジェクト指向プログラミングをしていますが、その強力さにはいまだに驚きの連続です。
しかしながら、オブジェクト指向の技術要素に疑問を感じることも良くあります。その中のひとつが今回のJavaのプロパティです。
「変更すること前提」といいますが本当にどのぐらいの量のプロパティを変更するのでしょうか？
その起きるか分からない変更に備えてどれだけのコードを記述すればいいのでしょうか？
数千行プロパティアクセスのためのコードで構成され、実際のコードがほとんどないプログラムを見ることが良くあります。
当然その数千行のためのJavaDoc、ユニットテストの設計書、テスト結果が必要となります。さらに欠陥まで発生する可能性があります。
そもそも変数アクセスにしておけばそれらのコードはすべて必要がないわけです。
それらに費やされた工数は、いざその変更が行われた際の変更コストを下回りますか？
C#はその点スマートであるといえます。変数とプロパティのアクセス方法が同一ですか。
ですのでJavaのプロパティには本質的な矛盾が存在するのですから、そんなに形にこだわる必要はないでしょうというのが私が言いたいことです。

«前のページへ 1|2|3

プロパティについて

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