クラス名・変数名に迷ったら書き込むスレ。Part28 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
クラス名、変数名のつけ方に悩んだら書き込むスレです。 命名規則や設計の善し悪しについて議論するのは基本的に禁止。 前スレ クラス名・変数名に迷ったら書き込むスレ。Part27 http://echo.2ch.net/test/read.cgi/tech/1476572490/ 無関係スレ 設計・命名スレ http://echo.2ch.net/test/read.cgi/tech/1477368563/ 設計から喧々諤々されたい殿方は別スレがございますので、そちらをご利用ください。 データベース的なものを想像して欲しい。 あるデータ群(オブジェクトの配列)を画面出力するとき、出力イベントをフックして ・「表示/非表示」を切り替える(単純にreturn falseだけで済むような処理ではない) ・「見た目」を切り替える(色変更や予め用意した画像に変更など) の2つが必要なとき、それぞれどんな単語を使えばいい? 紛らわしくなく、かつ統一感のある関数名にしたい。 上記2つは呼び出すタイミングが微妙に異なるため、一括にはしにくい。 また、出力を切り替えると言っても、実際には個々のオブジェクトに含まれている値やメンバ変数を読み込み、 その設定を適用させるといった内容になる。 ありがとう、それでいく 出社前にスレ確認できてよかった 通信やファイルへ書込を伴う処理で 一旦変数に代入(書き込み予約)してから、任意のタイミングで確定させて処理したい 確定処理ってupdate? apply? commit? finalize? save? それとこの場合の代入ってsetでいい? stageとcommitかな でもwriteやsendといった実際の物理的な動作をイメージさせる名前を差し置いてまで強調するようなことだとは俺は思わないけどな 抽象的な名前は基本的に糞 ReserveFoo()とかが並ぶのか 代入の接頭詞はset、みたいなイメージあると代入にしろ確定にしろ結構離れる感じね >>10 一応、write()と同じくらいのレベルでsave()を想定してた >>7 その言語でよく使われているORマッパーとか参考にすると 他の人にも理解してもらえそう setかどうかはmodelかviewかによるかな modelならset >>7 BufferedFile f; f.write(data); f.flush(); BufferedConnection c; c.write(data); // or c.send(data) c.flush(); Series を列挙する型と、それを格納する変数。 C# だと enum Series { A, B } Series Series; とできなくはないけど、別にしたい。 たいていは列挙の方を複数、変数を単数にするんだけど、複数と単数で変化がないものはどうしたもんか。 >>15 靴に足を合わせた方がいいと思うよ 型名と変数名が同じだと気持ち悪いという感覚が時代遅れだから、 名前を小細工するより自分の感覚を修正した方がいいんじゃないかしら >>15 型名は大文字から、変数名は小文字から始めればよい 1年後に1画面に入らないくらいまで広がっててsってなんだっけー んー、時代遅れか。 C# の例は挙げたけど、できない言語の場合にどうしようかってのもあったんだがな。 大文字小文字の場合も。 これといった案はなさそうだね。 いろいろ意見ありがとう。 >>21 > できない言語の場合にどうしようかってのもあったんだがな。 > 大文字小文字の場合も。 enum SeruesOption {A, B} SeriesOption series = A 最初の質問で「できなくはないけど」と言いつつ 「できない言語の場合」って追記するの、ちょっとずるくない? >>23 やり取りを円滑にするために最初に忘れず言おうな、とは思う。 が、ズルくはないだろ。 それで質問者が何か得したわけでもないし、 君が何か論破された訳でもないんだから。 まあできない言語なら >>16 みたいな回答はないから初めから書いとけ って言うのは正しいと思う でももう終わった話だしいちいち蒸し返す意味ない 言語に関わらず共通のスタイルを使うという発想自体がそもそもの大間違い 郷に入れば郷に従え C#では型名とプロパティ名に同じ名前を付けることが推奨されていてenumにXXEnumみたいなのは禁止されている 他の言語には違ったルールがある、それに従うだけ その良し悪しを判断するのはお前でもこのスレでもない あとC#ならenumの型名にs付けていいのはビットフラグの場合だけだ 型の名前は型自身じゃなくてインスタンスの性質を表しているべきだって 発想かもしれんけど、拡張メソッドの入れ物の静的クラスにExtensionsなんてのもあったりして ちょっと統一感ないね >>29 インスタンスの性質は分かるけど、型自身の名前って例えばどんなの? Extensions だって性質を表してるんじゃない? 詳しく表してるとは言い難いけど。 The name of a type should express the charactor of not a type itself, but the instance 確かに、やや低レベルな名前って気はするかな 具体的にどうすればいいかは分からんけど 現時点ではスレチだけど、いずれ設定周りの名称に出没しそうなのでご容赦ください。 スタンドアロンのシステムが既に稼働していますが、一部機能をクラウド化して併用する計画があります。 クラウド化してもスタンドアロンの方もそのまま運用を続けます。 いわゆる半クラウド?とでも言うのでしょうか、このようなシステムの場合、 何と呼べばいいでしょうか? >>34 ありがとうございます。 色々調べましたが、ハイブリッドクラウドとは パブリッククラウドとプライベートクラウドなどの複数のインフラ周りを 組み合わせた場合に呼ぶようです。 サーバーデータの保全や負荷分散という説明も見ると、 今回のケースに該当するのかというと、う〜ん。。。 単項検証: SingleFieldValidation 相関検証: MultiFieldsValidation データベースで行と行を比較する検証や表を超えて検証する場合はなんと言いますか? 日本語と英語の両方ともわからない >>36 相関 correlated 行 row または record 表 table ちょっと物事を単純化して話しますが オブジェクトの有効期間を変数として持たせたいんです リストの中にぶっこんでいって リストを触る奴がその値によってリストから削除したりをさせたい このとき、有効期限をどう表現しますか? 色々考えた結果 long lifetime = now + duration; と初期化しておいて if (obj.lifetime < now) list.remove(obj); というふにしました もっと名前、初期化、運用に他のやり方があったかなと心配しています 名前は単にtime_to_removeでもよかったかなと思ってます >>38 有効期限が本当にそのオブジェクトが管理すべき情報なのか、それともそのオブジェクトを使う側が 管理すべき情報なのか、それだけじゃ分からんけど、前者だとして CreationTime(作られた時) LifeSpan(寿命) TimeToLive(余命 CreationTime + LIfeSpan - now) IsAlive(TimeToLive > 0) こんだけの情報を持たせた方が扱いやすいかも >>39 ありがとうございます見てみます >>40 expireは既に別のとこで使っておりまして >>41 もう少し正確にお話すると class WithLifetime<T> { public final T org; public final long lifetime; WithLifetime(T org, long duration) { this.org = org;this.lifetime = System.currentTimeMillis() + duration; } } こういうのを list.add(new WithLifetime<Foo>(foo, TimeUnit.HOURS.toMillis(5))); こう使ってますね あくまでlistありきで list中の生存期間を、listを使う側の都合で勝手に決めてるという List<Foo> listのままで、Map<Foo, Long> lifetimeみたいなのを併用 っていうのも最初は考えたりもしたんですが、それでいくと list0, map0, list1, map1, list2, map2みたいな煩雑さがチラついてきますんで この形式にしました >>42 そのlistを拡張した方がいいんじゃないの 管理対象のobjectは何も知らない方がいい listを使う側も同期とか以外は知らなくていいくらいに そしたら汎用でも使える >>43 ありがとうございます とても有力な手だと思います ただ、みなさんも覚えがあるかもしれませんが こういうコンテナラッパーを気軽に書いても 意外とスッキリしていかねえな、ということです 1) 最初から十分なインタフェースをそろえるのはめんどい(主に指の疲労) 2) だから最初はsize, add, removeくらいで始めるのだが あとで結局また加筆していくことになる 3) コンテナクラスの理想は中身を知らないこと でもこういう作りにするとそこに想定が入ることになる だからと言ってすぐ困りはしないが、そのことに小さい不満が残る removeExpired()みたいなこともさせたいが、何か不満が残る それに引数を与えてやりたいが、ここでその引数の名前が難しすぎる 何をどういう基準でremoveしてるかを表現しきるメソッド名も難しい 最後までぐだぐだ申しましてすみません 不満ばかりできりが無いのでこれにて閉じさせてくだしあ >>44 remove_if(predicate) >>45 もしくはその知恵がないかやりたくない理由があるんだろ >>44 の文章見るとなにか異様にこだわりあるみたいだし 俺は同じような状況でexpires_onにしたことがある Optionsみたいに複数形ってクラス名には不適切? OptionBagか OptionsBagにすべき? ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる