vieweditattachhistoryswikistopchangessearchhelp

オブジェクトの永続化とその方法

MVC の、

＞Morphic もちょっと問題があって、インスタンス（モーフ）だけでインターフェイスビルダよろしく GUI が構築できてしまうんですよね。ちょうどドロー系ツールで絵を描くと、それが機能を持ったアプリもどきになるという恐ろしい現象が。それぞれのウィジェットもどきにサブクラスを作って、それっぽくコーディングすると（もしくは Squeak eToys すると）動いちゃうからラクで楽しいんですけど、これをソースとして配布しようとすると、とんでもない作業がまっているという罠があります。--sumim

を受けた、

それって必要なんでしょうか？
もし「なんでもコードに落とさないと運搬できない」のだとすると、ちょっと悲しいかも。 --戯

から派生。

例によって某Java開発環境とDelphiとの差という逸話(?)を思い出すのですが、
Delphiだと(Window上のWidgetなどの)Objectの属性や関連はテキスト(文法はソコソコ)に落としてくれてて、
もともとコードだった部分しかコードとして落ちてきません。これが本当に姿だと思うなあ。

(狭義な)ソース主義は、これもまたオブジェクト感覚から遠い、のかも(^^;

Delphiについて言えば、Widgetなどの貼りまくり可能Object(Componentと呼ぶ)のClassを自作するときは、
記述自体はおおむねコード主体ですが、その際にPropertyの仕組みを使って、「(永続可能な)属性値の受け皿」を
作ってあげてるような感覚を覚えます。このCompoのこの属性をProperty(たとえそれが派生属性でも)として
宣言しとけば、あとは必要なときにDelphiが勝手に永続化してくれるから安心、みたいな。

Delphiが勝手に永続化
どうも「永続化」という言葉になじめていないようで、実は今までは“コード化”かなぁと勝手に思いこんで脳内置換をしてしまっていたのですが、ここへきて、それだと文脈がおかしくなることにやっと気がつきました(^_^;)。永続化、たとえばクラスベースにおけるインスタンスの永続化というのは具体的にはなんなんでしょうか？　なんかわかりやすいたとえ話をいただけるとうれしいです。--sumim

これ なんか読んでいると、インスタンスの永続化というのは、メタな言語でコード化することかとも思うのですが、同じ“コード化”でも、はき出したコード（記述）が処理系に非依存的、普遍的であることが大切なのでしょうか。それともこの手の“永続化”は使い方を間違っている？--sumim

まあ計算機だから全てはコードだと言う言い方も可能ですが(^^;、
永続化がコードなのだとしたら、そのコード体系には代入文しかない(笑)ってのが特徴だと思います。
汎用言語じゃない。IfもLoopも無いし自作も不可能。てゆーか変数も自作できない。決められた場所から場所へ値を送るだけ。 -戯

＃てか、Smalltalkこそ永続化のご本家(?)かも。Imageとかってソレじゃないんですか？

まあ超素朴なコード体系だから処理系なりなんなりに依存しにくい、ってのは事実でしょうけど、それが本質というわけじゃないと思います。

喩えですか。相撲の水入りの後の組み直し、かな。元々の相撲(つまり水入り直前)までは、両力士は動態の中でたまたまそういう位置関係になっていたわけですが、組み直しの時はむしろその「位置関係だけ」を再現する。あんな感じじゃないかな。

なるほど。では「インスタンスで構築した物をコードに起こしてくれるもの」は、「インスタンスで構築した物を Smalltlak コードで永続化してくれるもの」と言い換えさせてください。--sumim

＃ところで、ここらの一連のやりとりはリファクタリングして別頁にしたほうが良いかも。良いWikiNameが全然思いつかないですが(^^; -戯
＃＃永続化に持ってくがいいですかね？それとも学びにくさのほう？判断迷う…　移動しました。こんなのでいかがでしょうか。--sumim

話を戻すと、配布するときに必ずソースにしないとならないってのは微妙に変ですね。
テキストファイル(笑)に必要情報を書いておいて、そいつのLoaderとSaverが有れば済む筈なのですが…

まあ逆にいえば今の状態を復元する(=属性値を代入しまくる)コードを自動生成しても良いんでしょうけど、
「テキストファイル」を出力するよりも「テキストファイルを生成するプログラム(笑)」を出力するほうが
コストが低いかなとは思います。

＞配布するときに必ずソースにしないとならないってのは微妙に変
ん〜。私のオブジェクト感覚からすると、Smalltalk のコード（“ソース”をこのように脳内変換していますが大丈夫でしょうか…(^_^;)）はオブジェクト間のメッセージのやりとりを連ねたスクリプト（脚本）という認識なので、必要情報だけ書き出して、しかもおそらくそこには XML などの別の言語が絡む…というほうが回りくどく感じてしまいますね。ちなむと、Smalltalk にはクラスごとにそのインスタンスを生成するためのコードをはき出す storeOn: というメソッドを定義しておくのが作法で、このカスケードがうまく働けばコードは自動生成されます。うまく動けば(笑)。＞だめじゃん Squeak --sumim




さて。復元については、もう1つ。
「属性値の代入程度の簡単な手順で、状態が復元できるように、(Objectの仕組みレベルで)なっていないとならない」
と思います。

Objectは状態の塊です。処理結果の塊といってもいいし、流派によっては副作用(笑)の塊とも言います。
が、処理結果の塊は、処理の塊ではないのであって、「静止状態」が定義可能かつ読み書き可能

でないとイケナイんだと思います。

たとえコードであろうと、それが「とんでもない作業」になってはイケナイ。
自動化しないとイケナイってのもさることながら、
そこで自動的に生成されたコードが「複雑な」ものであってもイケナイ。
なる筈が無い(ようにしておかないとイケナイ)。

状態というものが気楽に出し入れ(読み書き)可能になっていて、
任意(?)の状態のスナップショットが取れるし復元も出来るという。
Objectの性質の1つとして、これは重要なんじゃないかなあ。



YAML

このページを編集 (5223 bytes)

Congratulations! 以下の 2 ページから参照されています。

This page has been visited 9915 times.