 |
|
|
| 前のページ 1 2 3 4 次のページ
|
|
| メソッド
|
メソッドにコーディング規約を適用させることでバグを減少させることができます。難しい規約ではありますが、後のテストや修正を考えたときには非常に有用な規約なので是非とも守ってください。
|
| オーバーライドさせたくないメソッドはfinalを利用する（CMTD001）
|
これもクラスのfinal宣言と同様です。メソッドをfinal宣言する判断基準は難しい問題ですが、デザインパターンにおけるテンプレートメソッドパターンなどのクラスの整合性を崩してしまうようなメソッドについてはfinal宣言をしてください。
しかし、最近のJavaの実装の再利用はabstractクラスを継承するのではなく、interfaceを利用して委譲をすることが多くなってきています。interfaceを利用する場合は、そもそも実装の継承はできませんので、final宣言を行う必要のあるシチュエーションは減少傾向にあります。Java 1.3からjava.lang.reflect.Proxyクラスの登場にともない、委譲をより便利に実装できるようになったこともこの傾向を加速させています。
|
| サイズが0の配列を利用する（C_MTD002）
|
返り値が配列のメソッドで、nullを戻している場合はありませんか。
nullを戻すような実装をしてしまうと、メソッドを利用する際にnullチェックのロジックをわざわざ書く必要がでてきます。これにより、nullではなく長さが0の配列を返すようにするとnullチェックを不要とすることができます。
またNullPointerExceptionが発生して、プログラムが停止するといった危険を避けることもできます。
|
| publicメソッドはクラスの整合性を壊さないような設計を（C_MTD003）
|
これは感覚的に理解しづらいかもしれませんが、例えばスピーカーを売買するクラスを実装したとします。スピーカーは左右セットで販売される前提であるとして、次のように実装したとします。
|
public class buySpeaker{
public void buyRightSpeaker(){ ..... }
public void buyLeftSpeaker(){ ..... }
}
|
|
このように左右別々に購入ができるような実装をしてしまうと、スピーカーを購入する場合にはgetRightSpeaker()とgetLeftSpeaker()の両方のメソッドを同時に呼ぶ必要がでてきます。もしも片方だけしか呼ばれなかった場合、セット販売という前提は容易に崩れてしまいます。
特に、publicメソッドはいつどこで呼ばれるかわかりませんので、整合性を意識して処理としてまとめるほうが安全な設計となります。もし、内部的に分ける必要があったとしても、デザインパターンのFacadeパターンを利用するなどして、整合性を崩さないようなメソッドを提供するべきです。
また、1つの処理を行うために複数のメソッドを呼び出さないといけない設計では、呼び出す順番を間違えてバグにつながる可能性がありますので、上記のように整合性を崩さないメソッドを用意するのが安全です。
|
| メソッドは一つの役割にする（C_MTD004）
|
1つのメソッドの中で意味合いの異なる処理を複数行うと、可読性・保守性・拡張性・再利用性のすべてにおいて悪影響をもたらすことになりますので、メソッドは機能ごとに分割してください。
特にデザインパターンのFacadeパターンを適用する場合、setAndStore()のように複数の処理をまとめがちになってしまいますので注意が必要です。
メソッドの役割を1つにまとめることは、クラス設計の段階で意識することが重要なのですが、システムの仕様変更などにともなった追加修正を行う際にも注意が必要です。
機能追加のために既存のメソッドに次々と機能を追加すると、気がついたらメソッドの役割が1つになっていないということがあります。コードの追加修正の際には、メソッドの役割に一貫性があるかを常に確認し、必要ならばリファクタリングを行うことが重要です。
|
| メソッドの返り値としてthisは利用しない（C_MTD005）
|
メソッドの返り値としてthisを返したい場合、thisを返り値として返す必要が本当にあるかをよく考えてみてください。何か特別な事情がない限りは、thisを返さなくてもロジックを組み立てることができるはずです。
thisを返すことはオブジェクトの呼び出し関係がわかりにくくなり、処理を追うことを困難なものにしてしまいます。もし、thisを返すようなコードを記述しているならば、メソッドの返り値をvoidとするかthis以外の返り値とするように検討してみてください。
ちなみに、例外としてJava のStringBufferクラスはappendメソッドでthisを返す仕様となっています。これは、sb.append("aaa").append("bbb").append("ccc");といった形で一行で書ける方が文字列の場合はイメージがつかみやすいためthisを返しています。
|
| 引数の数が同じメソッドのオーバーロードは利用しない（C_MTD006）
|
メソッドのオーバーロードをする際に引数の数が同じになっていると、引数の型を確かめなければどのメソッドが実行されているのか判断できません。これは結果としてコードの可読性の低下につながります。
例えば、次のようにクラスSampleが実装されていたとします。
|
public class Sample{
public static void classify(Object sampleObject){ .... }
public static void classify(String sampleString){ .... }
public static void classify(Exception sampleException){ .... }
}
Sample.classify(sampleArgument);
|
|
このようにソースコード中で、classifyメソッドの呼び出しを見つけても、sampleArgumentの型がわからなければ、実際にどのメソッドが呼ばれているのかわかりません。さらに、このオーバーロードの問題に継承がからんでくると、メソッド自体がどのクラスに記述されているのかさえもわかりにくくなってしまいます。
開発環境によっては、Eclipseのように引数の型を自動で判断して該当のメソッドに飛んでくれる機能がありますが、そのような開発環境を利用されていない開発者を考慮して、引数の数が同じメソッドのオーバーロードは避けてください。
|
前のページ 1 2 3 4 次のページ
|
|
|
|
|
著者プロフィール
株式会社電通国際情報サービス 高安 厚思
株式会社電通国際情報サービス 開発技術センター
Java（J2EE）／オブジェクト指向の研究開発やプロジェクト支援、開発コンサルティングに従事。モデル、アーキテクチャ、プロセスが探求対象。今回は Javaコーディング規約2004の仕掛け人。
|
|
著者プロフィール
株式会社電通国際情報サービス 東田 健宏
株式会社電通国際情報サービス 開発技術センター
CTI、Webアプリの開発経験を経て、現在は主にプロジェクトマネジメント支援、プロセスエンジニアリング、ソフトウェア工学研究開発に従事。最近はコーチング、ファシリテーションといったヒューマン系スキルに興味を持ち日々修得に努めている。
|
|
著者プロフィール
インクステクニカルサービス株式会社 島澤 甲
インクステクニカルサービス株式会社 システム開発部所属
現在は主にJavaによるWebアプリの開発を担当している。Javaで初めてオブジェクト指向に触れ、オブジェクト指向による分かり易い設計とは何か日々模索している。
|
|
|
|
|
|
