メイヤー オブジェクト指向入門読書ノート7

所要時間40分。前回からの続き

yuyubu-sub.hateblo.jp

翻訳を原文に照らし合わせて確認などしたので進みが悪い

「2.2.20 メモリ管理とガベージコレクション」から「2.3.2 迅速な更新」まで読んだ

2.1 基準について

2.2 方法論と言語

2.2.20 メモリ管理とガベージコレクション

• 2.3実装と環境にも関連する内容である
  • カテゴライズを迷ったようなことが書かれている

次のカテゴリである実装と環境に入れるほうが適当ではないかと最初は見えるかもしれない。実際、両方に属しているのだが、決定的な要件は言語を対象としており、残りの要件は良い工学の問題である

• 言いたいことはわかるが文章が分かりにくい
  • 補足っぽい訳を書いてみる
    • 要件の最重要のものはプログラミング言語に対するものであるため、「2. 2方法論」にカテゴライズした。
    • 他の要件はよいエンジニアリングのためのものであるため「2.3 実装と環境」にも関連している
  • 原文

The last point on our list of method and language criteria may at first appear to belong more properly to the next category — implementation and environment. In fact it belongs to both. But the crucial requirements apply to the language; the rest is a matter of good engineering.

• Lisp意外のOOPは従来のプログラムより相互に依存するオブジェクトを多く作成する傾向がある
  • Lispは違うのかな？
• メモリの管理を開発者が行うとバグの温床 & アプリ側の開発に集中できなくなる
  • 良いOOP言語にはGCによる自動メモリ管理がほしい
• GCによる自動メモリ管理ができるように設計されていない言語では自動メモリ管理はしばしば不可能
• 例:キャストを使ったポインタの変装(変換？)ができる言語では安全なGCが掛けない
  • そうなの？
  • よくわからないから原文を載せておく

例えば、キャスト(cast)と呼ばれる変換によって、特定の型のオブジェクトへのポインタが他の型のポインタや場合によっては整数に変装できる言語では、安全なガベージコレクタを書くことは不可能である。

• OOP=GC必須なのかは現時点での自分の理解だと不明。

言語は安全な自動メモリ管理を可能にしなければならない。そして、言語の実装はガベージコレクションを担当する自動メモリ管理機構を提供しなければならない。

2.3 実装と環境

• OOPによる開発をサポートする開発環境に必要とされる需要な属性

2.3.1 自動的な更新

• インクリメンタル追加・修正に対応したい。

更新作業を行うときに重要なことは、最終的なシステムの一貫性を保証することである

• また訳が微妙
  • 最終的、という言葉はシステムの完成時点での、という意味に取れてしまう。
    • この記述だと個人的には納品時の凍結したソース、くらいの意味に思えてしまう
    • それが一貫している必要性があるのは書くまでもない。
  • ☓最終的な →○最新の くらいが妥当か。
  • ※誤訳とは思いませんが、個人的にしっくりこないだけです。
  • latest~って書いてるって思ったけど、ただresultingとだけなっていた。
  • 以下原文

When performing such an update, it is essential to have the guarantee that the resulting system will be consistent.

• スーパークラスのメソッド変更時に、(メソッドをオーバーライドしていない)サブクラスで新しいバージョンが呼び出されることを保証しなければならない
  • 伝統的には手作業で解決していた?
    • make file
    • include fileなどのメカニズム
    • 依存関係の記述と変更をたどる必要性
      • 今日のソフトウェア開発ではありえない
  • 依存関係はソフトウェアのテキスト(プログラム)の記述のみから導けるべきである。

変更後のシステム更新は自動的に行われなければならない。クラス感の依存関係の分析はツールによって実行されるべkで、開発者が手作業でおこなうものではない。

• コンパイラやインタプリタでうまく実現する
• この辺の感覚は手作業で巨大な依存関係を解決した覚えがないのでよくわからない。

2.3.2 迅速な更新

• 変更後のシステム更新は自動かつ迅速である必要がある。
• 変更時間はシステム全体のサイズではなく、変更のサイズに比例している必要がある。
  • そうでないと大きなシステムで利用できない。
• 差分コンパイル的な仕組みが必須である

更新されたバージョンの実行を可能にするためには、システムに対する変更の処理にかかる時間は、システムの全体のサイズに関わらず、変更された部分のサイズの関数でなければならない。

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)

Object-Oriented Software Construction (Book/CD-ROM) (Prentice-hall International Series in Computer Science)