アカウント名:
パスワード:
でも、クラスに色々機能を持たせなくちゃならないことも多いので、そこで継承を使うか、別のクラスにするかみたいな話になって、んじゃ定石集めてパターン(design patterns)作りましょうって事になり、結局データベースで言うところの正規化とかみたいな話になるのでは?
なにが言いたいかっていうと、「直感」なんかじゃないぞって話。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
全てが表だと困っちゃう (スコア:1)
それでもRDBってものには複雑な(おいそれと賛美できない)気持ちを持たずにはいられないです俺。
なまじ表構造なもんだから、表と相性が良いとは限らないTreeだのNetworkだのの様々な構造を
取り得るデータ…最近の流行だとObjectですが…との間で、いわゆる
意味的インピーダンスミスマッチを、抱えさせられるんですよね。アプリ作ってると。これが辛い。
というわけでRDBもほどほどにしてOODBなりなんなりの時代になって欲しいなあ。
ええと。俺の理解が間違ってなければ(笑)、細か
Re:全てが表だと困っちゃう (スコア:2, すばらしい洞察)
(中略)O-Rマッピングで苦労なさっているというご主張について、そもそもそのTreeだのNetworkだの
を関係モデルとして正規化(Normalize or Normalization)若しくは非正規化(一応断っておきますが、
「非正規化」は「非正規形」のまま放置することではなく、一旦正規化したデータモデルを、さまざまな
目的から、その正規を崩すことを意味しています。)が十分でないからではないでしょうか?という疑問を
抱きました。
また、OODBについて言及なさっていますが、果たしてOODBとOOPは相性が良いのでしょうか?
(私はいまだに良くわかりません。それほど経験をつんでいないもので...)
それから、規則9(の日本語訳)のあなたの理解は読みきれませんが、後続の記述から類推すると誤解
されているようです。規則9のココロは、従前のアプリケーションとデータの一体化状態から脱却しての
独立性という意味です。
Re:全てが表だと困っちゃう (スコア:1)
>を関係モデルとして正規化(Normalize or Normalization)
OO的なやりかただと、正規化とか非正規化という考え方を(普通は)しないんですよね。
OO勢がやってる分析や設計は、とどのつまりは「直感」です。
直感的にすっきり納得できるデータの並べ方ならOK、という感じです。
#Objectをいったん全部ばらしてRDBに格納するという前述のやりかたならば話は別ですが、
#あーゆーやりかたは主流じゃないようなのでここでは置いておきます。
#素朴に1クラス1テーブルにするか、それの亜種的なやりかた、あたりが主流だと思います。
そして、直感から離れるようなヤリカタは、たとえそれが正規化やそれ以外の何かであろうとも、
あんまり受け入れられてない、と思って良いと思います。
正規化とかの論理的に裏付けられたヤリカタに、あえて(かどうかはともかく)背を向けてるという印象です。
冷静に考えれば、おっかない話ではあるんですが(笑)。
俺としてはOOP(というかOOA/OOD)は、「児戯指向」だと思っています。
つまり幼稚園児でも判るような(笑)直感のみに従ったヤリカタを選択しがち。
これ、OOPの元々の考え方であるシミュレーションやメタファというものが、
元来そういうものである、という面が有るせいだと思います。
そういやSmalltalkは子供でも使える言語を目指したものでしたっけね。
#とはいえ、だから悪いと思うことも出来ない俺。OOPって、馬鹿だから可愛い子みたいな感じなんですよ(^^;
まあ、高速化のためのノウハウも存在しますし、Objectであるがゆえに却って性能的に得をする面もある
(なんせObjectはそれ自体が何らかの情報のCacheみたいなもんですから、うまく使えば色々と…)んで、
悲観することもないかなーという気もしています。
というか、正規化とかの方向は、コッチ(笑)から見れば、
「やりすぎて人間様に理解しにくくなってしまった最適化」
みたいに見えちゃったりするんですよね。その捉え方が正しいかどうかは別として。
>OODBについて言及なさっていますが、果たしてOODBとOOPは相性が良いのでしょうか?
まともな奴なら、「そのまま」保存するように作られてるはずですから。
O-Rのようにマッピングをする必要が無いわけです。
>規則9のココロは、従前のアプリケーションとデータの一体化状態から脱却
ああ。そっちですか。
でもOO勢なら、そういう場合は「ドメイン領域のデータのクラス」という括り方をするだろうな。
ネジクギトンカチ的なクラスは「アプリに依存しないクラス」として作られて当然ですが、
ドメイン領域のデータでありながら同時にアプリ依存性を薄くした「直感的でない(笑)」クラスの作り方は、
OO勢はあんまり得意としていないんじゃないかな。
なんでもかんでもモデリング「して」しまうってゆー感じ。
後で変更したくなったらどうすんだ?とクビを傾げることが時折。
#数年越しの永続クラスの設計を(欠点が判っても)今更変更できなくて喘いでいるG7
(オフトピ)OOは直感か? (スコア:1)
> OO勢がやってる分析や設計は、とどのつまりは「直感」です。
> 直感的にすっきり納得できるデータの並べ方ならOK、という感じです。
オブジェクトというのを最初に素人に説明するときは、直感とか「もの」とかいう話になりますが、「分析と設計」ってことになると、モジュール化でしょう。coupling & cohesion. (定着してる訳は知らないけど、多分モジュール結合度と凝集度。)一つのクラスで色々やらないで、別々に分ける。(hi cohesion)で、なるべく他人の内部構造に依存しない。(lo coupling)
でも、クラスに色々機能を持たせなくちゃならないことも多いので、そこで継承を使うか、別のクラスにするかみたいな話になって、んじゃ定石集めてパターン(design patterns)作りましょうって事になり、結局データベースで言うところの正規化とかみたいな話になるのでは?
なにが言いたいかっていうと、「直感」なんかじゃないぞって話。
Re:(オフトピ)OOは直感か? (スコア:1)
>めてパターン(design patterns)作りましょうって事になり、結局データベースで言うところの正規化とかみたいな話になるのでは?
>なにが言いたいかっていうと、「直感」なんかじゃないぞって話。
いや、直感という言い方は確かにちょっとアレだったかもですが、
パターンは今度は「経験」の世界であるわけで、
それが機械的論理的に決まる世界ではないという点において、直感とは同類ですね。
つまり、自分ひとりのではないのだけど、大勢の人々の直感(笑)の集積物っす。
定石と論理的帰結とは同じではないわけで。
もしパターンが正規化と同じような位置付けのものだとしたら、
パターンは単純に「究極の答え」と「それを崩したもの」とに分かれていたんじゃないかな。
でも実際のデザパタは、「トレードオフ」の世界ですね。
2つのパターンの採用を比較検討するとき、しばしばどっちも究極の答えではない、という世界です。
#もちろん、論外に間違った選択もありえますが、そういうのはここでは数にいれる意味がないんでパス。
てゆーか、パターンの数がこんなに何十個もある(さらに、自作することも可能(笑)だし、
世間でも日々新たなパターンが作られてる(大袈裟?)わけだし)のを見れば、
「ああ、これはプリミティブでもなんでもないんだ」と思うモンなんじゃないかな。
#元素の数が多すぎるんで「原子は究極の単位ではないのでは?」と昔の科学者は思ったのだとか...
正規化って、パターンのような、直感だか伝統だか経験だか自然発生だかによって生まれたものじゃないですよね。
よだん:
正規化と同じくらいに究極の答えがもしOOPにもあるなら、
ある1つの分野におけるクラスライブラリは、そうそう何種類も作る余地が無かったのではないかな?
でも実際には色々なカタチのものがあるわけです。
それだけ恣意または偶然(笑)によって如何様にも出来る世界だということじゃないかなあ?
Re:全てが表だと困っちゃう (スコア:0)
正規化は、考え方ではなくて手法です。その目的は、"One Fact in One Place" で、関係(Relations(複数形です))の一貫性を保つために行うもので決して最適化ではありません。
一部の設計の方法論では、正規化/非正規化≒パフォーマンスチューニングのような方針で(正規化)作業をされることがあるようですが、これは正しい正規化/非正規化ではありません。
正規化作業が上手な人のモデリングを見ていると、あたかも直感的に行っているように見えることもあります。それこそ、クラ