オブジェクト指向っぽくないメソッドの実装を愚痴る
クラスにおけるpublicメソッド(API/インターフェース)の実装について。
現在、参画中のプロジェクトで既存システムの追加・変更を行っているんですが、元となる前任者達の遺産(=ソースコード)がえらいことなんですorz
新卒１年目とかが書いたコードではないと思うんですけどね。自分も若かりし頃はそんなコードも書いてた気がしますヽ(´ー｀)ノ
とりあえず愚痴をいい機会なので、今回の悪い例からメソッドの役割について僕の考えを整理してみたいと思います。
重複なし
重複は何世代にも渡ってコードが引き継がれた場合に発生します。主な理由は
- 前任者のコードが分からないので、同一機能を新規に作った
- 前任者のコードが間違っているけど、今のシステムでは動いているから新規に作った
- 同一機能があるのを知らなかった
正しいのを新しく作ったなら、ちゃんと古いのは削除すべきです。デグレを恐れるのも分かりますが･･･
※オーバーロードは違います。メソッドの名前以外の事はしない
実はこれを守るだけでも、そこそこ可読性が上がります。C言語などでオブジェクト指向を考慮せずにプログラミングしてきた人に多いですね。(これまで出会ったデキる設計者はC言語でもオブジェクト指向っぽく設計している方が多かったです。)
悪い例
Phoneクラスのcall()メソッドで発信履歴まで残す。
この場合は履歴クラスで発信履歴を追加するメソッドを用意して、call()の呼び出し元で登録すべき。
メソッドの結果が単体で使えること
今回これで嵌りましたw
C言語のサブルーチンやprivateメソッドみたいな感じで書いたのでしょうか？単体でコールしただけでは期待しない結果を返していました。
例えばこんな感じ(実際は違うものですw)。
- テキスト編集クラスに
publicな"カンマをタブに変換するメソッド"がある
→実行したら改行が全部無くなる(想定外。もちろん、これではシステムも不具合を起こす) - テキスト編集クラスに
publicな"出力メソッド"がある
→実行したら改行が付くようになっている。
複雑なシステムなどでは、どうしてもテンポラリ的なデータが必要かと思いますが、publicなメソッドの結果がそうなるのはNGです。
しかも今回はこれがUtil系のクラスだったというハチャメチャさ。Utilなのに、順番意識して使用するとか、自由過ぎです。てか、レビューしたのか･･･
privateで特定のメソッドからのみコールされる想定とかはルールさえ守ればOKだと思っています。
今回はTipsではないのでブログっぽいですねw
