[debian-users:12212] Re: historical info

["Ken N." <kenn@xxxxxxxxxxxxxxxxx>]

In <14472.27975.964346.72159A@xxxxxxxxxxxxxxxxxx>
[debian-users:12135] Re: historical info, Jan.21 '99 23:29 JST
taru@xxxxxxxxxxxxx says:
=   
=   dpkg-divert することが dpkg が判断や処理をやっているということに
=   なると思います。

``diversion'' というインタフェースをパッケージに対して見せる必
要はないんじゃない？という話です。

=   dpkg-divert というインタフェースを通して実行する方式はサーバ
=   側の管理している情報をサーバがきちんと仕事をしていると言えないでしょうか？

その例だと、サーバ側は確かに``diversion'' という抽象名で参照さ
れる一連の操作と関連するデータについて詳細を隠蔽しcoherency を
維持しています。サーバ側がすべき事としてそれが全てであればそれ
で十分なのですが、そうではないわけです、もともとの話では。

樽石さんのイメージでは、パッケージが、たとえば「インストールユー
スケース」におけるアクタであり、またたとえばインストールの一連
のシーケンスのdriving controller object なのですよね。背景はわ
かります。パッケージが、自分のたどり着いた先のシステムにおいて
まわりの環境を把握し、それに応じて自分and/orホストシステムの状
態変更、調整してそのシステム上に定着する、つまり自律的なオブジェ
クトとして振舞う、というイメージですよね。

私はパッケージは受動的なものでよいと思っています。オブジェクト
として持つべきメソッドは属性のget とファイルのretrieveだけでい
い。自律性を生み出す複雑さを1000を越えるパッケージに分散させた
のでは開発効率や品質保持にもいい影響はありませんし、パッケージ
毎自律性能や品質のバラツキにもつながります。

「複雑なもの」「調和がとれていないもの」「アドホックで不様なも
の」というのは、どんなシステムでも多かれ少なかれ出て来ますが、
それらを極力一箇所に集中させる事によって、その他の部分の簡素さ、
調和性、汎用性、コードとしての美しさを維持し、再利用性や品質保
持につなげるというのが一般的な解です。OOならば、これらは典型的
にはコントローラとなるオブジェクトを明確に切り出すことによって
行われます。

たとえば、制約を認識して自律的に振舞うオブジェクトとしてのパッ
ケージというのを実現したければ、パッケージそのものは受動的につ
くっておいて、そのパッケージの属性を適宜get しながらインストー
ルシーケンスをドライヴィングするコントローラオブジェクト(d-agent?)
を作るというのでもいいですよね。


=   #これがちがうならオブジェクト指向的設計(特にカプセル化)
=   #は全て設計の失敗ということになると思います。

何を隠蔽しどのようなインタフェースを設けたかによっては明確に失
敗とよべる設計もあるでしょう。「良い設計」もひとつではないし、
「良い設計」でなくても「『あり』な設計」で十分な場合もあるでしょ
う。目標とする問題領域が違えば界面の認識の仕方も異なるでしょう。
その結論は少し短絡的だと思う。


 -.- . -. -.
Ken Nakagaki <kenn@xxxxxxxxxxxxxxxxx>
「会社は主にそれ自身の慣性によって前進している」-- Gerry Spence