Skip to content

Instantly share code, notes, and snippets.

@wm3

wm3/16-4.md

Last active August 29, 2015 14:06
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save wm3/a1fbfb6a5202b55cc009 to your computer and use it in GitHub Desktop.
Save wm3/a1fbfb6a5202b55cc009 to your computer and use it in GitHub Desktop.
Download ZIP
16章 後半
Raw
16-4.md

16.4 制限付き総称性

要は Java の Generics の extends

制限付き総称性が必要になる例 (16.4.1)

Vector(ベクトル)の加算

  • 各要素に対して + 演算子を呼び出したい

Dictionaryのハッシュ計算

非オブジェクト指向アプローチ (16.4.2)

Ada

  • パッケージにパラメーターを渡す
  • パラメーターに関数オブジェクトを渡せる

オブジェクト指向では Ada のアプローチは使えない

  • 関数オブジェクトは無い。相容れない

制限付き総称性の構文等の説明 (16.4.3)

  • Java の Generics の extends と使い方は同じ
  • 記号は「->」

補足

制限付き総称性を再帰する事が可能 (16.4.4)

  • 例: ベクトルのベクトル

「->」が無い場合は「-> ANY」という扱い (16.4.5)

16.5 試行代入

C++ の dynamic_cast に近い

引数渡しや代入の過程で型の情報が落ちる (16.5.1)

型の確認する機能が必要になる事がある

例: 図形のリスト(LIST[FIGURE])から対角線が一番長い長方形を探す

  • FIGUREには対角線を返す特性 (diagonal) は無い

例: ファイルに永続化されたオブジェクトの復元

  • BOOK を保存しても、復元する時変数の型は STORABLE になってしまう
  • 無理に BOOK として復元しようとしても復元したオブジェクトが壊れていない事は保証できない

型の確認をする方法の比較 (16.5.2)

悪い例: オブジェクトの型を候補の型と比較しながら分岐

考察

  • オブジェクトの型をそのまま取得したいわけではない
    • 期待した型かどうかを判別できれば良い
  • 「特性呼び出し規則」をいじるべきではない

試行代入のメカニズム (16.5.3)

  • 「?=」演算子を使って代入
  • 左辺の型に右辺をダウンキャスト
  • 適合しなければ、void が代入される

複雑なケース分岐に付いて? (16.5.4)

複雑なケース分岐ではなく、OOのスキーマを使うように出来ている

Java での同等の仕組みについて

  • (突っ込みどころが多い…)
  • 型が一致しなかった場合例外を投げるが、これはやり過ぎ
  • Java には総称性が無い

16.6 型付けと再宣言

継承で、特性の型を上書きする事が可能

例

デバイスとプリンタ (16.6.1)

  • サブクラスで特性の型を再宣言する (インスタンス変数とルーチンの引数型)

連結リストに対して「双方向リスト」サブクラスを作る (16.6.2)

型再宣言規則 (16.6.3)

特性の型、もしくは仮引数の型を特化の方向で再宣言が可能

  • (仮引数を特化して良いのだろうか…?)

「共変型付け」ポリシー

共変の問題は開発者は実害が無い事が多い (らしい…)

16.7 アンカー宣言

変数の型として、固定の型ではなく「他の変数の型」や「自分の型」を指定できる

アンカー宣言が欲しい例

連結リストにおける挿入 (16.7.1)

  • 継承した場合はそれに応じてノードの型を変更しなければならない

getter/setter の組 (16.7.2)

POINT に対する共役(conjugate) (16.7.2)

  • 各サブクラスが conjugate ルーチンの型を再宣言しないといけなくなる

連結リスト (16.7.3)

  • 挿入だけでなく、ほとんどの特性を再宣言しないといけなくなる

構文

  • my_entity: like (変数) (16.7.4)
  • my_entity: like Current (16.7.5)

補足

基本クラスについて (16.7.6)

  • 「like (変数)」の基本クラス … 変数の基本クラスに一致

規則 (16.7.7)

  • 「anchor: like anchor」と宣言しても良い
  • 適合について
    • anchor: T の場合、
    • 「like anchor」は T に適合する
    • T は「like anchor」適合しない
    • 「like anchor」に適合するのは「like anchor」のみ

アンカー宣言をしてはいけないケース (16.7.8)

  • 「x: like anchor」と宣言したら、x の型の再宣言は出来なくなる
  • 例えば、木構造等の子ノード場合はこれは都合が悪い
  • アンカー宣言はせず、必要になり次第サブクラスがアンカー宣言で再定義すれば良い

アンカー宣言をする事で実行時に影響を与えることはない (16.7.9)

16.8 継承と情報隠蔽

継承で公開範囲を変えられる (16.8.1)

  • export サブ句

例 (16.8.2)

銀行口座クラス

  • open、withdraw、等の処理は非公開だが、継承で公開できる

CELL (多重継承の章で記述したクラス)

  • TREE サブクラスで、right 特性を公開

他の言語の例 (16.8.3)

Simula の実装

  • 「protected」キーワードのように、サブクラスに公開するかを指定する

クラス作成者が公開範囲を決定するのは、解放/閉鎖の原則に反する

公開範囲はクラス作成者には分からない

インタフェースと実装の再利用 (16.8.4)

  • 再利用にはインタフェースの再利用と実装の再利用がある
  • 実装を継承しても何も問題無い

実装の継承が信用されないのは心理的な所による (16.8.5)

  • (ちょっと理解できませんでした…)

顧客/継承の比較 (16.8.6)

  • 表16.1

選択的エクスポート (16.8.7)

  • 選択的にあるクラスにエクスポートされた特性は、そのクラスの子孫全てに利用可能である
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment