public void reqCnctSndCls(String req) {}
つっこみどころ満載だな、と思ったあなたは「権利は義務の元に」をちゃんと理解してくれたのですね。思わなかったあなたは、読み直して、ちゃんとコーディング規約を読んで頂きたい。読んだ方が続きをより実感できるから。
規約に「単語を略すな」と言う物がある。この例で行くならcnctなんかconnectなんだかconcatなんだかconcertなんだかconcentrateなんだかさっぱり判らなくなるからである。略さず書くならこれは
public void requestConnectSendClose(String request) {}
となる。
これで安心した人、もうちょっと頑張りましょう。規約に、変数は名詞、メソッドは動詞になるように命名しろ、ってのがありますね。なので上記ではなんだかちょっとおかしい。要求接続送信切断、では何をするのか良くわからない。接続して要求を送信、その後切断という意味にするのなら、
public void connectAndSendRequestAndClose(String request) {}
とでもなるのでしょうか。
んな馬鹿みたいに長いメソッド名がが使えるか！と突っ込んだあなたは正しい。だからってreqCnctSndCls(String req)が良い訳ではない。じゃあ、どうするか？簡単なことです。
private void connect() {}
private void sendRequest(String request) {}
private void close() {}
public void order(String request) {
connect();
sendRequest(request);
close();
}
※設計によってはsendRequest()をsend()にした方がスマートだが。
こんだけ。よくメソッド名が長くなることを理由に単語を略したがる人がいますが、それは考え方が逆です。単語を略さない事を基本にしておけば、メソッド名が長すぎる⇒そうか、詰め込みすぎなんだな。多機能メソッドはアンチパターンだから分割しなきゃ⇒メンテナンス性、再利用性の向上となるはず。これが正しい考え方。命名則を意識するだけで設計まで向上します。
上記のような話をすると設定ファイルのreadと、シリアルケーブルのreadがあったら、
public byte[] readFromSettingFile() {}
public byte[] readFromSerialCable() {}
とかになって、これはもう短くならない！等という人がいますが、こんな物クラス分割が不味いわけで、
public class SerialConnection {
public byte[] read() {}
}
public class Setting {
public byte[] read() {}
}
が圧倒的に正しい。発展していくとDBとFileのどちらからか意識せずにデータを読む場合などに、
interface DataReader {
public byte[] read();
}
public class DatabaseReader implements DataReader {
public byte[] read() {}
}
public class FileReader implements DataReader {
public byte[] read() {}
}
のように設計して、
private void showAll() {
showData(new DatabaseReader(hoge));
showData(new FileReader(page));
showData(new DatabaseReader(age));
showData(new FileReader(sage));
}
private void showData(DataReader reader) {
byte[] data = reader.read();
System.out.println("data = " + new String(data));
}
のような扱いをする事からもどちらがスマートかは明らかである。
もう一度言おう、名前は略すな。結果長すぎたら設計が悪い。
戻る
|