どうにか汎用的なDB操作のWebソフトが作れないものかといろいろ考えているんですが、自分でイチから開発するとなるとちょっと不思議なことが起こってくるんです。ちょっと書き進めてゆくと「自分で設定したルールが自分でわからなくなる」というものです。これ、村上龍氏が主張するような「奴隷になるな！」的な理論の矛盾といいますか、能動的な行動でもって複雑なものを生み出してゆくという最終的な姿は、「自分の奴隷になってしまう」という結末があるんです。これ仮に「非奴隷の矛盾」というような言い方にしておきます。
　そんなわけで、非奴隷の矛盾に従って、自分で決めたルールを自分に強いるという意味では、もう誰に従ってんだかわからなくなってきます。そういう意味で自由で能動的で主体的であるということは、過去も未来もない刹那的な生き方になってしまうと思います...が、何せプログラムでもって何かを開発する際には、アイディアと発想は未来に、ソースと汎用関数は過去にあるわけで、どうやったって文学的な刹那主義になり切れないところがあるんですね。ソースという実体（があるんだか、ないんだがですが、仮にあるとして...）があって、整理整頓しないといけないわけでして、その整理整頓（つまりは設計）でもってアイディアが実現されるわけであって、時間的な行き来はもうとんでもなく頻繁で、自分が未来にいるんだか過去にいるんだか滅法わからなくなってくるのです。
　で、大きなプロジェクトになってくるとそのタイトルが必要になってくる。ここでは仮にLily Extensionとして、略してLEということにしています。しかしこれ、仮にとしておくと、最終的に完成するまでLEという名前になってしまうのが怖いです。命名は真面目にしないといけません。しかし、それでもLEは、そこそこのルールに従って開発しないといけません。いわゆるフレームワークというやつです。

クラスのルール

　クラスはとんでもなくいろいろなことができます。オブジェクトのプロパティーではほぼ好きなだけ変数を設定できます。通常のFunctionに与える引数は、どう考えても3つ、多くても4つが限度で、それ以上の引数は配列にして一度にぶち込んでやった方が親切です。しかし、ある文脈に沿った設定情報なり出力を制御する関数に対して、引数だけでは全然ダメで、やっぱり最終的にはクラスでもってオブジェクトを生成しないとまともな開発ができない...ということになります。このまともな開発というのは、

常にバージョンアップができる。（拡張ができる）
設計がちゃんとしている。（設計情報がちゃんと残っている）
インターフェイスがちゃんとしている。

の３点につきます。
　で、このクラスに関する徹底したルールは、

基本的には引数が一番最優位の情報にする。
次にクラス内部のプロパティーの情報。
次にオブジェクトに外部からプロパティーに設定した情報。

というルールにしておきます。これだと、複数の手段で内部の変数にアクセスできるので非常に便利。
　もう一つのルールは、

クラスのプロパティーは、設定情報を取得するプロパティーと出力するプロパティーにしっかり分ける。

ということです。これ、どういうことかというと、クラスから生成するオブジェクトは、プロパティーに値を設定する、という１つの機能しかないんですが、機能が１つなのに設定すべき場所が複数あるのです。それは、クラスの外側から、クラスの内側から、ということなのですが、クラスの外側から設定する値は引数に近い。しかしクラス内部で設定する値は返り値に近いんです。ある関数が何やらをごちゃごちゃと計算して結果としてクラス内部のプロパティーにセットして後から取り出すことができます。これは概念としては返り値に非常に近いのです。これらのプロパティーを完全に分けておくこと。つまり、

クラス外部から設定するプロパティー（限りなく引数に近い） [IN]
クラス内部で設定するプロパティー（限りなく返り値に近い） [OUT]

というものです。
　大規模な開発では、だいたいここらを使います。要は通常の関数のような引数と返り値を使わないですべてプロパティーとして入出力するようにします。こうすることでかなり複雑ないろいろな値を設定したり取り出したりできるというわけです。