アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
NGワード (スコア:0)
いくつかの駄目な単語ってのがきっとありますね。
私が退場願いたいと思う筆頭の単語は
●管理
●情報
です。
「Hogehoge管理」関数(とかテーブルとか)という名前の奴は
「管理」をはずして「Hogehoge」だけにすべきです。
「情報」も同様。
何故かって、そりゃ、管理とか情報とかってのは「いうまでもない」からです。ソフトで扱ってるからにゃ「管理」の対象であるのは当然だし、「情報」であるのも大抵当然でしょう。
英語名(物理名)や略語もですよ。InfoとかMngとか。それいりませんから。
あと先日コーヒー吹いたネタとして…
テーブル名に「テーブル」「Tbl」って接尾語をつけるのは勘弁な。
#ただでさえ貴重なOracleのテーブル名文字数限界が…orz
単に冗長だからウザイというだけじゃなく、
例えばテーブル名に「社員」じゃなく「社員管理」と書いてあると、
どうも社員そのもの以外の情報も混ぜていい、という空気が発生するっぽいです。
つまり正規化が崩れる。駄目テーブルになる。
Re:NGワード (スコア:1, 興味深い)
Hogehogeの実体と、その情報のみを収めたものと、複数のHogehogeを管理するもの全てにHogehogeって付けるの?
私だったらHogehoge / HogehogeInfo / HogehogeManagerみたいに使い分けるけどなぁ。
Re: (スコア:0)
まず「それは分けすぎ」である可能性を考慮したほうが良いと思います。
たとえばBuilderやFactoryなんてものは、
システム上に1つしか存在しないならClassそのものがやるべきで、
それがやりにくい(Javaのような)言語は開発向きではないのです。
複数あるなら当然ですがそれぞれに区別可能な名前がつくから問題ないし。
次に。「情報のみを収めたもの」って何でしょう?「実体」とどう違うのでしょう?
そのまんまじゃないでしょうか?だとすれば分ける意味がなさそうです。
そ
Re: (スコア:0)
Hogehogeクラスはアクセッサ+α程度の簡易なクラスで、
ロジックはHogehogeManagerに持つんじゃないでしょうか。
マーチンファウラーの言うt「ドメインモデル貧血症」の典型パターンであり、
OOPの原則である「データとロジックの融合」に反するモデルではありますが、
規模が大きくなれば自動生成で楽できる部分もかなりあるし、エンティティの
変更にも強くなります。
#見やすいプログラムになるかどうかは結局のところルールより担当者のスキルですけどね
Re: (スコア:0)
>ロジックはHogehogeManagerに持つんじゃないでしょうか。
「ロジック」と呼んでるのに
なんで「Logic」じゃなく「Manager」という
新しい(しかしそれ自体に何の"意味"もない)単語を
導入する必要が有るのかが、ちょっと不思議です。
よしあしはさておき Web MVC2 連中のあいだでは、
そういうクラスはそれこそHogehogeLogicと命名する
という文化なんじゃないでしょうか?
ところでついでですが、
個人的にはLogicもあまり好きな単語ではないです。
というか「ビジネスロジック」という言葉じたいサ
Re:NGワード (スコア:1, 興味深い)
Re: (スコア:0)
少なくともメタ機能を作るなどの一部特殊な場合では、認めたほうが絶対にいいですね。
ただ、濫用すべきでないという指摘なら納得できます。
実際によく見かけるManageやInfoという単語でDB定義一覧が埋め尽くされたシステムは、読みづらくてたまりません。
それらの単語片が、名前の違いを言わば希釈してしまうんです。違いが目に飛び込んでこなくなる。
Re:NGワード (スコア:1)
んー、テーブルかビューかの判別ではないでしょうか?
あと、マスタ系テーブルの区別を入れてるのもよく見ます。
接頭辞ですが、m_xxx(マスタ系) t_xxx(データ系) v_xxx(ビュー)みたいな感じ。
Re: (スコア:0)
ビューありませんでしたorz
#マテリアライズドビューという落ちでもなかった。
Re: (スコア:0)
テーブルやビューと区別する上ではそんなに気になったことないけどなー
#というか、文字数限界まで達したことないけど、そんな長いの?w
#むしろそっちの方が問題じゃ
##というか、アナタのオレオレ規約はちょっと勘弁だな
Re: (スコア:0)