AOAD勉強会(第2回)

Aspect AOAD

基本情報

  • Day/Time: 2005/07/24 Sun. 10:00 - 12:00
  • Place: 912 Training−Room @ OGIS-RI
  • Person: 9(▲1yyamano)

勉強会の内容

今日の範囲(Chapter2: The Object-Oriented Way)
  • a. 要件定義 pp27-32 まで
    • (The Object-Oriented Way 〜 Describing Objects の直前まで)
  • b. オブジェクトの定義 pp32-35 まで
    • (Describing Objects 〜 Expressions Example の直前まで)
  • c. 式評価システム pp35-38 まで
    • (Expressions Example〜Object-Oriented Design の直前まで)
  • d. 式評価システムのオブジェクト指向設計の例pp38-45 まで
    • (Object-Oriented Design〜Accommodating Evolutionの直前まで)
  • e. オブジェクト指向による拡張性への対応 pp45-51 まで
    • (Accommodating Evolution 〜 第二章の最後まで)

本日選択された項目は、c. とe.でした。

c. 式評価システム

Requirements# Descriotion
R1 式を評価できること(式の結果を決定できること)
R2 (解析した)式を表示できること
R3 構文上・意味上、式が正しいかどうか構文チェックできること
R4 操作は全て(R1、R2、R3)ログを撮ること

あまりに荒い要求なので、d.をかじってみる事にした。(以下に続く)

d.式評価システムのオブジェクト指向設計の例

  • 疑問1Figure2-6で構文木の構造が示されており、各クラスにcheck()メソッドが存在しているが、そもそもこの構造を作り出す際にチェックが必要なのでは？(itoh-san)
    • 抽象構文木が成立しないケースはどうするの？ということか。
    • Expression::check()で構文木のオブジェクト構造を試作してみることに（I氏)
    • 構文木は作っておいて、Expression::check()で式を評価するのかなぁ。
      • どんな式でも構文木のオブジェクト構造ができるようになってるのかな？

e. オブジェクト指向による拡張性への対応(Accommodation Evelution)

追加要件の整理(Table2-6)
Requirements# Descriotion
R12 使われている変数が定義されているかどうか

定義されている変数が使われているかどうか
R13 (ユーザが定義可能な)命名規約に従っているか
R14 R3,R12,R13を使用するかどうかを任意に選択できる

注：構文チェックは必須だろう
R15 R12とR13はログに残す
□ デザインパターンを適用してもなぜ問題が残るのか
  • ここでの議論に登場するパターン
    • Vistor
    • Observer
    • Decorator
Design Pattern motivation Good! Bad!
Visitor 構文チェック用に適用(R12,R13)

今回新しい追加要求に対して、チャックメソッドを新たに追加しなければならないのかp46		 新しいチェック機能を追加しやすい

チェックのために必要な情報は異なる

それぞれのチェック内容はそれぞれのvistorクラスが知っていれば良い

チェックさせる側(acceptor)は、チェック内容の詳細は知らなくてよくなる

チェックメソッドを変更せずに新しい機能を実現できる

新しいチェックメソッドの追加は避けたい

それぞれのチェック内容はクラスが知っていれば良い

新しいチェックを追加しやすい[拡張可能性] 		評価対象の式が拡張されたら対応しにくい(acceptor)

例) *や/とか参考演算子とか
Observer ログの呼び出しに適用(R4,R15)

適用前はログ出力を意識した呼び出しをしていた(依存関係による強い結合度)		 ロガーがいつ、誰から呼び出されるか知らなくて良い？⇒・・・

ロガーとAST(抽象構文木)クラスの結合度を減らす(p.49)

オペレーションの前後のログの呼び出しにobserverのメソッド呼び出しを行うことで、ログ呼び出しを隠蔽した		 observerの呼び出しが局所化されていない(相変わらずを呼び出すコードが散らばっている)

ASTメソッドがobserverを知っている必要がある
Decorator ログに適用()

Observerの代替案として		 結合度を下げる点ではObserverと同様(p50, l4)

ログ通知に関するコードをメソッド呼び出しで各必要がなくなった(observerの呼び出しが不要になった) 		Observerパターンより悪化

オブジェクト精神分裂症(多重人格のオブジェクト(several roles)のため、オブジェクトは自身のパーソナリティを自覚していなければならない(multiple personalities)？？？)
オブジェクト精神分裂症(Object schizophrenia)についての異なる意見
  • (解釈1)一つのインスタンス(decorator)が、
    • Expressionのチェックと
    • ログの仕事もしないといけないこと(MM氏)
  • (解釈2)使う側がDecoratorが存在するのかを知っている必要があること 
DI コンテナの AOP 機能については、Decorator、FactoryMethod で実現されているようだ(伊藤さん)

Observerは使ってないかも・・・。

□ オブジェクト指向の限界、問題点

アスペクト指向への期待(Motivation)をチラッと見せる

  • オブジェクトのモジュール化の単位と要求のモジュール化の単位が違う
  • 散らばるのと絡まること(scattering, Tangling)
  • 要求と(設計、コード)とのトレーサビリティがない。
    • Forward: 要求が追加された時に、どの要素に影響があるのかわかり難い
    • Backward:設計モデルを見ても decorator を何の目的で呼び出しているか分かりにくい

その他

Table2-2(p31)

Term Definition
View 対象のことを行っている？
Perspective 対象がどう見えるか？

視野、視座、視点と関係があるのか？
Role 役割

視野、視座、視点について

    • 視野: スコープ
    • 視座: どこから(誰が)見ているか, 例) Actor(利用者)
    • 視点: 対象。
      • 視野と視点は同じに感じる(I氏)
      • 雑誌の記事に掲載されていた(Akapon)

次回の予定

  • #3回
    • 8/7 Sun. 10:00~12:00 , 進行役:Akapon
  • #4回
    • 8/28 Sun. 10:00~12:00

リンク