- - PR -
プログラムの書き方でご指導お願いします。
| 投稿者 | 投稿内容 | ||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-11-09 23:58
＃先にこちらを
かるがるさんはtrueの場合のみ信用するスタンス(!trueをしない)、 未記入さんはtrueとfalseをどちらも評価するスタンスのまま お互いを判断していると思うので、平行線なのかなと。 (追加：「かるがるさんは"=="を信用して"!="を信用しない」かな) というのはまぁ、おいといて、
なのであれば、エラーがある場合(=false)ではない場合(!false)がOKという ことでしょうから、
というわけにはいかないのでしょうか。 パターンAかBか、であれば、Bですが、Bもちょっとなぁ・・・と いうのが私の感想です。 仕様変更でcheckCが・・・という場合は、(checkAとcheckBと)checkCの 仕様を見てからでも遅くないかな・・・と(^_^; [ メッセージ編集済み 編集者: キルシェ 編集日時 2005-11-10 09:17 ] ---------- あー、checkAとcheckBでどちらも別の例外を投げているんですね。 例外が別でしたら、パターンBかなと。 ただ、"return false;"という記述もありますので、そちらであれば、 エラー処理に入るパターンを全て洗い出し、単一のエラー処理 (といっても、"return false;"だけですが)を書きたいです。 例外A,Bを作る責務を負わなくても良いならば、他のバリエーションも ありますね。 （void checkA() throws ExceptionA;とか） ＃このあたりは、… 10ページ目くらいからの議題になるのかな？ [ メッセージ編集済み 編集者: キルシェ 編集日時 2005-11-11 15:00 ] | ||||||||||||||||||||||||||||||||||||||||||||
|
投稿日時: 2005-11-10 02:16
inaです。
例外処理系にするかis系にするかは、おいといて.... 私ならば、 チェックを行っているロジック群を切り出して、チェッカクラスを別途作成 してみて、後は 上記チェッカにどの様なインターフェースをつけてあげれば、コントローラ側がより制御しやすくなるか？ といった観点で設計（または既存ソースのリファクタリング）を行います。 | ||||||||||||||||||||||||||||||||||||||||||||
|
投稿日時: 2005-11-10 09:27
おはようございます。
私だったら、という事で恥ずかしながら私の考えを投稿したいな、と思います。 ちなみに、前提条件として
の時に、 ・「臨時承認」というステータスを追加したい という仕様変更が発生した、という状況で宜しいでしょうか？ その際、私だったら ( 仕様として「認証 OK 以外の際に「臨時承認」が発生する」という仕様だとして下さい → つまり、認証 OK の時には「臨時承認」は発生しない、という事です )
となります。 つまり、 ・既存のメソッド ( ここでいうと is_true ) に対しては修正しない という手法をとります。 新規開発か保守運用かで違うと思うのですが、 保守の場合は「動いていているものに修正は加えない」というのが まぁ、セオリーかな、と思い。 ( そーやって可読性が損なわれていくのですが。。。 ) こういうやり方はどうでしょうか？と愚考してみました。 皆様の忌憚ないご意見をお願いします。 追記: > ブンデスさん 一応、反応しておきますが、「勝ち」「負け」ではないと思います。 そしてアナタのご意見は？ <編集> コードタブで「タブ」と「スペース」だとインデント違うのね。。。 </編集> [ メッセージ編集済み 編集者: 小僧 編集日時 2005-11-10 09:29 ] | ||||||||||||||||||||||||||||||||||||||||||||
|
投稿日時: 2005-11-10 12:12
がるです。
んっと…思ったよりPMが多く来ていたので(っても一桁ですが)、 この場を借りて回答を。 噛み砕いての説明なので長文になることをあらかじめお詫びいたします。 まず始めに
というお話しを頂いたので、では実例を。 とりあえず直近の未記入氏の発言から拾い上げてみたい かと思います。 数発言前の私の
という発言に対して、未記入氏は
と発言されています。 つまり未記入氏は、特に質問をされることもなく 「がるがるの"なりません"とはis_true() の仕様変更にはなりません、 という意味である」 と断定しています(「か」で止めている部分、その後それをベースに 展開をしている部分などから断定していると読み取ることができます)。 後述しますが、私の「なりません」発言は「仕様変更にはならない」 という意味ではありません。 で。 「がるがるは"なりません"の発言がどの部分に掛かるのかを 明記していない」 という反論が聞こえてきそうですが、それはYesです。 意図的に、ですが。 きちんと議論を構築することが可能な相手であれば、 多くの場合はまず疑問を投げかけるか、或いはせめて 「仕様変更にはならないと断じているように読める。 したがって以下、その前提で議論を進める」 といったように「違う可能性があることを前提で」 「とりあえず一つの方向性を前提に」発言をすすめます。 然るに未記入氏はそのようなことを一切せず、 質問すらも出さずにあいまいな事柄を自らの 判断のみで疑問を投げかけることもなく断定し、そこを 基準に議論を進めています。 土台に誤りがあれば、以降の議論構築がおかしくなる のはごく当然のことです。 然るに「土台にミスがある」ことにすら気づかず 突き進まれると、会話自体が非常に困難になって しまいます。 以上が「思い込みで発言をしている」と、或いは 「議論の継続が困難である」と私が言う理由です。 で、他の方からも頂いた
という質問への答えに流れていくのですが。 ちなみに、未記入氏の「仕様変更ではない」と捉える 読み方の場合、恐らくは「なりません」という言葉は
という言葉に掛かっていると判断されたのだと 推測します。 私が「なりません」に掛けているのは
の太字の部分です。 そうですねぇ。もう少し前に「勘違いを誘発している 可能性があるからメソッド名を変えます」といった 方のメソッド名を使うともう少し分かりやすいかと 思うのですが。 未記入氏の発言をそのまま当てはめると is_hoge() true: hogeである false: 判定不能。さらに is_bar() で状態を確認する必要がある is_foo() true: fooである false: 判定不能。さらに is_bar() で状態を確認する必要がある となります。なお、散々書いているのですが、３つの 状態hoge、foo、barは「等価なレベルのステータス」です。 おかしい部分に気づかれましたでしょうか？ この部分への正しい記述は is_hoge() true: hogeである false: hogeではない is_foo() true: fooである false: fooではない is_bar() true: barである false: barではない というのがもっとも正確な記述です。 譲るだけ譲って近い記述をするのであれば、 is_hoge() true: hogeである false: 判定不能。is_bar() 若しくは is_foo() で状態を確認する必要がある といった記述をすべてに書く必要があります。 # とはいえそれは冗長に過ぎると思うのですが。 このあたり、trueとfalseがそれぞれ「何を意味 しているのか」というのを丁寧に理解することは とても大切だと思うです。 ちなみに
というのは、確かにそうかもしれないです。 trueは「処理が成功し、かつそのis判定の結果が "合致する"であった」となるのですが。 特にC言語の場合、戻り値がfalse(これが０なのか −１なのかでまた論争が起きるのですが(笑))の 場合、処理でミスったのか合致しなかったのか はっきりしないことが多いので。 # 実際には１で合致、０で合致せず、−１以下で # エラー、とかって作りが多かったと思うですが。 booleanの場合特にfalseについてはあまり信用を していないのかもしれないです。 # というか明示的にtrueを返してくれる「別の # メソッド」を求めてしまうんでしょうね。 このあたり、よくstring系クラスにある is_empty を作った人に共感を覚えたりします(笑 あと、小僧さんの
は、これはこれで「あり」だと思います。 ただ、３つのステータスが同じレベルであるかどうか 一瞬迷うと思うので、そのあたり、きちんとコメントなどに 書いておくとベターなのかなぁ、と。 以上、長々と説明を失礼いたしました。 | ||||||||||||||||||||||||||||||||||||||||||||
|
投稿日時: 2005-11-10 12:58
お疲れさまです。
ある状態をあらわすのに、is_Aまたはis_BのどちらかがTrueであるとします。 これが要件変更により３つのうちどれかがTrueになったとします。 変更前は、「is_A=True」と「is_B=False」が同じ結果であったのに、変更後はこれが崩れます。 例えばis_B=Trueの状態が２つに分かれたとしたら、is_Bを廃止してis_Cとis_Dに分けたら 上記に起因する問題は気づきます。 未記入さんはこういうことが言いたいだけなのではないでしょうか？ | ||||||||||||||||||||||||||||||||||||||||||||
|
投稿日時: 2005-11-10 13:04
本当にバカ揃いですね･･･。泣けてきます。あなたたちは、修正・変更というものを理解できていないようですね。メソッドのコードを書換えなければ変更ではないから安全だと思い込んでいるようですが、それは間違いです。設計が変わればコードの意味が変わります。これはコードの書換えが発生する以上に危険です。(コードの修正漏れがあっても気付きにくいですから) たとえば、int money = 100; というコードがあって所持金100円をあらわすとしましょう。これが仕様変更により日本円ではなくアメリカドルを表現する、と仕様が変更されたらどうなりますか？ money を使用しているすべての個所を再検証しなければいけなくなりますよね。それをあなたたちは、コードは変更されていないから安全だと言ってるわけです。 当初、is_true() が false を返した場合は「承認されていない」を意味していました。それが仕様変更により false は不定値ということになってしまったのです。コードは変更されていませんが、値の意味が論理設計レベルで変更されてしまったのですから、すべての個所で変更・再検証が必要になります。コードが変わっていないからといって以前のシステムと互換性が保たれていると考えること自体が愚かです。
「なりません」の意味するところなど私にとっては重要ではないです。いずれの解釈をしても、がるがるさんの論理はおかしい、ということを私は述べているだけですから。 ・is_true() の仕様が変更されていない場合 → false が「承認されていない」を示すので、is_wait() は「承認されていない」の詳細情報に過ぎない。 ・is_true() の仕様が変更された場合 → false は不定値をあらわすので、is_true() == false の分岐処理はすべて変更・再検証が必要になります。 どちらにしても、がるがるさんの論理は矛盾していることになります。
この定義は、がるがるさんが提示したプログラムコードと矛盾しています。すでに述べたことの繰り返しになりますが、はじめから上記のような設計になっていた場合は･･･
このようなコードにならなければなりません。承認NG を確定するためには is_foo() をチェックしなければいけないはずです。しかし、当初、がるがるさんは is(is_hoge()) { ... } else { ... } という is_hoge() のみをチェックするというコードを提示しています。これは、is_hoge() と is_foo() が背反でないと成り立ちません。
true のみを信用するスタンスであれば、else 節など書けないはずです。else 節が書けるのは true と false は背反だと信じている、つまり false も信用できる値だというスタンスに立っているからです。
アホですね。C言語で -1 は誰がどう考えたって真値でしょうに。もしかして、プロセスの終了コード 0 は正常をあらわす、というシェルスクリプト文化と混同しているんでしょうか。 | ||||||||||||||||||||||||||||||||||||||||||||
|
投稿日時: 2005-11-10 13:22
こんにちは。
※ バカと言われてしまいましたが。。。 ※ そしてまた「バカ」と言われそうですが。。。 未記入さん発言の 当初、is_true() が false を返した場合は「承認されていない」を意味していました。 という所が私の認識と違っています。 私は最初から ・is_true() が true を返したならば「認証 OK」 ・true 以外 ( まぁ、順当に考えて false ですが ) の場合は「認証 OK 以外」 と認識していました。 ( つまり「認証 NG」という結果を保証しない ) まぁ、「最初の設計思想だと〜」という話が出て来ると思うのですが、 この前提条件ですと、「こういう考え方もあり」なのでは？と思います。 背景とか、携わってきたシステムなどに関してこの辺りは ・再設計のしなおし ・現行ソースを触らないで機能追加 などと分かれるのかな、と思い。 あと、 int money = 100; というコードがあって というお話がありましたが、これは「変数に値を設定する」場合ですよね？ んで、今回はメソッドの話なので関係ないのかなぁ、と。 ( そもそも money = 100 ってハードコーディングなのですか？とか DB から Select した値を設定するのであればテーブルデータにパッチを、とか moneyTmp = 100 にして、 100 で割った値を money に設定する、とか ( もちろん数にもよりますが ) 色々と対応がありそうですけど ) 括弧書きの中身もあまり本気で言っていないのでこの辺りはスルーして頂けると嬉しいです。 | ||||||||||||||||||||||||||||||||||||||||||||
|
投稿日時: 2005-11-10 13:28
こんにちは。
2005-11-08 19:40 のがるがるさんの書き込み(ソースで)
とあります。 あと、C言語でtrue, falseの二値判定の場合、0以外はtrue、0はfalseと判定ですね。 値で処理を分けるのは別の話では。 [ メッセージ編集済み 編集者: tarnwo 編集日時 2005-11-10 13:31 ] | ||||||||||||||||||||||||||||||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。