- - PR -
拡張クラスの命名規則
投稿者 | 投稿内容 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2008-04-11 20:24
皆さんレスありがとうございます。
まさしくその通りだと思います。 今の時点でも既にかなり分かりづらいし・・・ ちなみに その「ちょっとした拡張」というのが、 JdbcServiceImplで言うと テーブルまでもがフレームワークにデフォルトで定義されているのでそれを自分のテーブルに合わせて変更するような場合です。取得するカラム追加やカラム名がデフォルトと違うとかそういうような変更だったりするのです。 インタフェースを直接implementする場合は、クラスの役割を考えて容易に命名できるのですが、上記のような「拡張」がかなり多くなりそうだった上に、息の長いプログラムになりそうだったので、後のことを考えてルールを作ったほうが良いのかな、と悩んでいました。 最初は、プロジェクトの省略名称なんかをプレフィックスで追加しようと考えていたのですが、そういえば、世の中の皆さんはどうしてるのかな、と気になったので質問した次第です。 質問の仕方が下手ですみませんでした。
FileAccessServiceImplやJdbcServiceImplを指しています。 区別するために「クラス」と書きました。 | ||||||||||||
|
投稿日時: 2008-04-11 23:11
(名前は難しいですね。。。)
方向がいろいろあるのではっきりしないですが。。。。。 被せ系なら JdbcServcieImpl JdbcServcieImplWrapper JdbcServcieImplWrapperExtender JdbcServcieImplWrapperExtenderHelper JdbcServcieImplWrapperExtenderHelperAdapter (わけわからん!!) 抽象系なら(より抽象的になる。。。) JdbcServcieImpl dbService db or Service (わけわからん!!) 参考になればと思います。 | ||||||||||||
|
投稿日時: 2008-04-12 10:37
業務でやっていると、システム名の略称が頭に作ってパターンが多いんじゃないかな?
JdbcServcieImpl の例で言うならば、システム名がHogeだとして、HogeJdbcServcieImpl みたいな。 もちろん、明確な「ここをこう拡張した」って箇所があるならば、それが伝わる方がベターかとは思います。 | ||||||||||||
|
投稿日時: 2008-04-13 01:17
本題とは関係ないですが、
ホントですか?Java で? ひょっとして、テーブル名とか全部 HogeUserMaster とか付けるわけですか? どんなメリットがあるんでしょうか。 | ||||||||||||
|
投稿日時: 2008-04-13 01:20
そういうときは名前空間のほうがいいような・・・。
| ||||||||||||
|
投稿日時: 2008-04-13 08:03
>flatlineさん
Hogeシステムとして、HogeUserMaster までは付けないと思います。 ですが、HogeDateとか、HogeMessageとかHogeStringUtil とか辺りまでは付ける事はあると思います。 クラス名が一般的過ぎて、クラス名が重複してしまうのを避けるのが目的です。 名前空間が違うから重複してもOKというのが本来の考え方ですが、 ・hoge.Date で java.util.Dateをラップした場合にコードが読みにくい ・一般の開発者がEclipseのコード保管等で楽に使用できる と言った効果はありますから。 ・・・ただ、元請サマのよく解らないコーディング規約で 「全てのクラス名はシステム名(Hoge)で始めなくてはならない」 ってのを押し付けられたって経験もあります(笑) 結局はバランスかと思いますが、開発者が利用しやすいように適切なところに付けるのが望ましいかと。 StringUtilなどは一番悩むところです。 Commonsにもあるし、一般的なフレームワークにもある名前だし、さらにシステム固有のStringUtilを作るとStringUtilだらけになる、そんな経験はないですか? ※どっちが良いか?ってのは宗教戦争なんでやらないでください。 | ||||||||||||
|
投稿日時: 2008-04-13 09:02
イスて色々なデザイナーがいて面白いデザインが沢山あります。
しかもイタリア製など高価なんです。。。 クラスも同じで色々なデザインがあります。。。 どちらも言える事は座り心地が良くないと イスからずり落ちやいます。。。 (名前空間もクラス名も座り心地のよい場所に。。。。。) >わたなべさん(関係ないですが) 気持ちはわかりますが「宗教戦争」は良くないですね ガンジーは非暴力、ダライラマも非暴力。。。。 イデオロギーの違いぐらいで。。。(ところで北京五輪どうなんの?) | ||||||||||||
|
投稿日時: 2008-04-13 14:45
設計が気持ち悪いというのは置いといて。単純にサブクラスにテーブル名を含めていったら良いと思います。
ちょうど、今、この問題で悩んでます。私も普通なら役割に合わせてクラス名を付けるんですが…。ある業務システム固有の GUI ライブラリとして簡単な Swing のサブクラスを作ることになりまして。たとえば JTextField のサブクラスを作って、この業務システムでの共通仕様を盛り込みます。フォーカス状態で背景色が変わるとかエンターキーでフォーカス移動するとか。 Ex とか付けちゃう?ださーい。システム名 Hoge とか付けちゃう?ありえなーい。名前空間が違うから TextField でいいのか。awt と被るよなあ、とか悩みました。 私が出した結論としては、名前空間だけが異なるのは良くない。クラス名自体も異なっているべき。Eclipseってすごく便利で自動的に import 追加してくれるでしょう。TextField とか書いて適当にエンターキー押していくと、自作の名前空間ではなく java.awt が import に追加されちゃったりするんですよね。なので名前空間だけで区別するのは間違いのもとと結論付けました。 それでも、Ex とか Hoge とか、なんだかなーと思っていて。どうにかならんかなと。今回は、JTextField のサブクラスを扱うデータの型ごとに用意することにしたので、 JTextField └ AbstractField<T> (背景色やエンターキー移動が実装されてる) ├StringField (String を扱う getValue/setValue を持つ) ├NumberField (Number を扱う getValue/setValue を持つ) └DateField (Date を扱う getValue/setValue を持つ) という設計にしました。もし、背景色やエンターキー移動のような業務システム特有の共通仕様だけを実装したクラスのときはどうしたらいいのかなあ。やはり、Hoge、Ex、Base あたりを付けるのが無難かと思ってます。 |