PHPでオブジェクト指向プログラミング
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
2005/04/17(日) 16:55:57ID:iM4mgYnJPHPによるOOPについて語りましょう。
0332328
2005/06/20(月) 03:52:16ID:???パスワードのチェックを一生懸命頑張ってるのはわかったよ。
そこまでやると利用者にとってはムカつくだけの機能だけどなw
ちなみに俺はifの話をしてるだけなので。
ifは3回で済むやんその部分・・・
と言ってみる。
ちなみにもう一回言うけど、あんたがifを並べて書く分には文句ない。
>>315から始まったifダラダラが嫌な方々に対しての話だから。
それとも>>329=>>327=>>324=>>320=>>319=>>317=>>315だった?
それだったら必死こくのもうなずけるw
0333nobodyさん
2005/06/20(月) 07:26:24ID:???Singletonやたら多くね?
RequestやらSessionやらControllerやら、
基幹部品ほとんどSingletonになるやん。
0334nobodyさん
2005/06/20(月) 10:13:11ID:???まあ WebProgramming ってのはそういうものな気がする
漏れが1クラスで2つ以上のインスタンスを作るのって composite 系ぐらい
0336332
2005/06/20(月) 17:13:53ID:???あ、そいつは失敬・・・orz
なんか俺が書いた332の文章読み返してみたら、そうとうイパイパイだな。
反省。
>>333
たしかに制御部分なんかはシングルトンばっかだけどコンテンツと直接関連するとこはけっこうインスタンスつくるな。
インスタンスつくればつくるほど(OOじゃない場合に比べて)重くなっていくのがウザイけど。
PHP5だとその辺いかがなもんだろ?
0337333
2005/06/20(月) 19:57:28ID:???Singletonは実装がちょっとだけ面倒だな。
継承で実現できないから毎回同じルーチンをコピペしなきゃならないし。
>>336
4のなんちゃってOOよりは速くなってるはずだよ。
俺もインスタンスのリストも作ってるけど
DBから読んでいっぺんにオブジェクト全部作るより、
一つずつインスタンス作っては表示した方が、メモリ消費量は少ないよなぁとか思いだしたら
一層Singleton傾向が強くなっていくんだよな。
0338nobodyさん
2005/06/20(月) 22:01:02ID:???結構書かれててビビる。
でも便利すぎるから使いまくりな俺。
大丈夫、ResultやらControllerやらConfig何個も作るなんて
アリエナイアリエナイ……
ほとんどデータ格納系となんかの基底クラスだけだ、シングルトン使ってないの。
ヤバいか。ヤバいかも。
0339nobodyさん
2005/06/20(月) 23:34:21ID:???Singletonは便利な反面、保守性を低くしがちでもあるから諸刃の剣だよな。
継承できないのもイタイ。アクセス制限もシンドイ。
でも便利・・・。
誰かもっとビューティホーなデザパタ考案汁!
とりあえず使いすぎない程度にほどほどでいった方がいいと思うけど。
>>337
基本的には一つずつインスタンス作って表示でいきたいんだけどね〜。
ちょっと特殊なソートをやるときってどうしてもまとめて読み込むしかないんだよな。
ソートが必要だと一般にDBにやらせてもどうせ同じだけメモリ食ってるだろうし。
(詳しく知らんけどたぶん)
っていうかPHPにソートをやらせると速度激減w
0340nobodyさん
2005/06/20(月) 23:58:34ID:???その逆も楽。
あっすまん。PHPだと無理だ。
0341nobodyさん
2005/06/21(火) 01:22:49ID:???0342nobodyさん
2005/06/21(火) 03:18:21ID:???0343nobodyさん
2005/06/21(火) 05:18:57ID:m8dmNWb0一つの画面に複数の要素が入ってきて、
要素構成が動的に変化する場合、
viewにどんなオブジェクトを渡すのがいいかな?
たとえば同じRankingオブジェクトでも
メインコンテンツになったりサブコンテンツになったりするので、
Model層でView的な意味あいを考えなくちゃいけないというかさー
ModelにいながらViewしてんじゃんみたいな気持ちになるんだよな
うまいことできねーかな
0344nobodyさん
2005/06/21(火) 06:59:34ID:???Viewは出力しかしないって方向性で。
0346nobodyさん
2005/06/22(水) 16:07:00ID:???0349nobodyさん
2005/06/23(木) 16:32:51ID:???MもVもCもクラス作るんですか?
そして全部シングルトンですか?
教えてくれた人に投げキ○ス。
0350nobodyさん
2005/06/23(木) 16:46:02ID:???基本クラスになるでしょ。
0351nobodyさん
2005/06/23(木) 16:51:40ID:???0352nobodyさん
2005/06/23(木) 17:08:39ID:???だからincludeのみなのは
ちょっとおかしいかも
Modelで意味レベルの情報をViewに渡して
Viewは表示用に整形して、テンプレートに組み込む感じ。
0353nobodyさん
2005/06/23(木) 17:45:35ID:???0354nobodyさん
2005/06/23(木) 18:26:23ID:???>>279です。
VとMはクラス作ってやってます。簡単なものであれば、Cはメインルーチンに突っ込んでます。
メインルーチンはこんな感じ。
$form =& $_POST;
$action = new Action();
$result = $action->execute(&$form);
// 省略するけどここで$resultによってエラー処理などを行う
$view = new View();
$view->execute($form);
フォームの「入力」「確認」「完了」「エラー」のように複数のアクションがあるものは、
MVCを1つずつ作ってメインルーチンからCを呼び出してます。
継承させるとコストが掛かるし呼び出すファイルの枚数考えたらバカバカしいので、
テンプレートのようなコードをMVCの3つ用意しておいてページをつくるたびにコピーして書き足してます。
ただしCを書き直す場面はほとんどないです。
全部シングルトンっちゃシングルトンだけど、本来のシングルトンのように
明示的にインスタンスの複製を禁止するような機構は組み込んでません。
>>353
俺のことかな。
0355nobodyさん
2005/06/23(木) 19:44:02ID:???PHPだしラフに書くことが多いみたいね。
なんかちょっと前まで、このスレ読んでて「みんなシングルトンしっかり書いちゃってるのか?」とか疑問に思ったりした。
まあ結果的にインスタンスを一個ずつしか作ってないってことかな。
そんな漏れはincludeしまくり野郎。
ガンガンファイル数増えるね。
メソッドの中でのincludeはOOのありがたみを感じるな。
0356nobodyさん
2005/06/23(木) 20:04:04ID:wsWVtbWS強制するものだということは分かるんだけど、
どんな利点があるのか良く分からないです。
詳しい解説キボンヌなんですが。
0357nobodyさん
2005/06/23(木) 20:23:05ID:???プログラムのどこからでもアクセスできる、ってのが
便利なんだと思う。
俺も>354みたいな感じで処理してるけど、
resultオブジェクトなんかは、そこら中でインスタンス作ってると
Viewで処理するときに混乱しやすいから、Controllerの最初の方で
インスタンス化しておいて、プログラムが走ってる間はそのインスタンスに
アクセスして処理すると。
最終的に全クラスのエラーや処理結果が格納されるから混乱しない。
0358nobodyさん
2005/06/23(木) 20:23:28ID:???> 強制するものだということは分かるんだけど、
それが利点。
たとえばシングルトンにするクラスが他のクラスのインスタンス情報をプログラムの開始から終了まで一括管理してる場合、ヘタにnewされちゃうと管理してた情報が水の泡になってしまうことにもなる。
だからそれを防ぐためにシングルトンにする。
まあ通常はコンストラクタをpublicじゃなくすことで、外部での勝手なnewを禁止するのが常套手段。
だがしかし、PHP厨はただ単純にnewを一回しかやらないことをもって「シングルトン」と呼んでいるらしい。
何か違う気もする。
0359nobodyさん
2005/06/23(木) 22:13:04ID:???HTTPだと、リクエストごとにオブジェクト作り直しなんだから。
0360nobodyさん
2005/06/24(金) 01:05:47ID:???という認識だな
単に一回しかnewしないと自分の中で決めているだけだったら
後から見返した時、呼び出しだけ側だけ見ててもわかりにくいし。
0361nobodyさん
2005/06/24(金) 06:46:55ID:???結局Singletonだけですか?
Composite使いがどこかにいたような。
Listを作る人もいたような気がするのでIteratorも書くのかな?
教えてエロい人!
0362354
2005/06/24(金) 08:05:16ID:???Conpositeパターンは階層構造をサポートしたwiki作る時に使った記憶があるな。
Iteratorは特に意識しなくてもたまたまそういう実装になってしまう時がある。
DBによらない(DBならLIMITで対応できるから)リスト表示でページャをサポートする時など。
そもそも俺はデザインパターン原理主義ではなく、考えた末の実装がたまたまどれかの
デザインパターンに一致することの方が多い。基本的なデザインパターンは一通り
頭に入れてあるが、設計する時にパターンの一覧表とにらめっこしてどれに当てはめるか
考えたりするような真似はしない。
0363nobodyさん
2005/06/24(金) 08:21:41ID:???あんまり見てないけど
ActionChainがなくなったらしいので、その代わりになるようなものなのか
0364nobodyさん
2005/06/24(金) 10:34:44ID:???両方使ったことあったらそれぞれの長所短所を挙げてちょうだいな。
0365nobodyさん
2005/06/24(金) 11:13:34ID:???時代の趨勢は
Mojavi>>>>>Phrameって感じ
Phrame触ってみたことないので中身は知らないけど
0367nobodyさん
2005/06/24(金) 12:32:34ID:???0368nobodyさん
2005/06/24(金) 13:26:31ID:???Mojavi2を一回しか使ったことないけど、その感想。
恐らく勘違いしまくってると思うのでMojaviマスターの方ツッコミ入れてください。
んで便利さを俺に教えてください。
MVCフレームワークとしては良く出来てるが、Webアプリケーションに
ここまでする必要あるのかなあという疑問はある。基本的に全ページ同一の
index.phpから呼ばれる設計になるので、Webの階層構造の利点を捨てて
しまっている。URL_FORMAT=2も冗長。
mojaviのファイル階層が深くて作業しにくい。階層構造になってるのにファイル名長すぎ。
(Action数) * (Actionの戻り値数)個のViewを定義しなきゃならんので、同じような内容のViewが
ずらずら並んでしまう。diff取ったらTemplateファイルを定義してる行だけ違ったとかありがち。
なもんだから、View+フォームフォーマッタand/orテンプレートエンジンとの連携のところや、
Action(Module)とDaoの連携のところで汚い実装をしちゃうと取り返しのつかないことになる。
ほとんど同じ顔の汚いコードがずらり、みたいな。というか既にそうなっちゃってるところ多し。
「純粋にMVCは提供しただけ。後は好きに使ってくれい」みたいな感じのところがあるので、
プログラマの質によって非MVCスクリプトよりもタチの悪いグチャドロのコードになったり
非常に便利に使えたりの差が大きいと思う。
0369nobodyさん
2005/06/24(金) 14:07:51ID:???たしかにViewだらけになりそうと思った
でもView名は必ず変えなくちゃいけないというわけでもないから
色んな状況を一つのViewクラスで受けてもいいじゃん。
わりと融通がききそうという印象はあるな
0370nobodyさん
2005/06/24(金) 14:59:01ID:???>>368
> 基本的に全ページ同一のindex.phpから呼ばれる設計になるので、Webの階層構造の利点を捨ててしまっている。
DocumentRoot下をちゃんと階層分けしてそれぞれのファイルにアクセスしてもらうように作るのは厳しいかな?
> mojaviのファイル階層が深くて作業しにくい。階層構造になってるのにファイル名長すぎ。
> 同じような内容のViewがずらずら並んでしまう。
禿同。
思ったけどcontrollerの中の〜Exists()をオーバーライドして〜Action.class.phpなどを強制的にやめてファイル名短くするってのはどうかな?
元々付属してきたファイルのケアしなきゃならんのは逆にしんどいだろうか?
まだ始めたばかりなので色々模索中。
0371nobodyさん
2005/06/24(金) 15:00:33ID:???dispatchメソッドの引数にmodule名とaction名を渡せば良いよ
俺はフロントコントローラーとして使ってるけど
おまい様の言うとおりurlが冗長になるので
少しプログラムに手を入れて
index.php/module名/action名
で呼び出せるようにしてる。
mod_rewriteを使うという手もあるね。
2つめは、同意。
仕方ないので我慢してる。
しかし、逆に構成がはっきりしてるので
分かりやすいという利点もあるような気もする。
3つめは、その通りだと思う。
でも、mojavi3-devの次期verで解決するっぽい?
1つのactionにつき1つのviewに対応させるみたいだけど
どうなるのかね。
ttp://forum.mojavi.org/index.php?showtopic=975
0372nobodyさん
2005/06/24(金) 19:58:11ID:???0373nobodyさん
2005/06/25(土) 00:49:00ID:???全部VIEW_SUCCESSを返して(Requestに状況説明ほりこみつつ)
一つのViewクラスで処理するとかすればいいんでないの?
俺が勘違いしてる?
0374nobodyさん
2005/06/25(土) 02:58:54ID:???> 基本的に全ページ同一のindex.phpから呼ばれる設計になるので、Webの階層構造の利点を捨ててしまっている。
どんな利点があんの?
同一から呼ばれてるからこそのフィルタ処理とかのメリットがあるんだが、それ以上のメリットがあるの?
0375nobodyさん
2005/06/25(土) 03:06:12ID:???>(Action数) * (Actionの戻り値数)個のViewを定義しなきゃならんので、
これ間違いね。
例えば、追加と編集のフォームやバリデーションなんかはViewのロジックはほとんど同じだから、
追加でAction&Viewを作ってやって、編集ではforward&VIEW_NONEでOK
編集用のViewは作らなくてすむ
0377nobodyさん
2005/06/25(土) 03:23:44ID:???>同一のファイルから呼ばれなくても同じクラス再利用すればいいのでは?
いってることが違うんだけど、どう言えば理解できるかなぁ…
0378376
2005/06/25(土) 03:27:27ID:???> 同一から呼ばれてるからこそのフィルタ処理とかのメリットがある
の部分だけにつっこんでみた。
>>368への反論としての意味は考慮してなかった。
0380nobodyさん
2005/06/25(土) 03:31:04ID:???index.phひとつpで経由してるから、個別の処理をクラスとして定義できて、forwardやactionchainみたいな
処理が可能になってるわけだけど、バラバラにしちゃった場合どうすんの?
あ、あとmod_rewriteでいじくる場合もこっちのが楽っぽいよね
0381nobodyさん
2005/06/25(土) 03:33:03ID:???↑まちがえた
0382nobodyさん
2005/06/25(土) 03:35:40ID:???dispatchの引数色々変えられるし。
ファイルわけとけば継承した自作Controller呼べる選択の余地もあるし。
とか言って実際やってみたわけではないがw
0384nobodyさん
2005/06/25(土) 03:39:29ID:???0385nobodyさん
2005/06/25(土) 03:46:31ID:???これはあんまりメリットにならんよね。
Controllerが違う時点でMVCから外れちゃってるし
てかactionChain理解してる?
0386nobodyさん
2005/06/25(土) 04:12:24ID:???Strutsの場合はサーブレットを基点に考えられてるから、そうせざるを得ないかもしれないけど。
ユーザやデザイナ、更新作業するオペレータって、ディレクトリ構造になれてるからね。戸惑うことが多いだろうね。
SEO的にも問題があるし。
0387nobodyさん
2005/06/25(土) 04:16:35ID:???MojaviとかSmartyはむしろもっと機能を減らした方がバランスがいいんじゃないかな。
0388nobodyさん
2005/06/25(土) 04:39:46ID:???たぶん話がくいちがってるな。
まず俺は「ファイル分け推奨派」側ではないので。べつにindex.phpで問題なし。
ただファイル分けしたいとかいう意見も面白いと思った。
同じサーバ上で複数の異なるサービス展開したいとか、URLレベルではModule/Actionの組み合わせ以外でアクセスされたいとか個々人で事情があるんだろうし。
まーMojaviの標準から外れた方法使う分手間はかかるだろうが、大したことないでしょ。
で、その上で俺の言いたかったのは、再利用するなら同じクラス(または継承クラス)使えばいいだけでしょ、という話。
フィルタだろうがアクションだろうが。
別にファイル階層化の方が利点があるかどうかには俺は言及してない。
0389nobodyさん
2005/06/25(土) 06:56:49ID:???まーね。
とは言っても小規模ならフレームワーク使わなくてもいいわけだし、MojaviやSmartyはPHPの可能性を広げてるって見方もあると思うけど。
「不必要な機能は使わなければいい」ってのは当たり前に思えることにもかかわらず、実際にはそれが明確になりにくいから「無駄に多機能」って印象も生まれるんではないかと。
高機能・多機能にすればするほど重くなるのは確かだが、MojaviやSmartyで「無駄に重くなってる」って感じはしないかも。
0390nobodyさん
2005/06/25(土) 14:50:03ID:???俺はアクセスカウンタでも自作フレームワーク使ってるけどね。
MojaviもStrutsもそれ自体の機脳をおぼえなくてはいけないので
冗長すぎると俺は思う。
0391nobodyさん
2005/06/25(土) 14:59:09ID:???片っ端から全部覚えようとするから冗長に思えるのでは?
0392nobodyさん
2005/06/25(土) 15:32:24ID:???> Webの階層構造の利点
これについては、URIにおいて階層構造でドキュメントの位置を特定できるという
本来のWebの意義を捨てるのはどうなのかなあという事です。
階層ごとにアクセス制限をつけるといったこともやりにくいですよね。
>>371の方法はスマートですね。なければ作れよと。自分がプログラマなのを忘れてました。
>>373
それだと何のためにActionがリザルトコード返してるんだよ?って問題になりそうなので。
エラー処理をVIEW_SUCCESSに処理させるのって見通し的に問題ありません?
>>391
冗長すぎるというよりも、Webの世界ではmojaviが当てはまるほどの規模の開発があまりないって事ですかね。
いまだに「会員登録」「一覧表示」「ドキュメント管理」「買い物システム」みたいな案件が多いですから。
先般mojaviで頼まれた案件は、自作のフレームワークの方が工数1/4くらいで済みそうでした。
昔作った計1000ページ近くに及ぶ顧客・企業・オーナーを結ぶデータベースへのアクセスインターフェイス、
あのくらいの規模だとmojaviでやったら工数減ったかも。
0393nobodyさん
2005/06/26(日) 05:32:44ID:???まずパッケージの中身見たらSmartyViewが空っぽでした。
とりあえずPHPViewをほぼ真似てSmartyViewを自作。
しかし、Smartyのキャッシュ機能のせいで、ActionとかFilterとか編集したときにそれが反映されない。
仕方ないので編集中はSmartyのキャッシュを無効に切り替えて対応。
なんか今後も振り回されそうな悪寒もあり。
よりよい方法はありませんか?
0394nobodyさん
2005/06/26(日) 12:03:06ID:???とりあえず「もはび」と語尾上がりで読んでしまう。
桶?
0396nobodyさん
2005/06/26(日) 13:08:30ID:???0397nobodyさん
2005/06/26(日) 13:10:59ID:???0398nobodyさん
2005/06/26(日) 13:12:33ID:???0399nobodyさん
2005/06/26(日) 13:36:13ID:???0400nobodyさん
2005/06/26(日) 13:40:55ID:???0401nobodyさん
2005/06/26(日) 13:47:17ID:???0402nobodyさん
2005/06/26(日) 14:08:20ID:???0403nobodyさん
2005/06/26(日) 14:11:37ID:???0404nobodyさん
2005/06/26(日) 14:28:16ID:???0405nobodyさん
2005/06/26(日) 14:28:58ID:???|´∀`';/^l
|u'''^u;' |
|∀ ` ミ ダレモイナイ・・・
| ⊂ :, モジャモジャ スルナラ イマノウチ
| ミ
| 彡
| ,:'
|''~''''∪
l^丶
モジャモジャ | '゙''"'''゙ y-―,
ミ ´ ∀ ` ,:'
(丶 (丶 ミ
(( ミ ;': ハ,_,ハ
;: ミ ';´∀`';,
`:; ,:' c c.ミ
U"゙'''~"^'丶) u''゙"J
/^l
,―-y'"'~"゙´ | モジャモジャ
ヽ ´ ∀ ` ゙':
ミ .,/) 、/)
゙, "' ´''ミ ハ,_,ハ
(( ミ ;:' ,:' ´∀`';
'; 彡 :: っ ,っ
(/~"゙''´~"U ι''"゙''u
0406nobodyさん
2005/06/26(日) 16:24:17ID:???0407nobodyさん
2005/06/26(日) 16:27:02ID:???もうねぇ、語源とかどーでもいいよ。
俺たち日本人はアルファベットを見るとローマ字読みしたくなる人種なんだよ。
モジャビ、モジャビ。
モジャビで決定。
>>405
わかったわかった。
0408nobodyさん
2005/06/26(日) 17:24:40ID:???日本人は律儀な方だと思うよ。アメリカ人なんてグルジア共和国
とかヨハネ・パウロ二世とか全部英語読みだもんな。
「mojavi pronounce」でググったらこんなん見つけた。
やっぱり奴らはモジャヴィで抵抗ないらしい。
http://forum.mojavi.org/index.php?showtopic=1077
つーかググった結果が33件って。mojaviでググっても
日本語のページばかりだし、日本でしか流行ってないのか。
0409nobodyさん
2005/06/26(日) 18:14:35ID:???そこの書き込み読ませてもらったけど、モハーベ砂漠(アメリカにある砂漠)に倣ってhで発音する派もいるみたいじゃん。
ちなみにモハーベ砂漠のMojaveの発音は「モゥ・ハァ・ヴィ」って感じのようだ。
ハァのとこにストレスで。
http://www.answers.com/mohave
↑発音も聞けるw
あと、「33件かよーっ!?」って思って俺もググってみたら実際はもうちょい出たよ
http://www.google.com/search?hl=en&q=mojavi
Results 1 - 10 of about 45,200 for mojavi. (0.04 seconds)
とりあえず俺はモハービでいくとするかな。
0410nobodyさん
2005/06/26(日) 20:06:06ID:???> あと、「33件かよーっ!?」って思って俺もググってみたら実際はもうちょい出たよ
いや、33件しか出なかったのは 「mojavi pronounce」でググった結果について。
mojavi単体で45,200ってのもかなり少ないね。
日本語googleの結果が1万件くらいだから1/4弱が日本語のページってことになる。
0411nobodyさん
2005/06/26(日) 20:45:24ID:???日本人の情報収集力の高さと見るか。
単に新しいもの好きですぐとびつきたくなるタチと見るか。
0412nobodyさん
2005/06/26(日) 21:36:48ID:???ちょっとしたフレームワークを作ろうと思って、
Factoryに引数を与えるとその名前でクラスを生成してくる、
みたいなのを考えてるんですが。
0413nobodyさん
2005/06/27(月) 00:51:05ID:???できなくてもeval()使えば確実。
0414nobodyさん
2005/06/27(月) 01:58:50ID:???のように一度作ったオブジェクトを削除するにはどうしたらいいんですか?
unsetだとだめっぽいんですけど。
0415nobodyさん
2005/06/27(月) 05:13:50ID:???0417nobodyさん
2005/06/27(月) 08:45:57ID:???いつの間にかアメリカの歴史の話になっている。
恐るべきスレだな・・・。
みんなもWebProgばっかやってちゃダメだぞ。
0418nobodyさん
2005/06/27(月) 20:12:48ID:???別に速度は変わらないんでしょうか。
0419nobodyさん
2005/06/27(月) 21:33:03ID:???0420nobodyさん
2005/06/27(月) 22:20:41ID:???Thx, eval関数の中でnewすることで作ったよ!
PHP4は型制限が緩いから俺様フレームワーク作るのは結構簡単だーね。
他人に使ってもらって使いやすいってのは難しいけど。
インターフェイスとか無いし。
PHP5で追加されたんだっけ。
0421nobodyさん
2005/06/28(火) 08:50:18ID:???速度に関しては何とも言えんな。
PHP5のオブジェクト指向に関する利点は、カプセル化、抽象クラスとインターフェース、__autoloadあたりの「機能」面だと思う。
オブジェクトの参照をうまく扱うようになったみたいだからメモリの使用量は減ると思うけど、その恩恵が得られるのは大量のオブジェクトを生成した場合くらいだな。
まあ元々Webプログラミングではオブジェクトを無闇にガンガン生成しないってのが鉄則だから、メモリに関しても速度に関してと同様に大して利点と言えないかもね。
0422nobodyさん
2005/06/28(火) 08:55:01ID:???あのさぁ、マニュアルに思いっきり載ってるんだけど。
http://www.php.net/manual/ja/language.oop5.patterns.php
俺ならevalではなくnew $classnameだな。
0424422
2005/06/28(火) 09:59:34ID:???Mojavi3ではファクトリーの実装でINIファイルをパースして、適切なクラス名のオブジェクトを生成するPHPのコードを自動生成してるみたいだ。
INIを編集しない限りは生成されたPHPファイルをそのままrequireしてるね。
ま、Mojaviの場合はシングルトン実装するために結局はnewInstance($class)メソッドの中で
$object = new $class();
とやってるけど。
っていうかPHP5イイな。
シングルトンをラクラク継承できる。
>>423
はい。>>423の勘違いぶりよりは幾分マシですが。
0425nobodyさん
2005/06/28(火) 11:04:43ID:???0427nobodyさん
2005/06/28(火) 13:05:11ID:???0428nobodyさん
2005/06/28(火) 13:29:41ID:???staticな$instanceは、継承したところで基底クラスにしか存在しないだろ?
0429nobodyさん
2005/06/28(火) 13:56:05ID:???0430nobodyさん
2005/06/28(火) 14:03:58ID:???継承したクラスからgetInstanceすると、すべて同じインスタンスをgetしてしまうから、
継承は出来ないんじゃないの?
424は自分でやってみてから言ってるのか?
■ このスレッドは過去ログ倉庫に格納されています