- PR -

拡張クラスの命名規則

投稿者投稿内容
わんこ
常連さん
会議室デビュー日: 2003/04/30
投稿数: 46
投稿日時: 2008-04-11 20:24
皆さんレスありがとうございます。

引用:

そのフレームワークのようにメソッドをオーバーライドしてクラスをちょこちょこっと改造することを前提としたクラス設計は、運用上は大部分の人にに分かりやすく、使って便利かもしれませんが、泥臭いクラス設計だと思います




まさしくその通りだと思います。
今の時点でも既にかなり分かりづらいし・・・

ちなみに
その「ちょっとした拡張」というのが、
JdbcServiceImplで言うと

テーブルまでもがフレームワークにデフォルトで定義されているのでそれを自分のテーブルに合わせて変更するような場合です。取得するカラム追加やカラム名がデフォルトと違うとかそういうような変更だったりするのです。

インタフェースを直接implementする場合は、クラスの役割を考えて容易に命名できるのですが、上記のような「拡張」がかなり多くなりそうだった上に、息の長いプログラムになりそうだったので、後のことを考えてルールを作ったほうが良いのかな、と悩んでいました。

最初は、プロジェクトの省略名称なんかをプレフィックスで追加しようと考えていたのですが、そういえば、世の中の皆さんはどうしてるのかな、と気になったので質問した次第です。

質問の仕方が下手ですみませんでした。


引用:

ここでの「親クラス」って FileAccessServiceImpl や JdbcServiceImpl のことでしょうか?クラスと書かれていることから考えると DataAccessService ではないのですよね?
だったら DataAccessService は考えなくて良いと思います。DataAccessService まで考えたほうが良いという場合は、クラス階層が先祖がえりになってしまっているのかもしれません。



FileAccessServiceImplやJdbcServiceImplを指しています。
区別するために「クラス」と書きました。

indigo-x
大ベテラン
会議室デビュー日: 2008/02/21
投稿数: 207
お住まい・勤務地: 太陽の塔近く
投稿日時: 2008-04-11 23:11
(名前は難しいですね。。。)

方向がいろいろあるのではっきりしないですが。。。。。

被せ系なら
JdbcServcieImpl
  JdbcServcieImplWrapper
JdbcServcieImplWrapperExtender
JdbcServcieImplWrapperExtenderHelper
JdbcServcieImplWrapperExtenderHelperAdapter (わけわからん!!)

抽象系なら(より抽象的になる。。。)
JdbcServcieImpl
  dbService
   db or Service (わけわからん!!)

参考になればと思います。
わたなべ
大ベテラン
会議室デビュー日: 2007/12/09
投稿数: 123
お住まい・勤務地: 札幌
投稿日時: 2008-04-12 10:37
業務でやっていると、システム名の略称が頭に作ってパターンが多いんじゃないかな?
JdbcServcieImpl の例で言うならば、システム名がHogeだとして、HogeJdbcServcieImpl みたいな。
もちろん、明確な「ここをこう拡張した」って箇所があるならば、それが伝わる方がベターかとは思います。
flatline
大ベテラン
会議室デビュー日: 2005/09/22
投稿数: 102
投稿日時: 2008-04-13 01:17
本題とは関係ないですが、

引用:

業務でやっていると、システム名の略称が頭に作ってパターンが多いんじゃないかな?
JdbcServcieImpl の例で言うならば、システム名がHogeだとして、HogeJdbcServcieImpl みたいな。



ホントですか?Java で?
ひょっとして、テーブル名とか全部 HogeUserMaster とか付けるわけですか?
どんなメリットがあるんでしょうか。
otf
ベテラン
会議室デビュー日: 2006/08/04
投稿数: 91
投稿日時: 2008-04-13 01:20
そういうときは名前空間のほうがいいような・・・。
わたなべ
大ベテラン
会議室デビュー日: 2007/12/09
投稿数: 123
お住まい・勤務地: 札幌
投稿日時: 2008-04-13 08:03
>flatlineさん
Hogeシステムとして、HogeUserMaster までは付けないと思います。
ですが、HogeDateとか、HogeMessageとかHogeStringUtil とか辺りまでは付ける事はあると思います。
クラス名が一般的過ぎて、クラス名が重複してしまうのを避けるのが目的です。
名前空間が違うから重複してもOKというのが本来の考え方ですが、
・hoge.Date で java.util.Dateをラップした場合にコードが読みにくい
・一般の開発者がEclipseのコード保管等で楽に使用できる
と言った効果はありますから。

・・・ただ、元請サマのよく解らないコーディング規約で
「全てのクラス名はシステム名(Hoge)で始めなくてはならない」
ってのを押し付けられたって経験もあります(笑)

結局はバランスかと思いますが、開発者が利用しやすいように適切なところに付けるのが望ましいかと。
StringUtilなどは一番悩むところです。
Commonsにもあるし、一般的なフレームワークにもある名前だし、さらにシステム固有のStringUtilを作るとStringUtilだらけになる、そんな経験はないですか?
※どっちが良いか?ってのは宗教戦争なんでやらないでください。
indigo-x
大ベテラン
会議室デビュー日: 2008/02/21
投稿数: 207
お住まい・勤務地: 太陽の塔近く
投稿日時: 2008-04-13 09:02
イスて色々なデザイナーがいて面白いデザインが沢山あります。
  しかもイタリア製など高価なんです。。。
    クラスも同じで色々なデザインがあります。。。

どちらも言える事は座り心地が良くないと
  イスからずり落ちやいます。。。

(名前空間もクラス名も座り心地のよい場所に。。。。。)



>わたなべさん(関係ないですが)
  気持ちはわかりますが「宗教戦争」は良くないですね
   ガンジーは非暴力、ダライラマも非暴力。。。。
    イデオロギーの違いぐらいで。。。(ところで北京五輪どうなんの?)  
未記入
大ベテラン
会議室デビュー日: 2008/02/07
投稿数: 115
投稿日時: 2008-04-13 14:45
引用:

ちなみにその「ちょっとした拡張」というのが、JdbcServiceImplで言うとテーブルまでもがフレームワークにデフォルトで定義されているのでそれを自分のテーブルに合わせて変更するような場合です。



設計が気持ち悪いというのは置いといて。単純にサブクラスにテーブル名を含めていったら良いと思います。

引用:

システム名の略称が頭に作ってパターンが多いんじゃないかな?



引用:

そういうときは名前空間のほうがいいような・・・。



ちょうど、今、この問題で悩んでます。私も普通なら役割に合わせてクラス名を付けるんですが…。ある業務システム固有の 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 あたりを付けるのが無難かと思ってます。

スキルアップ/キャリアアップ(JOB@IT)