- 締切済み
Javaのクラス生成について
「クラスを作成せよ」と言われたら、フィールドだけでなくメソッドも定義すべきでしょうか? 簡単な質問で申し訳ありませんが、宜しくお願い致します。
- みんなの回答 (3)
- 専門家の回答
みんなの回答
Javaだけでなく、どんな言語にも通じる話だと思います。 まずデータ保存や退避の目的のみのクラスを作成する事はあり得ます。カプセル化の方針に合うからです。カプセル化とは、データ構造を作れです。こういう場合、目立ったメソッドはほとんどありませんが、どんなクラスを作成する時でも、コンストラクト(Defaultの初期化メソッド)とデストラクタ(Defaultの後処理メソッド)を付けるのは、作法になってる気がします。なので多くの言語でこれらは、自動化されてる事も多いです。 次にフィールドのみか?ですが、そう考えるのであれば、フィールドか?プロパティーか?も検討すべきでしょう。結局#2さんの仰るように、何の目的でクラスを使用するのか?です。 プロパティーとメソッドの検討は、プログラムの中でのその位置付け(目的)をはっきりさせないと、クラスがサブルーティン置き場(捨て場?)に化したりします。 位置付けの明確化を前提に自分は、プロパティー,メソッドも含めて、密集積かつ疎結合の原則に従います。 要するに関係するものだけを集めて(密集積)、そのクラスにとって外部環境と思えるものとの抱き合わせは、抱き合わせが便利であっても避けます(疎結合)。こうするとモジュールの独立性が高まって再利用しやすくなり、プログラム単位の意味も明確化されるからです。 ここで注意すべきは再利用とは、プログラム開発後のメンテナンスや使いまわしだけの事でなく、開発中のモジュールの再利用や使いまわしの方が、圧倒的に多いという事です。 ここで難しいのは、クラスにとっての外部環境とは何か?(クラス境界は?)です。これは開発者の判断になります。個人的にこの判断は、「実行者を探せ」で自分は行っています(オブジェクト志向の5W1Hの簡略版)。 例えばデータ構造をクラスとして作成したら、そのデータ構造の内部論理に従う処理だけを、そのクラスにメソッド,プロパティーとして持たせます。データを使用する論理などは、それの使用者(クラスで、多くの場合プログラムのメイン部分)で実装します。 違う考えはもちろんあります。ありますが経験的にものになるなと思えたのは、上記のようなやり方でした。 しかし密集積・疎結合の原則に忠実に従うと、クラス間の相互依存度はどんどん高くなっていきます。またコード量も倍になったりするのはザラです。結局、自分は何を重視するか?です。 つまり、クラスを全面採用するなら(オブジェクト志向すると決めたなら)、ある程度最初から「俺はライブラリを作るのだ」という覚悟が必要になります。覚悟がないなら、やらない方がましです。 クラス作成とは、問題状況に特化したライブラリを作る事です。実際にはそこでは、普通の手続き型プログラミングよりも、プログラムの初期設計の完成度の良し悪しで、最終的な出来が左右されます。 この辺りの事情が実は最初のカプセル化の概念と裏で本質的につながっていて、オブジェクト志向はいくら読んでもようわからん、という事態になります。大概、やってみなけりゃわかりません(^^;)。 ちょっと脅かしましたが、「俺はオブジェクト志向なんかやらないのだ(^^)」という書き方もある訳です。その場合はクラスを、単なる初期化ルーティン便利機能付きデータ構造、とみなしても良い訳です(コンストラクタを除けば、フィールドのみ)。同様にサブルーティン置き場としてのクラスだってありえます(コンストラクタ無しのメソッドのみ)。 やっちゃいけないのは、開発スタイル(方針)を混ぜる事です。たいてい最後には収拾がつかなくなっています(^^;)。 まず自分のやりたい事を眺めましょう(^^)。