skillup

技術ブログ

プログラミング全般

オブジェクト指向設計 ダックタイピング

投稿日:

オブジェクト指向シリーズ。ダックタイピング・・読む前は名前は聞いたことあるような気がする・・程度で細かいことは何一つわからない状態でした。今回具体的なコード例があった分イメージを何とかつかむことはできた(ような気がします。)

ダックタイピング

定義

そもそもの定義が難しい・・
Wikiには以下の通り。

ダック・タイピング(duck typing)とは、Smalltalk、Perl、Python、Rubyなどのいくつかの動的型付けオブジェクト指向プログラミング言語に特徴的な型付けの作法のことである。それらの言語ではオブジェクト(変数の値)に何ができるかはオブジェクトそのものが決定する。つまり、オブジェクトがあるインタフェースのすべてのメソッドを持っているならば、たとえそのクラスがそのインタフェースを宣言的に実装していなくとも、オブジェクトはそのインタフェースを実行時に実装しているとみなせる、ということである。

いやー何言っているかさっぱりわからん(汗)まあ辞書的に定義するとこんな例になりますよね・・・例によって検索するといい例があったのでリスペクトも込めてリンクします。

http://d.hatena.ne.jp/bingo_nakanishi_perl/20090818/1250607321
http://qiita.com/ksss/items/1659d53c39c4cad11bdc

自分なりに解釈すると・・・

同一性のある処理(if,switchなどで分岐されるタイプ)の場合、インターフェイス(具体的にはメソッド名)を共通にして変更に強いコードを作る考えということでしょうか。

実際のコーディング上のコツ

  • 安易にif,switchで複数で条件分岐を行わない(条件分岐された場合共通化を考える)
  • 上位のプログラム(呼び出し側っていったらいいのかな)ではインとアウトのみ定義しておく(逆に言うと、ここが厳密でないとまずい)
  • 内部の詳細な処理は内部のプログラムに任せる

感想

疎結合とかDIの有用性っていう概念が少しずつわかりかけてきました。2年ぐらい前に聞いたときはさっぱりイメージが出来なかったんだけれど・・・実際に自分で開発・保守をしてみると変更の時に耐え切れず残念なコードを書くことが非常に多かったです。

そんなときにああでもない、こうでもないとうんうんうなりながら、本書のような本を読むとその有用性がはっきりわかります。

変更により残念なコードになるのを防ぐためには変更がありそうな部分には「タッチしない(上記のリンクの例でいうと各動物のクラスだったり、料理だったりする)。」「上位側ではインとアウトのみ定義し、ふるまい自体は各クラスに任せる」という考え方が大事になってきます。

今までは上記のような場合、継承を使っていたんだけれども、継承がうまく使えない場合に知っておくとよさそう。

ここ数日、単一責任、依存関係の管理、インターフェイス、ダックタイピングとやってきましたが、オブジェクト指向の要点としては自分なりには下記の通り。

  1. コードを単一の機能(クラス)ごとに分ける
  2. 各機能(クラス)が何を行うか、別の機能(クラス)はタッチしない
  3. 機能ごとの依存度をとにかく減らす
  4. 詳細な機能はなるべく隠し、インとアウトだけをしっかりと定義しておく

今まではフィーリングに近い感じで画面ごとにクラスを作っていました・・・オブジェクト指向では「依存度を減らす」「内部の詳細構造を隠す」ということが大事で、詳細部分を公開しないことによって外部との依存度がへり、結果として変更に強いコードができます。

この意識が今まであまりなかったのですが、オープンソースなどみていますと、1行のメソッドをラッピングしていることにはこういう意図があったのかと思い、保守性を上げるための工夫というものがおぼろげながらわかりました。

このような工夫はテストをするときにも非常に有効です。

例えばプログラムでデータをもらう場所というのはデータベースだったり、外部ネットワーク(APIだったり、メール)しますが、これらとの連携を行う場合、コードが分割されていないとテストが結構大変です。

-プログラミング全般
-

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

no image

オブジェクト指向について その3

今回は場合分けによる変更コストとオブジェクト指向のメリットについてです。 例えば給付金が発生して、その金額を死亡時、退職時、通常時で場合分けするとき、if-elseで書けば下記のようになります。 [c …

no image

正規表現その2

10/28に書いた正規表現に関しての追記です。 Contents1 覚えておきたいメタ文字2 留意点 覚えておきたいメタ文字 よく出るメタ文字の復習です。 メタ文字 メタ文字の説明 [] いずれかの1 …

no image

フレームワーク作成時の注意ポイント

以前も多分書いていますが、フレームワーク作成時のポイントなどを列挙。 次元が違うものも多々含まれているかも。 ルーティング機能 基本設定情報の読み込み キャッシュ機能 データベース Form情報の管理 …

no image

クラスメソッドとインスタンスメソッド

以前staticメソッドを定義したときに、記法がインスタンスメソッドの呼び方でも呼べてしまうことがあったので、これを機にインスタンス・クラス×変数・メソッドちょっと調べてみました。 言葉で書くよりコー …

no image

コメントについて

リーダブルコード 第5・6章はコメントについて。 今回はコメントです。ここは結構賛否両論になるところではないかと思います。 ざっくり分けると「できるだけコメントは詳しく書くこと」という意見と「コメント …