skillup

技術ブログ

アーキテクト設計全般

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

投稿日:2017年8月30日 更新日:

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

ダックタイピング

定義

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

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

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

第136回 PHPでダックタイピング

Rubyでcase文を卒業してダックタイピングに入門する

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

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

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

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

感想

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

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

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

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

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

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

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

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

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

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

-アーキテクト設計全般
-

執筆者:


comment

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

関連記事

no image

オブジェクト指向 クラスの設計と業務ロジックの整理

本日も引き続き「現場で役立つシステム設計の原則」を読み進めてます。 本日は主にクラスの作り方について。 Contents1 クラス設計と業務ロジック1.1 要点1.2 感想 クラス設計と業務ロジック …

no image

ステートパターンについて

トランザクション系のデータの場合、スタータスの遷移がキーになることが多く、仕様の把握に関してこの部分の理解が重要です。 今まで、ステータスの遷移に関してはExcelを使って表現していたことが多かったの …

no image

オブジェクト指向 アプリケーション層に関して

本日も引き続き「現場で役立つシステム設計の原則」を読み進めてます。 本日は主にアプリケーション層(以下AP層)。MVCモデルでいうところのコントローラーに近い?)の考え方について。 Contents1 …

no image

APIに関して

RESTAPIのルーティングで気をつけることなんぞを。 直近のプロジェクトではRESTAPIを作ることが多かったんですが気をつけることなんぞを。 Contents1 仕様書はソースから2 ツール3 命 …

no image

abstract,interface,traitなどについて

昔はようわからなかったabstract(継承全般)、interface、traitの使い分けなどについて。 今の現場でいろいろと考えることがあり、自分なりにいろんな方の知見を共有できたので、メモしてお …

アーカイブ