スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

選択できない選択肢

あなたの実力以上に有徳であろうとするな。
できそうもないことを己に要求するな。
プログラミングにおいて最も重要なもののひとつ。「美しさ」。 「美しい」ソースコードと「読みやすい」ソースコードとは必ずしも一致するのものではありませんが、美しいソースコードは可読性や拡張性が高く、保守性にも優れています。美しいコードを書こうという努力は、決して自己満足に終わるものではありません。

さて、「美しい」といってしまうとあまりにも漠然としているのですが、今回とりあげるのはその中の「統一性」です。
インターフェース設計においては、複数の機能をひとつのインターフェースで実現しようとすることがあります。しかし、もともと複数の機能ですから、機能によって必要とするパラメータが微妙に異なったり、操作対象によって使えたり使えなかたったりする場合がでてくることがあります。
よく言われるオブジェクト指向のアンチパターンにfat interfaceと呼ばれるものがあります。一部の子クラスでのみ有効な機能も全てスーパークラスのインターフェースに詰め込んでしまい、スーパークラスのインターフェースが膨れ上がる。おまけに、実オブジェクトのクラスによって使えるインターフェースと使えないインターフェースまで出てきてしまう。fat interfaceの名の通り、インターフェースの数が膨大になるもの勿論問題なのですが、それ以上に、使えるか使えないか一見して分からないというのは、使う側にとっては非常に問題です。
他の例としては、いろんな機能要求に答えるために、複数の引数を持ったり、フラグ型引数を持つもの。例としては、POSIXのopen()関数。この関数では、flagsにはこれとこれが同時指定可能とか、このflagsにはこのフラグとこのフラグは同時指定可能とか、modeはflagsがこの値のときだけ有効とか、関数の形や型定義からは判断できない仕様ができてきしまっています。

誤解のないように書いておくと、ひとつの関数やインターフェースに複数の機能をバインドしてしまうのはいけないことだと言っているわけではありません。インターフェースの統一は非常に重要な観点です。上記の例で問題なのでは、インターフェース中に「選択できない選択肢」があることです。仕様を確認すれば分かるというのはなしです。そもそも、選べないものは見せるべきではありません。

インターフェースを統一・共通化しようとした際に、上記のような「選択できない選択肢」が登場しそうな場合には、本当に共通化するべきか再考するべきです。そもそも共通項のない機能であれば無理して共通化する必要はありません。共通項が多い場合や、相乗効果が得られそうな場合には統一する 価値があるかもしれません。先のopen関数の場合、多少不要な引数が現れることもありますが、readとwriteのオープン処理が共通化されているために、read/writeモードでファイルをオープンするといったこともできていますので、それほど悪い例とは思いません。

本当に「美しい」コードは、見た目のエレガントさだけではなく、機能性・理解性も優れているものです。

【関連記事】
関数のユーザビリティ

【関連書籍】
アンチパターン―ソフトウェア危篤患者の救出
J2EEアンチパターン
サーバーサイドJavaアンチパターン
Code Complete第2版―完全なプログラミングを目指して

コメント

こんばんは、共感です

こんばんわ!

記事を拝見しました

本当に「美しい」コードは、見た目のエレガントさだけではなく、機能性・理解性も優れているものです

よい言葉ですね!
私は、次にカスタマイズを頼まれたときに、容易に対応できるソフトがプロが
作るソフトだと思っています。

ではまたよります!

わかったようなことを言う人をまた発見しました。
非公開コメント

本のおすすめ

4873115655

4274065979

4822236862

4274068579

4822255131

B00SIM19YS


プロフィール

  • Author:proger
  • 組み込み関係で仕事してます

ブログ内検索

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。