クラス名・変数名に迷ったら書き込むスレ。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/ 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入ってたのかｗ 332 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 02:27:10 ] おかしくないよ 例 C#のNullable<string> >>328 彼はそれだけじゃ理解できないからもう少し書いてあげないと MailAddress mailAddress1 = new MailAddress(); MailAddress mailAddress2 = new MailAddress(); mailAddress1.IsRequire = true; //mailAddress1.IsMissing ⇒ true & mailAddress1.IsCheck ⇒ false mailAddress2.IsRequire = false; //mailAddress2.IsMissing ⇒ false & mailAddress2.IsCheck ⇒ true mailAddress1 = "hoge1"; //mailAddress1.IsMissing ⇒ false & mailAddress1.IsCheck ⇒ false mailAddress2 = "hoge2"; //mailAddress2.IsMissing ⇒ false & mailAddress2.IsCheck ⇒ false mailAddress1 = "hoge1@hogemail.hoge"; //mailAddress1.IsMissing ⇒ false & mailAddress1.IsCheck ⇒ true mailAddress2 = "hoge2@hogemail.hoge"; //mailAddress2.IsMissing ⇒ false & mailAddress2.IsCheck ⇒ true ほんと、書いててむなしくなるな･･･ 333 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 02:31:49 ] >>330 >>318はどこかの誰かのアンカミスで、ToNに宛てて言ってるんだろ？ そうとしか思えない。いや、それ以外ありえない。 334 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 02:52:12 ] >>318 　　　､ミ川川川彡　　　　　　　　　　　　　　　　 ,ｨｒ彡'";;;;;;;;;;;;;;; 　　ミ　　　　　　　彡　　　　　　　　　　　　　 ,.ｨi彡',.=从i､;;;;;;;;;;;; 　三　　ギ 　そ 　三　　　　　　　　　　　　,ｨ/ｲ,r'"　.i!ｌi,il i､ﾐ',:;;;; 　三.　　ャ 　れ 　三　　　　,.　-‐==- ､, /!li/'/　　　l'' l', ',ヾ,ヽ; 　三　　グ 　は 　三　　,,__-＝ﾆ三三ﾆヾヽl!/,_ ,_i ､,,.ｨ'=-､_ヾヾ 　三　　で 　 　 　 三,. ‐ﾆ三＝,=＝‐ ''' `‐゛j,ｪﾂ''''ｰ=5ｒ‐ｫ､,　ヽ 　三. 　 言　 ひ 　三　　.,,__／　　　　　　.　,' ﾝ′　　　￣ 　三 　　っ　　ょ 　三　　 /　　　　 　 　 　 ｉ l, 　三.　　て 　 っ 　三　　ﾉ ..::.:... ,_　　i　 　 !　 `´'　　　　　　J 　三　 　る　　と　 三　 iｪｧﾒ`'7rｪ､,ｰ'　 　 i　}ｴ=､ 　 三 　 の 　 し　 三　ﾉ "'　　 ￣　　　　　! '';;;;;;; 　 三 　 か　 て　 三.　ｉヽ,_ﾝ　　　　 J　　　l 　　三　 !?　　　　三　　!し=､ ヽ　 　 　 　 　i　　　　　　　　　,. 　　 彡　　　　　　ミ　　 ! "''　`'′　　　　　　ヽ、,,__,,..,_ｨ,..ｒ,',", 　　　 彡川川川ミ.　　　l　　　　　　　 _,　,　　 | ` ｰ､≡＝,ﾝ _,,, 　　　　　　　　　　　　　 ヽ、 _,,,,,ィﾆ三"'"　　,,.'ヘ　rｰ‐ ''''''" 　　　　　　　　　　　　　　　 `, i'''ﾆ'" ,.　-‐'"　　　`/ 　　　　　　　　　　　　　　　ヽ　!　 i´　　　　　　 ／ 　　　　　　　　　　　　　　　ノレ'ー'!　　　　　 ／　O 335 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 02:54:57 ] >>332 その結果、入力内容が正しい（IsValidate ⇒ true）かどうかってのも必要かも 入力必須でなく（IsRequire ⇒ false）、未入力の場合、メアド判定はfalseでも入力結果は正しいからね。 まとめるとこんなんになるのかな？ mailAddress1.IsRequire = true; //mailAddress1.IsMissing ⇒ true & mailAddress1.IsCheck ⇒ false & mailAddress.IsValidate ⇒ false mailAddress2.IsRequire = false; //mailAddress2.IsMissing ⇒ false & mailAddress2.IsCheck ⇒ true & mailAddress.IsValidate ⇒ true mailAddress1 = "hoge1"; //mailAddress1.IsMissing ⇒ false & mailAddress1.IsCheck ⇒ false & mailAddress.IsValidate ⇒ false mailAddress2 = "hoge2"; //mailAddress2.IsMissing ⇒ false & mailAddress2.IsCheck ⇒ false & mailAddress.IsValidate ⇒ false mailAddress1 = "hoge1@hogemail.hoge"; //mailAddress1.IsMissing ⇒ false & mailAddress1.IsCheck ⇒ true & mailAddress.IsValidate ⇒ true mailAddress2 = "hoge2@hogemail.hoge"; //mailAddress2.IsMissing ⇒ false & mailAddress2.IsCheck ⇒ true & mailAddress.IsValidate ⇒ true つか、そう考えると入力判定にIsRequire属性必須だよな 空文字はメアドチェックにははじかれるけど、入力必須でなければバリデート結果はtrueだからな。 まさに書いててむなしくなるな･･･ 336 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 03:49:58 ] >>335 IsCheck==IsValidate 俺ならIsValidプロパティかValidateメソッドで実装するな 337 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 06:16:46 ] TONさん議論の入り口にも立ててなくてﾜﾛｽ ワザとやってるんだろうか 338 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 06:23:06 ] IsValidate はまず品詞がおかしい 339 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 09:43:08 ] IsCheked IsValid 340 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 09:58:20 ] 論旨に影響しない瑣末な違いだ 341 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 10:11:52 ] このスレにとっての本題だがな 342 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 10:17:46 ] いつの間にか設計の話するスレになってたんだな 343 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 10:21:41 ] 設計の話と言うか おぶじぇくとしこういちねんせいのToNに虚しさを感じながらも無駄な説明を繰り返すスレ 344 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 10:29:51 ] トンはもう秋田 345 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 17:28:10 ] さぁTONさんタイムがやってまいりますた！！ 346 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 19:33:32 ] >>327 さすがに頭おかしくないか？ >>317とかそれのどこが「自動」なんだ。 >>264で指摘しているように、ただ判定処理が書かれるコードの場所が変わってるだけだろ。 >>328,>>332>>335 君ら（複数人だよね？）それ本気で書いてるのか？ こんなこと一々説明しなくても当然分かるだろうと思って書かなかったが、 IsRequiredはゲッタのみかつ定数を返すようにしないとマズいだろう。 IsRequiredをインスタンスメンバとして実装しちまったら 外からMailAddressをセットできなくなるだろ。 言ってる意味分かる？ なんていうか、まともなコード書いたことない奴が本読んだだけで 物を言ってるのがバレバレだなw 347 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 19:44:20 ] >>346 >>>264で指摘しているように、ただ判定処理が書かれるコードの場所が変わってるだけだろ。 それがobject指向の目的だよ。 データと判定処理をクラスが持っていたら、クラスの所有するデータが増えるたびに、 そのデータの判定処理をするプログラムを書かなければいけないよ。 データそのものが判定処理を持っていれば、データを持つ所有クラスは何も改変せず、 自動的に処理されるよ。 >IsRequiredはゲッタのみかつ定数を返すようにしないとマズいだろう。 別にまずくないよ。設定するのが嫌だったら、初期値でfalseにしといて使いまわせばいいだけだよ。 >IsRequiredをインスタンスメンバとして実装しちまったら >外からMailAddressをセットできなくなるだろ。 MilAddressは、IsRequiredを所有するクラスなんだから、セットも糞もないよ。 何が困るのか実際のコードで示してくれよ。 348 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 19:54:53 ] >>347 ではCustomer.MailAddress1のIsRequiredはtrueであって欲しいとして、 Customerの外のクラスから MailAddress ma = new MailAddress(); ma.IsRequired = true; Customer.MailAddress = ma; とかされた場合、どうするの？ 349 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 19:55:40 ] ごめん ma.IsRequired = false; に訂正 350 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 19:57:14 ] っていうか、ここまで言ってまだ分からんかなあ。。 351 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 20:01:53 ] 横に長いコード書くなよ。うちの専ブラの使い方で見づらい 352 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 20:05:16 ] >>348 trueであって欲しいのに、 ma.IsRequired = true; をし、さらに Customer.MailAddress = ma; をすることが間違い じゃあ、 Form.TextBox1のVisibleはtrueであって欲しいとして、 Formの外のクラスから TextBox tb = new TextBox(); tb.Visible = false; Form.TextBox = tb; とかされる可能性は問題ないの？ むしろ、そんな設定をするほうが悪いんじゃないの？ 353 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 20:07:53 ] >>348 IsRequiredをtrueなりfalseと設定したいから、そう記述するんだろ？ お前はいちいちプロパティが改変されることを予見してすべてプログラムするのか？ 354 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 20:09:51 ] >>352 おいおい何を言ってるんだよトチ狂ったかw そもそも外（UI）から操作される値の話をしてるのに、 外から操作してはダメな値を操作するのがおかしい、ってどういう意味だよ。 もう一度>>230から読んで話の文脈をちゃんと理解して何かいってよ。 355 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 20:12:13 ] >>353 それこそOOPを理解してる？ 普通に考えれば、IsRequiredは外から操作されたくない値だろう。 >>230の意図はそうじゃないよ、って言いたいの？ じゃあまあ>>230の意図はおくとして、IsRequiredが外から操作されたくない 値だったら（普通にありふれたシナリオだと思うが）どうするの・ 356 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 20:15:42 ] >>354 おいおい、お前頭がおかしいんじゃないか？ なら、絶対に表示しなければならないGUI部品のTextBoxがあったとして、 そのTextBox.Visibleを絶対に変更されないような仕組みをわざわざ作る必要なんてないだろ？ 使う本人が分かればいいんだから。IsRequiredも同じだろ。 357 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 20:17:19 ] >>355 >普通に考えれば、IsRequiredは外から操作されたくない値だろう。 いや、汎用のクラスライブラリとしては、普通に操作できて当たり前だろ。 358 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 20:18:12 ] っていうか、正直>>230のような目的で>>251式にデータ自身に メソッドやプロパティを持たせるかどうかは意見が分かれるところだとは思うけど、 IsRequiredはクラスメンバの値を公開するようにすべき、ってのは まともなプログラマが100人いたら100人が同意する話だと思うぜ。 359 名前：デフォルトの名無しさん [2009/02/17(火) 20:19:25 ] 質問 bool値を返す関数ってよくIs〜って名前付けるよね？ でも『Ａ君はＢ君の方を見ていますか？』みたいな文の場合、 英語にするとDoes〜で始まると思うんだけど、 こういうときの関数名はどうするべき？ 360 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 20:21:00 ] >>359 CanASeeB 361 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 20:25:25 ] >>360 それ可能・不可能の意味合いに変わってるじゃないですか 362 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 20:25:53 ] >>356 外から変更されたくない値は変更できないようにしておくのが当たり前。 君は「アクセス修飾なんてぜんぶpublicでいいじゃん」っていう初心者様？ >>357 汎用クラスライブラリの話なんかしてないの。 ベタベタに特定用途専用のクラスの話をしてるんでしょ。 だいじょうぶかよ。 CustomerクラスのMailAddress1プロパティが必須かどうか、なんて値を 外から操作できてどうするんだよw もちろんそういう用途が皆無とはいえないはずだが、普通はないよ。 363 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 20:31:54 ] >>362 変更されたくない値かどうかは、設計者次第 汎用クラスとして設定できるようにしておいて、その継承クラスで隠蔽しておけばいいだけでしょ。 >>230の使い方もわからないのに、勝手に変更されたくないと決めつけて意見するほうが間違い。 とはいえ、汎用的に利用するために、IsRequireのようなプロパティは公開しとくのが当たり前だろな。 >汎用クラスライブラリの話なんかしてないの。 >ベタベタに特定用途専用のクラスの話をしてるんでしょ。 ユーザが入力した文字列のバリデーションなら汎用だろ。 勝手に特定用途専用なんて決めつけるほうがおかしい。 >CustomerクラスのMailAddress1プロパティが必須かどうか、なんて値を >外から操作できてどうするんだよw CustomerクラスのMailAddressプロパティなんて>>230は話してないだろ？ 何で勝手に自分の都合のいい解釈してんの？ それに>>317をみれば、それぞれのデータにIsRequiredプロパティがあるほうが わかりやすいだろ？ 364 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 20:32:26 ] >>359 A.IsLook( B ); でいーんじゃないかなぁ。もしくは A.IsLooking( B ); これで伝わると思うんだけど。。。 365 名前：デフォルトの名無しさん [2009/02/17(火) 20:44:00 ] >>362 業務ソフトは入力値のvalidationばかりだから それにリソースを取られないようにクラスライブラリ化するのは当たり前でしょ mailaddressの未入力を許可するみたいなのこそベタベタの汎用処理だと思うぞ 366 名前：デフォルトの名無しさん [2009/02/17(火) 21:02:15 ] ToN敗走 367 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 21:10:43 ] >>363 んもー鳥頭さん？ ＞それに>>317をみれば、それぞれのデータにIsRequiredプロパティがあるほうが ＞わかりやすいだろ？ まず最初に、そこは異論ないよ。 何度も言うように、意味論的にはオカシイんだけど。（正直これに違和感感じない人間にOOP論じる資格なし） ただ、何度も言うようにデータにIsRequiredがあるのは意味論的には間違ってるから、 （それは本来Customerクラスが知っているべきことだ）その当然の帰結として、IsRequiredを フールプルーフに出来なくなっちゃうよ、これって問題じゃないのかい、と言ってるの。 フールプルーフに出来なくなっちゃ、とは Customer.MailAddress1に触るコードを書くときは、MailAddress.IsRequiredの値を間違って 破壊しないようにCustomerクラスを使う人が注意を払わなきゃならんということ。 どっかのトンマがIsRequiredを間違って破壊しちゃう可能性が機構的に排除できないってこと。 >>365 自分で自分の足を（撃とうと思えば）撃てるのはかまわないが、 安全装置を（組み込もうと思っても）組み込めないようなライブラリなんかに価値はないよ。

---

---

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

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