クラスを作るとメソッドの数が多くなりすぎる

クラスを作ると，たいがい，メソッドの数が多くなりすぎて，メソッドをさがすのに一苦労します．

なにか，クラスのメソッドの設計でいい方法はないでしょうか？

メソッドが増えすぎる原因として，

・フィールド変数１つにつき，取得メソッド，設定メソッドで(最大)２つ必要．

ということがあります．
あと，

・private のメソッド（クラス内部でよく使われる手続きをまとめたもの）が結構必要．
・private のメソッドから呼び出す private のメソッドが結構必要．

ということがありますが，publicメソッドがこれらのメソッドと紛れてしまう，ということがあります．

No.4 ベストアンサー 回答者： Healer99 回答日時： 2006/04/21 14:19

>> 4.privateメソッドの一番外側のメソッドをprotectedにしてそれ

>> を内部クラスかスーパークラス化し、コーディングが頻繁に発生
>> する部分のメンテナンス性を向上させる。
>私の基本的知識不足で完全に理解しきれないのですが，
>非常に役に立ちそうなテクニックのような予感がします．

たとえば doSomething() というpublicメソッドが、doMiddle()というprivateメソッドを呼んでいて、なおかつさらにdoBase()というprivateメソッドが呼ばれているとします。もちろんdoBase()の下にいくつも下位メソッドがあっても構いません。

最初はdoSomething()だけでよかったのが、仕様変更の積み重ねでdoAdd1() doAdd2()と増えていき、そのたびにdoMiddle()に変更が頻繁に発生するがdoBase()は特に変わらないという場合に、メンテしたいのはdoMiddle()だけなので、doBase()はそのクラスの中に実装されている必要はないので、doBase()をprotectedメソッドとした配下ロジックを継承元クラスとして、クラス分けすることができます。

実際にはこんな簡単なケースではないのですが、だいたいぐちゃぐちゃなプログラムというのは、ひとつのメソッドですべて解決しようとしていたり、ロジックが部品化されておらず何百行にわたるメソッドになっていたりします。

それをリファクタリングして、共通に使われる部分、個別で使われる部分の線引きをすれば、共通で使われる部分を継承元として、機能別に小さなクラス(またはメソッド)の集合となり、実際にはかなりの仕様変更に耐えることが多いです。

クラス数が増えることに難色を示す人がいますが、クラス数を増やさないといけないのは、それだけシステムに機能数が増えていることの現れなのです。

また混乱されている原因のうち、プログラマがシンプルに実装出来していない以外の問題として、たまにjavaを正しく理解していない設計者が実権(?)を握っていたりすると、継承回数を抑制したり、機能は減らさないのにメソッド数を抑制したりして実装プログラマや稼動後のメンテナンスプログラマに負担をしいている場合がありますね。

あとアジャイルについては、指摘された本は知りませんが、とにかく「シンプル」に「軽く」作ることですね。

この回答への補足

書いていただいたこと，すべてなるほどです．

>共通で使われる部分を継承元として、
>機能別に小さなクラス(またはメソッド)の集合となり、
>実際にはかなりの仕様変更に耐えることが多いです。

メソッドで共通コードを抽出というのは考えたことがありましたが，スーパクラスでというのはちゃんと考えたことがなかったです．なるほど．

>クラス数が増えることに難色を示す人がいますが、・・

そうですね．

非常に参考になりました．　

補足日時：2006/04/22 03:17

No.3 回答者： Trick--o-- 回答日時： 2006/04/20 16:17

どんなクラス設計をしているのかによりますが……

「private のメソッドから呼び出す private のメソッド」をまとめてひとつのクラスにします。このとき、privateからprotectedに変えます。
今作っているクラスを分離させたクラスを継承する形にします。

継承・スーパークラス・サブクラスは分かりますよね……？

参考URL：http://www.nextindex.net/java/inherit.html

この回答への補足

「private のメソッドから呼び出す private のメソッド」を減らすという意味で継承を使うという方法があったのですね．なるほど．これならメソッドをまとめて減らすことができますね．

補足日時：2006/04/20 22:07

No.2 回答者： Healer99 回答日時： 2006/04/20 00:05

ソース上に決まったマークをつけると良いかも知れません。

実際は質問者さんの困っているようなクラスは、クラス設計としてはNo.1さんの指摘のように落第なんですが、とはいいつつも昔のシステムをjavaで書き直したり、または下手なプログラマが集まって作ったシステムではメソッドの数がgetter/setterを別としても100ほどあったりして、一体そのクラスが何をするものなのか、あるいはクラス名とは別のクラスになっていたりはちゃめちゃです。

ということで最近はやりのアジャイル的手法な提案ですが、

1.クラスの役割を可能な限り限定する。
2.getter/setterを先頭か最終にまとめて書き、またメソッドも似た機能ごとに分けて書いて、エディタのタグジャンプやマークの機能を活用する。
3.さらに、javaDocコメントを可能な限り完璧に書いて、ある程度コーディングしたら警告すらもないjavaDocドキュメントを作成し(Eclipseでは簡単に作成できますし、ant化も簡単です)、ソースとjavaDocを併用するように心がける。
4.privateメソッドの一番外側のメソッドをprotectedにしてそれを内部クラスかスーパークラス化し、コーディングが頻繁に発生する部分のメンテナンス性を向上させる。

というところでしょうか。私はこれらを実践しているので、自分のソースは勿論のこと他人のソースでもメンテナンスに困ることはあまりありません(数千本のソースを扱うこともザラにあります)。

この回答への補足

大変具体的で，かつ（表現も含めて）丁寧なご回答をありがとうございました！

> 1.クラスの役割を可能な限り限定する。
> 2.getter/setterを先頭か最終にまとめて書き、
> またメソッドも似た機能ごとに分けて書いて、
なるほど．そう心がけるようにします．

> エディタのタグジャンプやマークの機能を活用する。
これは，メソッドを抽出して，メソッドへのアクセスを良くすると言うことですね．

> 3.さらに、javaDocコメントを可能な限り完璧に書いて、ある程
> 度コーディングしたら警告すらもないjavaDocドキュメントを作
> 成し(Eclipseでは簡単に作成できますし、ant化も簡単です)、ソ
> ースとjavaDocを併用するように心がける。
Eclipseは使っていますが，javaDocは「併用」とまでは使っていませんでした．
心がけるようにします．
(参考にしたいのですが，javaDocは印刷されていらっしゃいますか？)

> 4.privateメソッドの一番外側のメソッドをprotectedにしてそれ
> を内部クラスかスーパークラス化し、コーディングが頻繁に発生
> する部分のメンテナンス性を向上させる。
私の基本的知識不足で完全に理解しきれないのですが，
非常に役に立ちそうなテクニックのような予感がします．

もう少しだけ詳しく解説お願いしてよろしいでしょうか？
情報へのポインタ（本，URL）でも結構ですので・・

> 私はこれらを実践しているので、自分のソースは勿論のこと他人
> のソースでもメンテナンスに困ることはあまりありません(数千
> 本のソースを扱うこともザラにあります)。
大変勇気づけられますし，私も目標にしたいと思います．
おかげさまで希望の光が見えてきました．

あと，「アジャイル」というのが役に立ちそうなのですが，
おすすめの分かりやすい本などございますでしょうか？
検索したところ，
http://www.amazon.co.jp/exec/obidos/ASIN/4894715 …
などがひっかかりましたが・・．

補足日時：2006/04/20 09:04

No.1 回答者： Trick--o-- 回答日時： 2006/04/19 15:44

必要の無いものを削る。

外部から参照しない変数にはGet/Setを作らない

privateメソッドとpublicメソッドが紛れる、というのは具体的にどういうこと？
命名を工夫したり、書くときに分けて書くように気をつければそんなことも無いと思うけど。

コメントはちゃんと書いてる？
コメントを書いておけば、探すときに検索用のキーワードが考えやすいでしょう。

ごちゃごちゃになるのなら、改良の余地があると言うこと。
クラスの継承などを使えば、一つ一つのクラスは小さくなるんじゃないかな。