抽象性と可読性のトレードオフに関して

私自身プログラムを書く場合、とにかくコードを書く量を制限したいという思いが強く、多少でも共通化できる箇所がある場合はなるべく共通化するようにしておりましたが、時と場合によっては過剰に共通化したことによって可読性が下がり、結果として保守しにくくなるということもありました。(特に可読性が落ちることが多いです。)

直近で悩んだテーマ

類似のクラス

例えばDogとCatみたいなクラスがあるとします(あえて内部にどのようなメソッドがあるかはここでは書かずに説明させていただきます。)

1. 共通化してAnimalのようなクラスにしてしまう
2. DogとCatの親クラスを作り、継承する
3. DogとCatをのクラスをあえて共通化させず残す

上記のような3つの選択肢があり、私としては１(妥協して2)の選択肢が最適と考えることが多かったですが、正しいかどうかはケースバイケース(DogとCatの類似性)になります。

コードを書くときは書く以上に、読みやすいか(仕様がわかるか)というのも同じぐらい大切になってきます。

コードを書く量で考えると3>2>1のようになることが多いですが(3が一番ダメで1がベスト)、可読性も3>2>1(3がベストで1がダメ)になることがあり得ます。

変数の統合

また編集画面などで大量の入力項目がある際に以下のように引数がずらずら並ぶのは基本的にNGでなるべく少ない変数にした方がいいと考えて案1→案2のようなケースを考えておりました。

この場合変数が増えることが往々にして多く、案1の場合、その度に修正が発生します。

案1

案2

ただ案2の方が優れた書き方かというとそんなことはありません。確かに変数が増えるなどの影響には強いのですが、デメリットとしては

「連想配列だと内部にどんな変数が入っているかがわからず、内部構造を隠蔽されてしまい、他者からは分かりにくい」

というデメリットがあり、一概に推奨はできないです。変数を統一することで、可読性が減ってしまっているというデメリットがあります。

その場合、personalのようなオブジェクトを作るという選択肢もありますが、そうしますと案1と同等になり、コードを書く量としてはそれほど大差ないかと思います。

動的な呼び出し

メソッドを呼び出す場合に類似性が高かったり、数が多いとループから動的な関数あるいは変数を作ったりすることも多かったのです。

こうすることで一気にコード量を減らすことは確かにできますし、類似の変更があったときに、メンテが非常に楽ということもありますが、定義元が変更した場合に修正の影響をエディタの補完機能などでさがせないというリスクもあります。

まとめ

このように抽象度を上げたりすると一般的にコードの量は減るのですが、その分可読性が減るというデメリットもあります。

大切なことは

• 保守性(メンテナンスのしやすさ、修正時間)
• テストのしやすさ
• 可読性(他者が読んで読みやすいか)
• 統一性(可読性の一種ですが、他の箇所と処理が統一されているか否か)

を考慮してそれぞれにメリット、デメリットを考えられることかと思います。