クラス名・変数名に迷ったら書き込むスレ。Part14

1 名前：デフォルトの名無しさん mailto:sage [2008/12/29(月) 00:20:32 ] クラス名、変数名のつけ方に悩んだら書き込むスレです。 質問する人は、その変数に何を格納するのか(クラスだったらその役割) プログラミング言語は何なのかを、それぞれ書いて、 いい変数名を思いついた人は、それに答えてあげましょう。 命名規則や設計の善し悪しについて議論するのは基本的に禁止。 >>2 英和・和英・英英など各国語辞書と翻訳サイト。 >>3 類義語(シソーラス)辞書、図形・数式・数学用語の英単語。 >>4 関連スレと、いろいろな言語規約。 >>2-10 諸事情によりリンクがずれた場合。 前スレ。 ◆ネーミング倶楽部◆: pc3.2ch.net/tech/kako/1035/10353/1035362308.html Part1: pc5.2ch.net/tech/kako/1046/10465/1046541730.html Part2: pc5.2ch.net/tech/kako/1058/10582/1058213523.html Part3: pc5.2ch.net/test/read.cgi/tech/1067171530/ Part4: pc5.2ch.net/test/read.cgi/tech/1087209526/ Part5: pc8.2ch.net/test/read.cgi/tech/1109330204/ Part6: pc8.2ch.net/test/read.cgi/tech/1128266018/ Part7: pc8.2ch.net/test/read.cgi/tech/1144978008/ Part8: pc10.2ch.net/test/read.cgi/tech/1154448184/ Part9: pc11.2ch.net/test/read.cgi/tech/1168356029/ Part10: pc11.2ch.net/test/read.cgi/tech/1180146315/ Part11: pc11.2ch.net/test/read.cgi/tech/1191250784/ Part12: pc11.2ch.net/test/read.cgi/tech/1206118762/ Part13: pc11.2ch.net/test/read.cgi/tech/1222661623/ 231 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 18:17:56 ] Required Missing 232 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 18:28:07 ] SetRequired IsRequired IsRequiredButNotFilledIn 233 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 18:33:04 ] IsRequired IsMissing 234 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 18:39:25 ] なるほど参考させてもらって IsRequiredとIsFilledがわかりやすそうなので、これにしました。 ありがとうございました 235 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 18:59:44 ] In... 236 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 19:14:00 ] (・∀・)ｲﾝﾎﾟ!! 237 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 19:21:58 ] それは Im... ぢゃ 238 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 20:53:05 ] しかし、「入力必須であることを設定、取得するプロバティ名」ってのはどういうことかのう。。 そのクラスは、文字列か何かの別のプロパティを一つだけ持っていて、 そのプロパティが必須かどうかを表すプロパティ、って意味なのか？ だとしたらなんだか無駄な気がするんだけどな。 「それ」が必須かどうかを表現するためだけに、ただの文字列をラップするのか。 「それ」が必須かどうかなんてことは、そのデータを持つクラスが知ってればいいことだと思うけど。 239 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 21:03:22 ] 入力で未入力を許容するかどうかを確認する例はよくあるだろ 240 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 21:06:16 ] ToNじゃ！ToNがでたぞ！ ま、開発経験の無いでっかちド馬鹿に一つだけ教えてやるけど よくある入力フォームでの話だろ お前は何の経験も無いから知らないだろうけど そんな理想論掲げるだけ無駄だし無意味だし金にもならないし社会活動として破綻してる 241 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 21:34:51 ] >>239 それはそうなんだが、俺(>>238)の言ってる意味わかってる？ 普通は>>230みたいな変な実装しないと思うよ。 これじゃたわざわざ述する手間を増やして可読性を落としてるだけじゃん。 242 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 21:38:07 ] だからバリデータを自分で実装するからだろ 243 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 21:46:09 ] 必須は、mandatoryともいうな。 244 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 21:46:47 ] 設定するのが義務的な意味で。 245 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 21:48:31 ] >>241 例えばTextBoxの派生クラスを作るのに、 Require属性がなかったら、いちいち項目ごとに異なる派生クラスを作って、 いちいち入力必須かどうか記述しなくちゃいけないじゃん。 そのほうが手間だし可読性は最悪だろ Require属性があればプロパティを設定するだけですべてに応用ができる。 246 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 21:51:16 ] UserやらNameから派生したテキストボックスとかあったら爆笑しちゃう 247 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 21:55:44 ] >>246 バリデートもそれぞれ別にやらなきゃいけないしな User.IsMissing Name.IsMissing MailAddress.IsMissing ・・・・・ Address.IsMissing とか、いちいち全部チェックするのかしら。 手間だし可読性も最悪。 248 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 22:01:03 ] >>245 その入力欄が必須かどうかを表す値をGUI部品に持たせるって 普通は変な設計だと思うけどなw もちろん必須かどうかをユーザーに対して表示する機能を持たせるため、 というような事情はありうるだろうけど。 それ以前に、それって>>230の話と違うことない？ >>230はGUI部品の話をしてたんだろうか？ 249 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 22:01:56 ] >>241 ごめん、変じゃない実装って何？ >>238だけじゃいまいち分からん。 250 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 22:06:03 ] >>230は「入力」の話をしてるのに GUIで入力しないで何で入力するんだ？念力？ ユーザーオブジェクトの必須フィールドについてとかなら 全然違う書き方で質問してくると思うが 251 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 22:08:25 ] >>248 インターフェースでIsRequire属性を、それぞれのクラスに継承させ、 ファクトリークラスからインスタンスを生成する。 ファクトリークラスでは foreach(IInterface object in ObjectList) 　boolValue = boolValue & Object.IsMissing; これだけですべての項目のバリデートができる user、name、mailAddress、birthDay、age等すべてでValidateするのとどちらが可読性が上かい？ そして、こんな設計は変なのかい？ なんか書いていてむなしいぜ。 252 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 22:17:29 ] >>249 例えば、Customerクラスに氏を表すFamilyNameというメンバがあるとする。 そのFamilyNameが「入力必須」であることを表現するためだけに、 IsMissingをプロパティに持つ新たな型を導入するのは無駄だということ。 素直にFamilyNameは単純に文字列で持てばいい。 それが必須かどうかの情報はCustomerが持っている方が直感的だ。 253 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 22:17:39 ] >>248 だからバリデータを自分で実装するからだろ 俺(>>242)の言ってる意味わかってる？ 254 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 22:21:38 ] >>252 そりゃ無駄だわｗ そして、当たり前の事だわｗ 最後に、ただのお前の勘違いだわｗ 255 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 22:24:43 ] >>252 逆 その理屈だと、どんな属性もそれを抱えるクラスが持てばいいことになる。 Formに貼り付けたUI部品のVisibleをすべてFormで管理するなんて煩雑過ぎる そのオブジェクトの属性は、そのオブジェクトが持つのが常識 かつ>>251の書いているとおりインターフェースを利用した場合のほうが、 拡張すべき実装（例えば誰が入力したか）がでた場合に簡単に拡張できる。 インターフェースにUserを追加するだけだからな。 256 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 22:33:57 ] >>254 そうでもないよ。 例えばnullを許容するかどうかの場合を考えるとわかりやすいよ。 これは空文字とは別にnullなんだという情報をCustomerクラスに持つなんてしないでしょ。 その属性は、そのオブジェクトに持たせるのが常識。 257 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 22:43:20 ] そのCustomerオブジェクトがValidであるかどうかのチェックが必要な場合はCustomerクラスに記述すべきじゃない？ 今回のお題とは全く別件だけどさ 258 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 23:08:54 ] >>255 ＞その理屈だと、どんな属性もそれを抱えるクラスが持てばいいことになる。 いや、そうは言ってないよ。 「そのオブジェクトの属性は、そのオブジェクトが持つのが常識」には完全に同意するけど、 FamilyNameが入力必須かどうかは普通に考えれば「Customerクラスの都合」であって FamilyNameの属性ではない。 ただ、>>251の言うことが正しい（少なくとも一理ある）のは理解した。 >>251の言う利点は正直あまり同意できないけど、確かに、例えば ある値に「不正な入力がされている」ことをUIに反映するようなことを考えるときには プロパティから取得したデータ自身が「自分が不正な値かどうか」を知っている方が便利だ。 言い訳がましいけど、俺は普段（「入力」ボタンが押されたときまとめて、ではなく） 個別のコントロールに入力された時点でプロパティの値を設定して、プロパティのセッタの中で バリデーションを行って結果はイベントで通知してUIに反映する、というコードを書く場合が多いので >>251の発想はなかった。 「変」とか言ったのが気に障ったらそれは謝る。 259 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 23:13:20 ] ここは属性プログラミングの出番だと思うね。 まあ、 >命名規則や設計の善し悪しについて議論するのは基本的に禁止。 なんで、ほどほどに。 260 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 00:10:01 ] >>258 Webアプリじゃそんな贅沢な事出来ないしな 261 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 00:12:16 ] TONさんさー 今回は出なくていいよ。 正直これはどうでもいい。 262 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 00:15:26 ] >>258 それだとコントロールが追加されるごとに、 ・新たなプロパティ値を設定する部分 ・バリデーションをする部分 ・イベント通知をする部分 ・そのコントロールが未入力を許容するかどうか という項目をCustomerクラスに追加していかなきゃいけなくなるでしょ ファクトリークラスとインターフェースを利用すれば、 インスタンスを生成するだけで、それが自動的にできる。 そのためには、それぞれのコントロールにRequired属性が必要になるってこと。 >>259 これで最後にするよ。 263 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 00:26:49 ] T.O.N.さんは質問者が解決って言った後に愚痴り出すのが趣味だから、しょうがないよ 264 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 01:20:04 ] >>262 ＞インスタンスを生成するだけで、それが自動的にできる。 それはちょっとミスリードな言い方だな。 単にそれらの処理が書かれる場所がデータを所有するクラスからデータ自身のクラスに 変わるだけ、でしょ？ もちろん、>>251のコードのように列挙してチェックする必要がある項目が 多数になる可能性があるのなら、(1)データ自身に、(2)同じインターフェイスとして実装する ことによるポリモーフィズムの利点が利いてくるのは確か。 でも>>230のような用途でそんな可能性があるのかなあ。 やっぱり正直、一見エレガントに見えて「策士策に溺れる」的に思える。 ＞そのためには、それぞれのコントロールにRequired属性が必要になるってこと。 ごめんこれは何を言っているのかよくわからん。 最後に、確かにこれはスレ違いと言われても仕方がない話題だねすまんかった。 265 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 01:21:52 ] >>258 解決済みの件を無駄だの変だのと蒸し返した挙句、 今日一番の長文が殆ど全部言い訳で占められてるってどうよ？ 本当に性格悪いな、あんた。 266 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 01:29:07 ] >>264 何で質問者がいるうちに言わないの？ 何で質問者が居なくなった頃を見計らって「ぼくのかんがえたしつもんしゃがいいたかったこと」を語りだすの？ 何で質問者がそこまで間抜けな質問をしていると仮定するの？ 267 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 01:47:57 ] >>264 >単にそれらの処理が書かれる場所がデータを所有するクラスからデータ自身のクラスに変わるだけ、でしょ？ 「単に」ではなく、それが最も重要な利点。 Validateする内容が文字列だけだと勝手に決めてないか？ stringだけなら、配列にいれた文字をstring == ""ですべてチェックできるが、 intやstringが混在する場合だと、その都度、異なるメソッドに割り振ってチェックしなきゃいけないから効率が悪い。 データ自身が処理を持っていれば、インターフェースで指定したValidateの返値を得るだけでチェックできる。 そしてユーザ指定型を追加して拡張したい場合でも、インターフェースさえ設定すれば、 所有クラスは何も変えずに使い続けることができる。 >でも>>230のような用途でそんな可能性があるのかなあ。 十分にある。 ・Webアプリのコントロール→ボタン押下時に一斉にチェックする必要がある ・入力をチェックする再利用可能なValidationクラスの設計→メアド、数値など、 入力値をチェックするコントロールを再利用可能なクラスとして設計し、一斉にチェックする場合 ・データベースへInsertするための汎用クラスの設計→DateTime値、int値、nullかどうかなど、 それぞれの入力値を一斉にチェックする場合 >ごめんこれは何を言っているのかよくわからん。 これを理解できないのに、なんでインターフェースを語れるんだ？ 268 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 02:09:32 ] 経験値不足な彼相手によくそこまで付き合ってあげられるなぁ。 ちょっと涙が出てきた。 269 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 02:55:17 ] >>264 >それはちょっとミスリードな言い方だな。 いや自動にできる >単にそれらの処理が書かれる場所がデータを所有するクラスからデータ自身のクラスに >変わるだけ、でしょ？ データ自身のクラスに、そんな処理を書くわけないだろ 処理はデータ自身の基底クラスに記述 データ自身はそれを継承しているだけ だから自動でできる 270 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 02:58:57 ] 案の定いつも通りの流れでﾜﾛﾀ 271 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 03:01:59 ] そろそろTONさんバックレます また2週間くらい 272 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 03:10:32 ] >>230読んでクラスのメンバフィールドの話をしてると思った人ってTimeOfNowの人意外にいるの？ 273 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 03:34:59 ] 俺は入力フォームみたいのを作って実行する、データ自体には依存しない一般的な仕掛けを実装したいのかなと思った。 274 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 05:23:45 ] とりあえずTONのひとはコテハンかトリップでもつけてくれねぇかなぁ。 275 名前：TimeOfNow ◆g72UvIyAhI mailto:sage [2009/02/13(金) 05:41:07 ] トリ付けました。 276 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 05:42:01 ] >>274 フルボッコされると自演乙とか言っちゃう人だから、まぁ無理でしょ 277 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 05:44:00 ] TONが「ました」 なんて言う訳が無い 278 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 09:00:15 ] >>273 「普通」はそうとしか取れないよな 279 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 13:48:04 ] 年度末、年度初めって何かある？ startNendoOfYearとかベタなのしかおもいつかんｗ 280 名前：279 mailto:sage [2009/02/13(金) 13:49:40 ] ああ、ごめん年度開始月と、年度末月でした。 startMonthOfNendoとか、endMonthOfNendoとかしか思い浮かばない・・ 281 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 14:02:28 ] >>280 それでいいじゃん。何か不満なの？ 282 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 16:04:55 ] Nendo -> FiscalYear （会計年度） Nendo -> BusinessYear （事業年度） Nendo -> AcademicYear, SchoolYear （学校年度） 283 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 18:59:25 ] of yearっているの？ ToN！ 284 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 20:13:55 ] >>267 いや、「＜コントロールに＞Required属性が必要」というのはやはり意味不明に聞こえる。 コントロール、に？ 前半の話は理念的に美しいのは認めるが、現実解としてはやはり間違いだと思う。 >>230のような話は、ベタにやった方がずっと早くわかりやすく書ける。 >>269 それ自分で言ってることの意味がわかって言ってるの？ 285 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 20:22:21 ] >>284 スレ違いの話題いいかげんにしろや池沼 286 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 20:25:25 ] >>284 >前半の話は理念的に美しいのは認めるが、現実解としてはやはり間違いだと思う。 なら汚いスパゲッティコードしか書けてないんだろ object指向ならあらゆる処理を行うコードが、それぞれまとまっているわけだが？ int.ToString(); string.Substring(0, 0); datetime.AddDays(0); そしてintなどには未入力であることを示すプロパティが無いから、 自前で実装しておきたい需要は普通にあるだろ。 それこそ機能を作っておいて>>269の言うとおり継承するだけでいいんだから そのほうが簡単で確実だし可読性も良い。 お前の言う方法だと、いちいちその都度、Customerクラスを専用に作り直さなければ ならないので遅いし、クラスによって実装が異なるから分かりにくく可動性に欠ける。 287 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 20:44:50 ] >>286 いきなりお前呼ばわり？ まあいいけど、既に書いたとおり、>>230のような情報は本来「データを所有しているクラス」 が知っているべきことであって、データそのものに属する情報じゃない。 OOP云々いうのなら、こういう「意味論的なおかしさ」にも敏感になってよ。 それだけでなく、年齢（普通ただの数値であることを期待するだろう）が、「必須項目かどうか」 を年齢自体に持たせるために、本来ただの数値で済むものに専用型を導入するわけ？ int age = Customer.Age.Value; みたいなまどろっこしいことを強制されるわけ？ 策に溺れてるじゃん。 それと、その継承の使い方はおかしいと思うよ。 継承って「見たくないコード」を隠すために使うものなの？ 違うと思うけど。 288 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 20:47:41 ] >>287 暗黙の型変換ができればいい。 289 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 01:22:06 ] >287 継承の使われ方は結果論であって、 親クラスがその責務をもつのが妥当かって話で その観点からは個人的にはアリだと思うけど。 まどろっこしいかどうかは言語によっても変わるだろうし。 でもお二人ともスレ違いだしそろそろやめたら？ 290 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 02:04:47 ] >>287 そこで暗黙の型変換使わないでどうするの？ もう少し知識を揃えようね。 それにオブジェクト指向の根本が見たくないものを隠すからなってるだろが。 291 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 02:12:27 ] o(･_･= ･_･)o ｷｮﾛｷｮﾛ 292 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 02:18:46 ] Webアプリだと普通にベストプラクティスの一つだと思うけどな。 それを「少なくとも一理ある」だの「正直あまり同意できない」だの、どんだけ言い訳まみれの人生なんですかｗ 293 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 02:44:55 ] >>1 >命名規則や設計の善し悪しについて議論するのは基本的に禁止。 294 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 06:12:10 ] >>238の時点でブッチギリにスレ違いなのに、何をいまさらｗ 295 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 11:35:18 ] 所持数とか使用数みたいな 変数名はいまだに悩む 296 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 19:23:01 ] 結局残るのはTimeOfNowを肯定する人間は一人も現れないと言う事実のみ 297 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 21:41:34 ] いまはこーのばしょで〜TimeOf Now〜 298 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 21:45:21 ] >>287 >OOP云々いうのなら、こういう「意味論的なおかしさ」にも敏感になってよ。 なるほど組み込み型の変数以外は、どんなクラスであれ、データそのものでなく、 データを所有するクラスだから、未入力属性が存在することは認めるということね。 つまり、バリデーションを受け持つクラスや、GUI部品が 未入力であることを示すプロパティを持ってる事には納得したってことだな。 じゃなんで、>>238のような質問をするんだ？ >>230はどう考えても、お前の言うところのデータを所有しているクラスのプロパティだろ。 >int age = Customer.Age.Value; みたいなまどろっこしいことを強制されるわけ？ 暗黙の型変換、拡張メソッドがあるじゃん >継承って「見たくないコード」を隠すために使うものなの？ すべてではないが、一つの機能だろ。 継承とカプセル化が無縁のものなら、なんでprivateとprotectedの違いがそもそもあるんだ？ 299 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 22:38:32 ] >>298 だからいきなり人をお前呼ばわりするなって。 最低限の礼儀も弁えない糞ガキなの？（まあ、やってることは疑念の余地なくそう。） 悪いけど前半は何を言ってるのかさっぱり理解できん。 最後の三行について言えば、>>269,>>286が言っているような目的、 つまり、例えばEMailAddrクラスがあるとして、そのクラスの中に直接Validateメソッドを 書くことを避けるためだけに無理に（つまり何の「汎化」にもなってない！） ベースクラスEMailAddrBaseクラスを作る、なんていう継承の使い方を良しとする まともなプログラマって見たことないよ。 それって、例えばCで、「関数の行数が長すぎるからもっと短くしろ」と叱られた 馬鹿な新米プログラマが、 int hogeFunc(int x, int y) { 　　#include "hogeFuncの中身.h" } とやってるのと何が違うの？ ついでに言えば、こういう愚行を「カプセル化」と呼ぶ人間も見たことない。 （まあこれは普通そんな頭の悪いことはしないから当たり前だけど。） 300 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 22:57:46 ] 俺が設計してやろうか？ 301 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 22:58:36 ] 2chでお前って言われてブチ切れるやつ始めて見たｗｗｗｗ 302 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 23:04:15 ] ひょっとして４０過ぎのおっちゃん？ 303 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 23:09:47 ] >298,299 お前らもう最低だな。早く死ねや 304 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 23:34:55 ] 老害すぎる 305 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 02:37:36 ] つかNullable型のような物を自前で実装するってだけだろ 何そのEMailAddrBaseってｗ ダサすぎｗ 306 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 02:43:12 ] つまりやっぱりTONの人なの？ 307 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 02:45:37 ] >>299は総称型も暗黙の型変換もない言語を使ってるんだよ… 308 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 02:51:28 ] IsMissingだけをサポートするMyStringって型作ってEMailAddrやらFirstNameやらPostalCodeやらがそれを継承するだけじゃん なんでEMailAddrBaseやらFirstNameBaseやらPostalCodeBaseまでつくらにゃならんの？ 309 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 03:09:49 ] EMailAddrBaseさん、落ち着いてくださいよ 糞ガキ呼ばわりも十分に無礼っすよ 無礼者同士、仲良くしたらいいじゃないっすか 310 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 10:50:13 ] 議論も仲良くもここでやんな。 311 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 15:37:35 ] 荒らしにはスルーが基本。読む価値なし 312 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 19:54:42 ] だれかToNさんに鏡を渡してあげないと 313 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 21:40:08 ] 質問ですが、ToNとTONとT.O.Nとどれが一番いいと思いますか？ 314 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 21:45:57 ] ToNがいいと思うけど顔文字に見えてしまう 315 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 21:54:14 ] >>313 もういっこピリオドを付けてT.O.N.にする 316 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 00:22:31 ] >>299 >クラスの中に直接Validateメソッドを書くことを避けるためだけに無理にベースクラスEMailAddrBaseクラスを作る お前バカだろ。電子メールアドレスの基底クラスを作って、それを派生させるのはメアド入力だけかよｗ 個々のオブジェクトに普遍、共通な機能をクラスに記述し、それを継承できるとこにobject指向の意味があるんだよ。 例えばメアドでも住所でも、バリデートが必要なデータは、すべて使用者が入力するデータなんだから、 入力値とIsMissiongプロパティを所有するValidateStringとか言う自作クラスを作って、それを継承するだけだろ。 ついでに入力値を設やりとりするプロパティとか、文字数とか、nullかどうかをチェックする機能も 基底クラスに記述すればいいわけだ。 >（つまり何の「汎化」にもなってない！） お前の脳内で汎化してないだけだろ。 EMailAddressでも、ZipCodeでも、Addressでも、FaxNumberでも、 すべて未入力を許容する可能性があるんだからValidateStringを継承すればいいだけ。 いちいち未入力であるかどうかを個々に記述してたらばからしいだろ。 >こういう愚行を「カプセル化」と呼ぶ人間も見たことない。 お前、継承の機能を全然理解してないだろ。 customerクラスが、未入力を許可するかどうかを所持していたら、 項目が増えるごとにメンバを増やさなければいけないから、 入力するフォームが増えるだけ異なる別個のクラスができて非効率的だろ。 データが所有クラスが、自分自身に未入力を許容するかどうかを持っていれば Customerクラスを改変せずに利用できるから非常に便利。 317 名前：デフォルトの名無しさん [2009/02/16(月) 00:44:03 ] >>299 もう面倒だから俺が設計してやんよ public class MyString //入力関連の基底クラス 　private string mData = ""; 　private bool mIsRequire = false; 　public string Data //入力データを格納するプロパティ 　public bool IsRequire //入力必須かどうか 　public bool IsMissing //入力必須であるのに入力がない public interface ICheck 　public virtual bool IsCheck() //入力データをチェックするメソッド public class MailAddress : MyString, ICheck　//メアドチェック 　public bool IsCheck() 　　return IsMissing && IsMailAddress 　public bool IsMailAddress //メアドかどうか public class PostalCode : MyString, ICheck　//メアドチェック 　public bool IsCheck() 　　return IsMissing && IsPostalCode 　public bool IsPostalCode //郵便番号かどうか public class Tel : MyString, ICheck //電話番号チェック 　public bool IsCheck() 　　return IsMissing && IsTel; 　public bool IsTel //電話番号かどうか 汎用化できるじゃん。しかも継承させたほうがすっきりして可読性が良い。 318 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 00:46:53 ] >>316 ここでもいつも言ってることだが、人が言ったことに反論してもらえるかな？ 人が言ってもいない、ただの君自身の被害妄想的な妄想に対して一生懸命反論して 何か意味あるの？ いつも思うんだが、こういう人間ってどういう思考回路してんだろ意味がわからない。 319 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 01:24:14 ] >>317 一応反論（と言っていいかわからんが…）しとくけど、俺が使った言葉は「汎化」ね。 >>269,>>286が言っているような継承の使い方は、なんの汎化にもなってない愚行だ、 と言ったんだよ俺は。 しかし、君に言ってもしょうがないけど>>269がどういう意味で自動って言ってるのか さっぱり意味がわからんな。 この人継承って魔法か何かとでも思ってるのかしらん。 まあIsRequiredのようにメンバ変数の値を返すだけプロパティやメソッドなら コンストラクタでメンバ変数に適切な値を入れるとかで見かけ上「自動」にできるけど （でも普通はそんなことせず、素直に派生クラスでオーバライドする作りにした方が早いよな） Validateのようなメソッドがどう「自動」にできるのか聞いてみたいもんだ。 コンパイラの中の小人さんが適当にValidateの中身を書いてくれるのかw 320 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 01:47:04 ] >>313 1番目のToNがお気に入りです 321 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 01:49:25 ] あと、一つ思ったんだが、>>230がいうような情報をデータ自身に持たせることが 意味論的におかしいことは既に書いたけど、そのことの帰結として、 例えば同じ型のデータが2つ以上必要で、それぞれ入力必須かどうかが 違ってたらどうするの？ もちろん、例えば入力必須かどうかで別の型にするとか、いろいろ技巧的に解決法があろうとは 思うけど、それって本当に直感的と言える？ むしろそんな技巧を凝らさなければならなくなるのは、最初の考え方に無理があるからじゃないの？ もちろん物事何でもトレードオフだから、多少意味的におかしくてもコードが簡潔になるとか、 それ以上のメリットがあれば良いとは思うんだけど、>>251が提案しているような方法は ある種エレガントではあっても冗長なだけにしかならんよ。 まるで庭の焚き火用の穴を掘るのにユンボ使ってるようだ。 322 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 01:59:24 ] ＞ある種エレガントではあっても冗長なだけにしかならんよ。 323 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 04:19:31 ] 設計の話か。俺になんか聞きたいことある？ 324 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 05:23:07 ] ＼(ToN)／設計ｵﾜﾀ 325 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 01:22:01 ] >>264でスレ違いを謝罪してるのに何故未だに続けてるの？ 326 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 01:37:10 ] 「確かにこれはスレ違いと言われても仕方がない話題」であり、 「紛らわしい事については認めるが、スレ違いでは無い」からです。 「スレ違いな話題だと勘違いする馬鹿」に対して「お気の毒に」と言っているのが>>264です。 これを「TimeOfNowメソッド」と呼びます。 327 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 01:50:08 ] >>319 >>>269,>>286が言っているような継承の使い方は、なんの汎化にもなってない愚行だ、と言ったんだよ俺は。 >>317に書いてるじゃん >しかし、君に言ってもしょうがないけど>>269がどういう意味で自動って言ってるのかさっぱり意味がわからんな。 MailAddress mailAddress = Factory.CreateMailAddress; PostalCode postalCode = Factory.CreatePostalCode; Tel tel = Factory.CreateTel; foreach (ICheck object in Factory.ObjectList) 　icCheck = isCheck && object.IsCheck; いろんな手法はあるが、わかる安くかけば、こんなふうに自動でできたよ >Validateのようなメソッドがどう「自動」にできるのか聞いてみたいもんだ。 >>317に書いてるじゃん 328 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 01:51:34 ] >>321 >>>230がいうような情報をデータ自身に持たせることが意味論的におかしい おかしくないよ 例 JAVAのString.isEmpty() >例えば同じ型のデータが2つ以上必要で、それぞれ入力必須かどうかが違ってたらどうするの？ その型を格納するクラスが二つになるだけだよ。 メールアドレスを格納するクラス MailAddress mailAddress1 = new MailAddress(); MailAddress mailAddress2 = new MailAddress(); とするだけだよ。参照渡しと値渡し理解してる？ >例えば入力必須かどうかで別の型にするとか、いろいろ技巧的に解決法があろうとは >思うけど、それって本当に直感的と言える？ オブジェクトにそのプロパティがあるほうが直感的だよ。 どんな入力内容にも、入力必須が入力必須でないかの二つしかないよ。 入力必須でなければ、入力必須をfalseにして普通に使えばいいだけだよ。 一般化できる昨日をスーパークラスに記述するobjectの仕組み理解してる？ 329 名前：デフォルトの名無しさん [2009/02/17(火) 02:02:00 ] >>321 >あと、一つ思ったんだが、>>230がいうような情報をデータ自身に持たせることが >意味論的におかしいことは既に書いたけど、そのことの帰結として、 >例えば同じ型のデータが2つ以上必要で、それぞれ入力必須かどうかが >違ってたらどうするの？ 異なるインスタンスを生成するだけじゃねーか なにいってんだ？ 330 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 02:12:45 ] >>318 お前も人の言ったことに反論してねーじゃねーかｗ 331 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 02:16:45 ] >>324 ToN入ってたのかｗ

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef