メイヤー オブジェクト指向入門ノート4

第２章オブジェクト指向の基準

• 2019/08/29
  • ２章はじめから「 2.2.2クラス(class)」まで読んだ
  • 次回「2.2.3表明(assertion)」から

• これより後の章でオブジェクト指向を学ぶ前に、オブジェクト指向に寄る開発の重要な側面を広くざっと見渡す
  • ２章はこれより後の章のプレビューとしての役割持つ
    • これより後の章を一個ずつ全部読むつもりなら不要の章。
• オブジェクト指向という言葉が見境なく使われてしまっている。

2.1 基準について

オブジェクトらしさ(objectness)を評価するための基準として何を選ぶか

2.1.1どの程度独断的になる必要があるだろう？

• オブジェクト指向開発の重要な性質をリストアップ

• オブジェクト指向はブール条件ではない。(白黒つけにくい。)

  • よりオブジェクト指向的な選択肢を選ぶことの重要性
• 全ての人が常に全ての性質を必要とするとは限らない

• オブジェクト指向はソフトウェアによる問題可決の探求を助ける要素の一つに過ぎない。

  • 「オブジェクト指向」であることにこだわりすぎない。

• 銀の弾丸では似が移行に列挙する項目によって書かれる完全な世界を知っている必要がある。

2.1.2カテゴリ

説明する基準は3つの分類に分割できる

• 1.方法論と言語
  • プログラミング言語
  • 分析、設計に使用されるテキストやグラフィックによる表記法
• 2.実装と環境
  • ツールの基本的な性質

• 3.ライブラリ

  • オブジェクト技術は再利用に依存している
    • 基本ライブラリに対するメカニズムの基準
      • 入手しやすさ
      • 利用
      • 開発

• 分類は絶対的ではない。

  • 例:メモリ管理→方法論と言語、実装と環境にまたがる場合がある

2.2 方法論と言語

2.2.1 継ぎ目のない連続性(seamlessness)

• 方法論と言語は、分析、設計、実装、保守全てに適応される必要がある。

  • 言語は全ての段階において指向を助ける表現手段である必要がある。
  • 結果、開発過程の継ぎ目がなくなる。
    • ライフサイクルの各段階の移行の規模を小さくする(疑問:アジャイル的な話か？)

• アンチパターン　

  • 実装に適用できない道具を使って分析と設計飲みにオブジェクト指向の概念を適用する
  • 分析と設計でオブジェクト指向を適用できない実装の道具(プログラミング言語)を使う

支援する方法論も含めて、オブジェクト指向言語及び環境は、ライフサイクル全体に適用され、作業段階の間の隔たりを最小限にするものでなければならない。

2.2.2クラス(class)

定義

抽象データ型とその部分的または全体的実装を表現するソフトウェア要素

• オブジェクト指向はクラスという概念に基づいている
  • 疑問:Javascript(プロトタイプベースのオブジェクト指向)は？？？？
• 抽象データ型:オブジェクトの集合
  • オブジェクトの集合
    • オブジェクトに対して適用可能な操作、特性(feature)のリストと操作の属性(properties)によって定義される

2.2.3表明(assertion)

続きはまた今度。