PHPでオブジェクト指向プログラミング

PHP5になって本格的なOOPができるようになったので
PHPによるOOPについて語りましょう。

2ですよね？

PHP5のせいでPHP(・ー・)ｵﾜｯﾀﾅ･･･
http://pc8.2ch.net/test/read.cgi/php/1113715166/

PHPって普通にべた書きできちゃうから
あまり本格的にOOPしてる人は少数なんだろうな。

>>4
あえてべた書きにすることもあるな。貧弱なサーバで速度を稼ぎたいときとか。

このスレは速度を多少犠牲にしても洗練されたコーディング
（オブジェクト指向）をする為の情報交換スレにしたいと
思っております。

PHP5のnamespaceってどういう経緯で不採用になったの？
個人的にはinterfaceなんかよりも欲しい機能だったのだが。

class Net_Foo_Bar_Baz {} みたいなのとはオサラバしたいのに。

PHPでOOPするくらいなら素直にJava使えば良いんじゃないの？

Javaはそこいらのレンタルサーバーに入ってないから使い物にならん。

>>8
いや、当然Javaも使ってますよ。
でも適材適所というか、Tomcat動かす程でもねーなっていう案件もあるわけで。

>>10
同感。規模によって PHP は Java より数倍早く作れるし。

と言えども、PHP3→PHP4→PHP5と全然違うから、毎年覚え直しで開発効率云々も無意味。

JAVAでフレームワーク使うと、めちゃめちゃ早く作れるから、PHP最高というのも昔の話だし。

PHPにフレームワークが無いとでも？

まあ、Javaの方が安定性も洗練度も上だわな。

PHP5がこなれるにはまだ時間がかかるでしょ。
でも、OOPと呼ぶには中途半端な仕様なので、
数年後にはPHP6でまたがらりと変わってやり直し、
ってことになるような悪寒。

PHP4はこれからも結構長く使われるのではないかな。
できればPHP5よりPHP4のメンテナンスに力をいれて欲しい。

>>12
「全然違う」！？
「毎年覚え直し」！？
どんな低脳君なんですか！？

>>16
なんつーか、4.3の時なんて、マイナーバージョンアップなのに
さっぱり動かなくなったりとか、ひどかったからねぇ。
その前はmb_stringの問題で回避しながら書いてたら、
いきなり使えるようになったりとかさ。
ともかく、他の言語では考えなくて良い無駄な労力が多くて疲れる。

困ってないと言うことは、それだけ何もやってないと言うことだから、
別に君はPHPに拘る必要はないと思うよ。
PHPの動き始めてからの面倒くささは、作った奴なら一度は感じることだと思うし。

セキュリティもバージョンアップも無視して、同じバージョンを使い続ける覚悟でもあれば別だろうが。

>>15
どこら辺が中途半端なのか詳しく教えて。

数値型・文字列型などの基本型がオブジェクトになっていない

プリティーでキュアキュア

>>19
それって致命的か？
そもそもPHPって型とか意識しなくていいのが売りでしょ？

だから反対に困ることもある

らしいよ。理由は知らないけど

問題を抱える人は
その人自身に問題があることが多い

型フリーなお気楽路線にしたいのか厳密かつ大規模なプロジェクトで信頼性得られるほどお固いOOPLにしたいのかよくわからんよな
どっちもイケるのを目指してるんだったら考え直すか二分化するかした方がいいかもねぇ

その中間じゃない？

Java みたいに面倒ではなく、
デザパタができる程度には OO 化で丁度いいと思うよ。

PHP-light とPHP-Fullって2バージョン作るべきだと思う。

PHP-light → Ruby
PHP-Full → Java

PHP-standard → PHP5

リリース前から言われてたことだけど、やっぱJava意識しすぎだろと思う。
PHP5専用のOSSプロジェクトも幾つか見かけるようになってきたけど、
やたらと「Javaの〜の移植」ってのを目にするし。

PHP5になって、OO機能が充実して、出来るようになったことが
「Javaから移植しやすくなりましたよ」ってだけじゃ悲しすぎるだろ。
それは言語の存在意義を否定することじゃないのか。

じゃあC#はどうなるんだ

C#の存在意義ってまさに「Java潰し」だったから、それでいいんジャマイカ

PHPの存在意義って... なんだろう?

Perl潰し

あっなるほど

逆にやられるわけだが。

うほっ、いいPHP…

Java でやるの面倒な案件が PHP なら簡単に書けるから
Java から移行している、ってのもあるんだと思うよ。

>>36
あるか？
PHPで作ったけど問題出てきたシステムを、JAVAに焼き直したことはあったが…

>>37
それはＰＨＰの問題なのか？
単順に作りが悪いだけだったんじゃないのか？

PHPでは問題が起きて、Javaじゃ問題が無いって、例えばどんな問題なの？

どう考えてもメンテナンス性のような気がするが。

>>39
それは、メンテナンスし難く作ったとかPHPに熟知してる人間が少ないとか
そういった問題じゃないの？

PHP の大きな利点と言われる「簡単に書けること」を生かすと
メンテナンス性が悪くなるように感じる

一方 PHP でもメンテナンス性の高い書き方はできるのだが
そうすると上述の利点が、全部ではないにしろ、相当に失われるように思える

もちろん両方を少しずつ犠牲にして中間を取ることもできるのだが
それを中庸と見るか中途半端と見るかはまた意見のわかれるところ

でまあ、あくまで私見だが、pear とかのまじめな開発者は別として
これまで世の中で「PHP書けます」と自称していた人の大半は
メンテナンス性を犠牲にして簡単さを重視していたような気がするよ
それはPHP自身ではなくそれを使う人間の側の問題なんだろうとは思うけど

>>41
概ね同意かな。

しかし「簡単に書ける＝メンテナンス性が悪くなる」は
必ずしも成り立たないのだから、簡単に書けることがウリのPHPには
「簡単に書けて、かつメンテナンス性も（あまり）悪くならない」方向を追求して欲しかった。
が、実際にPHP5で強化されたのは、専ら
「メンテナンス性は向上するが、簡単ではない（かも知れない）」類の機能だったわけで、
結局簡単に書く＝メンテナンス性悪の図式はそのまんまなんだよな。

JavaみたいにガチガチのOOPを強いる言語もいいけど、
PHP5のように簡単に書けるけど、Java風のしっかりとしたOOPも
できる見たいな方が好みかな。

そして書く人によって品質に差が出てしまって後で困る。

自分は今携帯向けサイトのJAVA→PHPの移行の仕事してる。
なんかJAVAでパフォーマンスが悪すぎたのでPHPに切り替えることになったらしい。
JAVAが悪いというよりは、作りが悪いだけだと思いますが。

コーディング規約や使用するライブラリ類を規定して
なおかつソースレビューとかすればPHPでも品質はそれほどばらつかないと思うよ。
それからメンテナンスし易いような作りにしても、全然難しくならないので、
簡単に書けるというPHPの利点は全く失われないと思う。

>>44
仕事で使うならの話だけど
そこら辺は社内のコーディング規約でどうにでも
なると思うけどね。

>>44
Javaはその差が少ないって一般的に言われてるけど、
実際は全くそうじゃないんだよな…

>>45
JavaってPHPよりパフォーマンス悪いの？

>>48
Ｊａｖａはパフォーマンスという点からみれば、最も悪いかと。

そういや、JavaでWebアプリ作る時、鯖に結構メモリ積まないと洒落にならないよね・・・
あれ、どうにかできないかなぁ。

せっかく、OSはLinuxとかなのに、Javaである程度のパフォーマンスを得る為に、
メモリを1G〜2Gも積むはめになる。

同様の機能のWebアプリを自宅でPHPで作ったら、メモリ256MBでも
Javaで作ったやつよりも快適だし。

自宅かよ…

>>51
自宅に開発環境も無いの？
釣りかなｗ

http://61-23-225-96.rev.home.ne.jp/


ぷぇぷｗぷぷはぷぷｗぷｗっうぇっうぇぷぷぷぷっうぇ
ぷｗぷぷｗぷぷｗぷｗぷｗぷぇぷｗぷみぷぷｗぷｗ
ぷぇぷｗぷぷぷぷぷはぷぷｗぷぷぇぷｗぷおｋぷぷぷ

PHPの方が遅くね？つーか最低でもコンパイルする分は速くなるんじゃね？
正規表現とかはPHPの方が早かったけど

まあ、スレ違い

満足できればどちらでもいいのです

>>53 新手の山田？

速度なんてほとんどどうでもいい
速度気にする奴に限ってプロファイリングすらやってないし

>>56
プロファイリング？
何言ってんの？

>>54
普通にやれば、Javaの方が圧倒的に速いよ。
多分>>45のケースは彼自信の言うと通り作り方か実行環境が悪いだけだと思う。

それにしてもあれだな。PHP5はAmazonECSの為に生まれたようなもんだな。
SimpleXMLの高速XML処理にSQLiteの組み合わせ。
アソシエイトの収入がとうとうお小遣いのレベルを突破しましたよ

>>54
コンパイルするからJavaの方が速いというのは少し違うと思う。
PHPは単純なインタプリタ言語ではなくて、コンパイルされてから実行されるよ。
ただ毎回コンパイルされるのでそのままでは確かに遅い。
でも、通常はそのままで運用する事はなくて、
アクセラレータ等を使ってコンパイル結果をキャッシュして高速化を図るよね。

言語自体の速度はいろいろなツール等でカバーできたりするので、
そこは実はどうでもいい気がする（そこまで差がつかない）。
それよりサーバ構成や負荷分散方法などの実行環境次第でパフォーマンスが決まるんじゃないかな。

Javaだから速いなんて一概に言えないはず。

http://Y043129.ppp.dion.ne.jp/
おｋｗｗｗうはっｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗうぇｗｗｗ
おｋｗｗｗｗｗｗｗｗｗおｋｗｗｗｗ
ｗｗｗ
うはっｗｗｗ

http://p2933db.tokynt01.ap.so-net.ne.jp/

ｗｗｗｗｗｗｗｗｗｗｗｗうはっｗｗｗうはっｗｗｗ

ｗｗｗｗｗｗｗｗｗｗｗｗおｋｗｗｗっうぇうぇｗｗｗ
っうぇっうぇｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

>>59
実際計った？
http://www.thinkit.co.jp/free/compare/2/2/1.html
ここ見て俺もやってみたけど、複雑な計算が絡むほど差が激しくなる。
もちろんJavaだからなんでも速いとは言わないが、やりたいことが増えるほど
PHPは不利。

>>62
実際に全く同じシステムをPHPとJavaで構成して測った事はない。
客の予算とか要件次第で採用する言語は違ってくるから。
ただ、JavaとPHPで速度差が実用に耐えられないほど開くような
複雑な計算をさせるような案件をやっていないだけかもしれない。

自分が今やってる案件は、
イントラ内の業務システムや、
携帯/PCサイトの更新用の管理ツール、実際にユーザが閲覧する画面等。
こういうのは、
パラメータを受け取って、入力チェックをして、DBに対して登録・更新などを行うとか、
DBに登録されてるデータを必要な件数だけ取得して表示するとか複雑な計算は必要としないものが多い。

こういう処理でJavaとPHPでそこまで差が開くのかな。
測ったらいいじゃんと言われたらそれまでだけど、そこまでの余裕はないので勘弁して下さい。
適当な計算させたり、DBに接続繰り返すだけの単純なテストして
それで○○が速いですねっていうのはひどすぎると思うし。
できれば実用的なシステムに対して負荷テストを行ってどの程度のアクセス数に
耐えられるのか比較するほうがいいと思う。

＞もちろんJavaだからなんでも速いとは言わないが、やりたいことが増えるほど
＞PHPは不利。

という点は同意。
PHPがJavaより速いと主張する気はなくて、
PHPも要件次第ではJavaとさほど変わらない事もあるんじゃないかと。
そういう場合にはやっぱりサーバの負荷分散とかインフラ周りが重要だと思う。

なんかいろいろ言ったけど、書いてるうちに
どっちが速かろうが客が満足すればそれでOK
という気がしてきた。

Javaが圧倒的に速いとか行ってる>>58見たいな人は
正規表現すら知らないJava厨なんだろうな。

>>63
＞パラメータを受け取って、入力チェックをして、DBに対して登録・更新などを行うとか、
＞DBに登録されてるデータを必要な件数だけ取得して表示するとか複雑な計算は必要としないものが多い。
典型的なWEBアプリって感じだな。
こういうもんなら、実際差が出たとしても微々たるもんだろうし。
ただ、こういう処理に「オブジェクト指向プログラミング」と言えるほどのオブジェクト指向が必要かは微妙だな…
phpdocumentorとかでソースの管理はしやすいだろうけど。

>>64
おいおい勘弁してくれよｗ
正規表現すらしらないでどうやってJAVAやれっていうんだ（ぷ

ひょっとしたらJavaに正規表現がないと思ってるのかも…

>>65

＞典型的なWEBアプリって感じだな。
＞こういうもんなら、実際差が出たとしても微々たるもんだろうし。
PHPの仕事ってたいていこういう典型的なWEBアプリが多いんじゃないかな。
こういう場合には、言語よりもその他の要因でパフォーマンスが決まると思う。

＞ただ、こういう処理に「オブジェクト指向プログラミング」と言えるほどのオブジェクト指向が必要かは微妙だな…
確かに。
適材適所というか、PHPに関しては、何でもガチガチのOOPで組めばいいというものではないと思う。

あんたらが使えるか使えないか知ったこっちゃねーが
基本的にJava厨は正規表現使えない奴が多い。

全てCで組む
鯖を強化
これで解決
PHPをコンパイルするソフトってあるんだね。


40ﾏｿだけど

正規表現を上手く使いこなすのは
Perl厨≧Ruby/Python厨≧php厨＞＞＞Java5厨≧C/C++厨≧Java1.4厨＞VB厨

正規表現なんて基礎じゃないか
でも逆にPerlとかPHP使いはHTTPをよく知らなかったりするんだよな

PHPAの5版って出るのかな？

>>69
その場にあったパターンに合致するようなライブラリを昔は作ってたな。
C言語の時もそうだったけど。
そっちのほうがパフォーマンスが良かった。

パフォーマンスを犠牲にしてまで、標準のフルスペックの正規表現ルーチンを
使わざるを得ないスクリプト言語って可哀相だな。

>>72
その基礎が分かってない奴多いんだよJava厨には。

>>74
なんか時代に取り残されたC厨って感じだな。
今日日パフォーマンス重視のために正規表現使わず
独自ライブラリ作るアホはいねーよ。

いや実際正規表現は遅いらしいじゃん
使うまでもない時も多いとｵﾓﾌ

>>75
パフォーマンス重視するのなら、作り込むのは普通だな。

つーか、だからクリティカルなシステムでは、JAVAとかCとかで作るんだろ。

本当にクリティカルな部分はJavaなんか使いたくないなぁ

>>78
今流通しているATMの殆どがJAVAなわけだが、お前は使わないのか？

aspxマンセー

WEBアプリの遅い速いなんて、DBがネックになったり、WEBサーバをスペックアップするとか、いっそ増やすとかで解決できることがおおいんじゃない。
PHPでもJavaでもどっちでもいいと思うけど。

PHP5で書かれてるオーぷんソースなソフツってなんかある？

PHP5で書かれてるかどうかは知らんが「PHP5動作確認済」とうたってるのはいくつかある

俺のスクリプト
1日20アクセスの無名な配布サイト…

こりゃPHP5ｵﾜｯﾀﾅって言われても仕方ﾅｲﾅ・・・

PHP5.10ｷﾀ━━━━━━━━━━━━━━━(ﾟ∀ﾟ)━━━━━━━━━━━━━━━!!!!

またチェックしなきゃならんな…

>>86
ｷﾀｰ　が異様に長い

Snapshotsにあることはあるが

('A`)間違えました
VisualJ#始めました・・・

PHP4でポリモーフィズムってどうやるの？

型指定いらないんだから、同じメソッド持ってるクラス作って、
適宜インスタンス化して適当に呼び出せばいいんじゃないか。

同名のメソッド実装したらいいだけやん

「ポリモーフィズム」って言いたいだけと(ry

多分インターフェイスがないから
明示的にポリモーフィズム出来ないじゃんと言いたかったんだろうけど
インターフェイスはポリモーフィズムの本質ではないからねぇ

>>94
じゃあなんて言えばいい多態性か？
OOPの３大機能の一つだぞ？
お前はオブジェクト指向知らんのか？

ハ？

………

PHP5でクラス作って云々やるぐらいならJAVAやるな。ストラッツとサーブレット
技術者不足気味らしいからPHPは開発、楽だったけどJAVAに方向転換するべ。
糞安いPHPの案件やるぐらいならJAVAだ。

OOPを精一杯勘違いしてる香具師が多いようだが勉強する気がないんか

>>97
ハ？じゃねよーバーカ。
お前は多態性すら知らんのか？
ニワトリ並みの知能指数ですなｗ

>>100
テメーもOOPの三大機能も知らずにこの板に顔出せるな？
少しは勉強しろよタコ。

クマーな気持ちでマジレスすると

オブジェクト指向を理解しているのなら、
PHP4でポリモーフィズムをどうやるのかって
聞かないよねー。

三大機能三大機能ってw
べんきょうしたばっかりなのかい？
(*´Д`)ｷｬﾜｲｲﾈ

何年後かに思い出して恥ずかしくなれるような
まともな技術者になれたらいいﾈ　PUPUPU

俺、JAVAプログラマだが、三大機能ってなんだ？
言語なんて、中の考え方や実現方法が違うだけで、機能はどれも同じだと思うが。
それとも、従来の言語思想と異なる３つの点って意味かな？

JAVA厨は三大機能も知らないで仕事してるのかよｗｗｗ

>>103-104
で？三大機能の何が間違ってるのか言ってみろ。
ただ煽りたいだけだろ？馬鹿かお前ら？

・OOを理解していない奴を見下したくなる機能
・OOを実装していない言語が見えなくなる機能
・PHP4以下が無かったことになる機能

これぞ三大機能

>>107

君が本当にオブジェクト指向を理解しているなら、>>91という質問は有り得ないよ。
それに>>92-93で答えもらってるのにそれはスルーしてしまっているのはおかしくないか？

http://www.google.co.jp/search?hl=ja&c2coff=1&q=%22%E4%B8%89%E5%A4%A7%E6%A9%9F%E8%83%BD%22%E3%80%80OOP&lr=

"三大機能"　OOPに該当するページが見つかりませんでした。


m9(^Д^)ﾌﾟｷﾞｬｰ

>>おばかちゃん
ﾁﾐの思っているポリモーフィズムってどんなのだい？
コーディングレベルで説明してみ？

結局、言葉を知っているだけなんだろうな(ぷ
>>94でｲﾀｲとこつかれてファビョってるw

Smartyスレで突っ込まれて逆切れしている奴と同一っぽいな。

>>107
間違ってるかどうかではなく、三大要素を知ってるか知らないかなんてレベル低過(ry
どうも>>105みたいなのもいるらしいが・・・
ﾏｼﾞﾚｽするとPHPはJAVA同様に、メソッドのオーバーライドはデフォルトで動的束縛（って>>107にわかるだろうか？）。
だからポリモーフィズムを明示しなくても勝手にポリモーフィズムになる。
まさに>>93の通り同じ名前のメソッド実装すればいいだけ。

>>114
そんなネタに釣られクマー。

まあﾌｧﾋﾞｮたんは中学生か高校生くらいだろう
教科書的な知識のひけらかしが
何か懐かしいw

ひけらかしとすら言えるほどの(ry

>>111-113 >>116
朝っぱらから昼まで何やってんだお前ら？
お前らみたいな雑魚ニートが社会人様に意見すんな。
働いてもいない奴に説得力なんてまったくねーよ。
しかもポリモーフィズムすらも知らんくせにｗ
なんでお前らみたいな雑魚がこの板にいるのよ？
場違いだ場違いｗ
とっととお母さんに小遣いでもせびりにいけよ。な？

>>114
一番、知識を言いたいだけの人だな。

>>118
あららw
中学生が大人のふりしてもおじさんにはまるわかりだｿﾞ
大人見くびるなよ、坊や。

しこしこしてろよ

>>120-121
大人のくせに朝から晩まで２ちゃんねるか？屑ニートが。

大人は仕事の合間ににちゃんねるをすることもあるのだよ。
にちゃんねるには色々な人がいる。覚えておきなさい。

ただ、普通のセキュリティに気を遣ってる企業なら、掲示板に書き込めるような
ネットワークにPCはぶら下がってないけどね。
自宅でやってる奴とか、ADSL直結みたいな中小企業なら知らんけど。

なんか荒れてきたなー
>>91=>>101=>>106=>>107は釣りだったわけだがw
ちなみに>>114を知識のひけらかしに思えるほどレベル低いやつは発言すんな
>>107のアンポンタンぶりにある意味勘違いして安心した厨どもが押し寄せたが勘弁してくれ。
別に大人でも子供でもいいからここからはまともな書き込みｷﾎﾞﾝﾇ

ポリモーフィズムとか言わないけどね

>>124
> 掲示板に書き込めるようなネットワークにPCはぶら下がってないけどね。

2chは普通にHTTPで書き込みが行われるわけだが。Cookieにしたって
ネットワークからみればHTTPのヘッダの一部に過ぎないわけだし。
外部の80番ポートに繋げないネットワーク環境ってどんなんだよ。
そんな会社見たことないし、激しく不便そう。

セキュリティの関係で社内の一部が外部ネットワークと一切接続なしにするというのは
ﾜｶﾗﾝでも無いが、社全体を外部との接続が全く無いのが「普通のセキュリティ」とは思えんな。

アクセスログをみりゃ、市区町村や省庁からのアクセスもたまにあるし、
GKをはじめ有名企業からのアクセスも多々ある。

あ、スレ違いだな。

すぐボロが出るんだから無知な輩はフカすなってこった
企業内からネットに繋げるなんて当たり前の話じゃねえか

ポリモーフィズムで大漁なスレはここですか

>>125
立場が悪くなるとすぐあれは釣りだったと言い出す人いるよね。
なんかガッカリですよ。

わざわざそんな書き込みに反応する>>131にもガッカリですよ。

>>128
うちの会社（みかか系）は、２ｃｈは、読めるけど、書けないよ。

>>127
アクセス禁止サイトってのがあるだろ
プロキシなんかで弾いたりしてさ
客先は禁止サイトにアクセスしたら警告が出るぞ

引きこもり的には、すべてのサイトに遍くアクセスできるのが当たり前ってことでしょ。
大手企業は、都合の悪いサイトは、社員がアクセスできないようにしているのは当たり前だ。

>>128は２ちゃんのログが読める立場の人間なのか？

あー、すまんすまん。
「書き込めるようなネットワーク」ってことね。
勇み足でした。

いよいよくだらん議論になってきたな

>企業内からネットに繋げるなんて当たり前の話じゃねえか

日本語理解できてますか？
ネットにつなげられるかじゃなくて、２ちゃんに書き込みＯＫかどうかの話だろ？
なんか話を勝手に変えて、ネットアクセス自体ができないって事にして、
アホだって叩いてないか？

>>138
まー、PHP厨なんてこんなもんでしょ…
大手企業社員の振りをするのが精一杯と。

つまりPHP4使いはｸｽﾞ
PHP5使いはｴﾘｰﾄってことか

>>139
↓どう読んでもそういう風には読めない。

>>124
> ただ、普通のセキュリティに気を遣ってる企業なら、掲示板に書き込めるような 
> ネットワークにPCはぶら下がってないけどね。 

昔、出向先で2chに繋げなくしてるところがあったが、自作鯖とSSHコネクション張って
そこ踏み台にして自由に読み書きしてましたよ。

普通、ちょっと頭使えばそう言うことくらいはすぐにできるわけで、
「どのPCも掲示板に書き込めないネットワークに繋がってる」状態ってのは
もの凄くレアだと思うんだが。

>>136
かどうかは知らんが、ふしあなトラップを見ると大企業からの書き込みは
別に珍しくないね。go.jpからも時々アクセスあるし。


>>122-124
で、「普通の企業なら2chになんて書けない。（だからニート）」と言いたかったんだろうが、
逆に>>124の無知をさらけ出す結果になっちまったというわけ。

>>123
仕事の合間に２ちゃんねるを見てるようじゃ
ろくな仕事してないみたいだなｗ
ほとんどニートみたいなもんだろｗ

>>126
ポリモーフィズムという言葉すら知らんのか屑。

>>127
まともな企業ならプロ串かましてるだろうから
２ちゃんねるなんて見れないようにするなんて
普通にしてるだろ。そんなことも知らんの？
程度の低いWebプログラマですね。死ねば？

>>129
うわぁ・・・
マジでお前みたいな低レベルな奴がWebに携わってんの？
やめてくれマジで。とっとと田舎に帰りな小僧。

>>143
技術的に可能でも、どっちみち仕事中に２ちゃんねるに
書き込むような奴はまともじゃねーよ。
お前も屑ニートか。死ねよ雑魚ｗ

>>142
会社員として厄介な奴だな。
遵法意識に欠けるお荷物社員だろ。
お前のせいで、ISO剥奪とかされなきゃいけどな。

会社員じゃなくて、バイトとか派遣とかじゃないか？
正社員で、客先で穴開けなんてやってたら、社会人として終わってる
まぁ、バイトや派遣でも終わってるけど
なんでわざわざ閉じてあるのか考えた方がいい

すげーくだらん話になってるな
全然OOP関係ねーし
そのフォーカスのにぶらせ具合でお前らの程度が知れるよ
ガキと馬鹿は一緒に失せろや

>>144
> まともな企業ならプロ串かましてるだろうから 

今時そんな用途にProxy組むかよｗ いつの時代の話だ。
口開くたびにボロが出るな。ここまで来ると微笑ましい。

> ２ちゃんねるなんて見れないようにするなんて普通にしてるだろ

いやあ・・・そんな会社見たことないぞ。2chは情報源としてチェックしてる
会社の方が多いんでは？書けないようにしてるトコは何件か知ってるけど。

> 程度の低いWebプログラマですね。死ねば？ 
プログラマってのは納期に完成品を納品すりゃいいの。分かってないね。
だいたい俺はアドバイザで机借りてただけだから、ほとんどの時間がヒマ。
他の会社の仕事片付けてる時間の方が多かったくらいだよ。

>>145
出向だっつの。残念ながらバイトでも派遣でもどっかの社員でもないよ。
つーかSSHの先でHTTPクライアント使うのが穴開け？違法？ISO剥奪？すごい発想だな。
そもそも「居てくれれば助かる」っつーんで机借りて金もらってるだけで、ヒマな時間に何しようが自由。

>>144
この程度の知識のヤツが社会人ってのも凄いな。少なくともWebやOOPが本職がじゃないことは良く分かった
「ニートじゃない」ことが唯一の拠り所みたいだけど、本当に社会人なのかこいつ？
言っとくけどコンビニの店員とかは社会人とは言わないぞ

>居てくれれば助かる

会社にとって命取りか。。。
やっぱり何の保険もない奴は雇わないに限るな

社内規定でわざわざ閉じているのに、それを中の人が無視してどうするのかと思う

匿名掲示板でニートだ社会人だ大手企業だって
相手の姿を妄想しながら叩き合う行為は愚か以外のなにものでもない。
そういう妄想攻撃を恥ずかしげもなくやっちゃう時点で、
そいつ自身のｼｮﾎﾞさのみは明らかにできるけどね。

ポリモーフィズムなんか知らんがphp3で組んだシステム売り込みから初めてすでに年収四千万の俺が来ましたよ。
設計は設計屋の仕事。実装なんかアルバイトにやらせりゃええねん

>>152
そこまでなるのに、どれくらいの年月がかかった？

まぁ、>>144が、ここまで自信に満ちて相手を批判できるってことは
当然、客先の了解を取って、トンネル開けて2chに書き込んでたんだろう。

もし、無許可でやってたとしたら、皆が言うように恥ずかしい奴だが。

あゴメン
>>148ね

>>151
同意。
というわけでスレにそった話題で。

>>150
> やっぱり何の保険もない奴は雇わないに限るな

保険？何の話だ？保証の間違いか？

>>154
> 当然、客先の了解を取って、トンネル開けて2chに書き込んでたんだろう。

当たり前じゃないですか。というか「トンネル開けて」ってSSHの意味分かってないのかも
知れんが、仮想端末越しにブラウズしてるだけだぞ？

> 社内規定でわざわざ閉じているのに、それを中の人が無視してどうするのかと思う

会社のIPアドレスで余計なことして欲しくないから閉じてるんであって、
会社とは全く関係ないマシンから独立に書き込む分には何の問題も生じないでしょ。
その辺はちゃんと了解も取ってあるし。

PHP5.0.3でオブジェクト指向な感じでWikiを作ったのだけれど、
ソース晒したら意見もらえるかな。

最近OOPの勉強を始めたので、出来る人から見ればクソみたいなソースかもしれませんが…

>>148
PROXYなんか当たり前の話だろ何言ってんだお前？
２ちゃんねるで情報収集？馬鹿かお前？
程度の低さが知れるなｗお前みたいなのがWebプログラマを騙るなよ。
一緒にされたらかなわん。

>>149
＞WebやOOPが本職がじゃない
ハァ？OOPって職なんですか？
なんだこのレベルの低さはｗ
もう書き込むなよ恥ずかしいだけだから。

>>159
下らん罵り合いは他所でやってくれ。鬱陶しいよ。

PHP5はクソって話題になったら困るから、わざとそらしてるんだろ。
>>157なんてイタくて見てられないくらいだもんな。釣りでしょ。

埋め

埋め

>>159
> PROXYなんか当たり前の話だろ何言ってんだお前？

Proxyが珍しいとは言ってないけど。
外部へのフィルタリングにProxyサーバなんて立てるか今時？って言ってるんだよ。

> ２ちゃんねるで情報収集？馬鹿かお前？

零細企業なら必要ないかも知れんけどな。ある程度大きいところになると
こういうトコに自社情報がリークしてたりは日常茶飯事なのよ。そういうのチェックする
部門だってあるぞ。あとググった結果が2chだったってことも別に珍しくないんだが。

あと、本職＝専門って意味な。辞書引いてみ。

いったいお前ら何にそんな興奮してるんだ？

たしかに。あまりにくだらんから読み飛ばしてるが。

>>114
> メソッドのオーバーライドはデフォルトで動的束縛

ここが意味不明。
「オーバーライド」は継承時の実装上書きのこと。
継承が不要だと言いたいときになぜ出てくる？

>>167
>継承が不要だと言いたいときになぜ出てくる？

誰もそんなこと言ってない
つっこみいれるなら会話の流れ嫁

ところでPHPって変数に型とかないけど、ポリモーフィズムっていうのか？

class Oya { public function func() { return "親クラス"; } }
class Ko extends Oya { public function func() { return "子クラス"; } }

$obj = new Oya;
echo $obj->func(); // ここでは$objは親クラス
$obj = new Ko;
echo $obj->func(); // ここでは$objは子クラス

これはポリモーフィズムではないよな。

バーカ。

そもそもポリモーフィズムは型に依存した概念じゃないし。

Javaしかやったことないから分からないんだろうな。
>>169 は数学も形で覚えるタイプ。

>>171
ポリモーフィズムを敷衍しすぎ。
OOPでのポリモーフィズムの話だろ。

126 ：nobodyさん ：2005/06/08(水) 07:48:50 ID:???
ポリモーフィズムとか言わないけどね

この馬鹿について語らないか？

意味が分からないから語れない
（現場ではあまり）ポリモーフィズムとか言わないけどね
という意味か？

ここは言語論争をする場所でもなければ、オブジェクト指向の腕自慢をする場所でもない。
スレッドのタイトルが『PHPでオブジェクト指向プログラミング』となっているのだから、
相手を貶めたい人やらプロだのアマだのにこだわりたい人は邪魔ですよ。

この流れではスレッドの趣これい旨に沿った話題の展開さえままならない。
これ以上続けられても迷惑なばっかりなのでそろそろ止めてくれ。
小学生でも無いだろうし、お互い大人になろうよ。

>>172
ポリモーフィズム∈OOP
じゃないのか？
それにSmalltalkもObjCも型付け出来ないぞ。

静的型付けは確かに有用だが、
OOPに必ずしも必要という訳ではない。

それぞれの利点を考慮して
言語の性質に見合った設計をしていく事が大切だと俺は思う。

でも、説明するときでもポリモーフィズムってあんまり言わなくない？
多態って言うなぁ
漢字にした方が、初心者の人でも、何のことかイメージしやすいし
相手が理解できない専門用語を言って満足してるアホみたいだから、横文字は好きじゃない

と言うわけで、>>173 私怨みっともないぞ

>>178
ハイ本人登場ｗ

>>177（=>>126か？）
ポリモーフィズムじゃヤダとか駄々をこねるので仕方なく多態でいってやろう。
だいたいお前の職場だろうがこのスレだろうが意味が通じることが重要ってのがお前の主張じゃないのか？
少なくともこのスレではポリモーフィズムを多態と言わなかったがための誤解なんてなかった気がするが。

>>176
俺はPHPには型がないからOOじゃないなんて言ってない。
PHPでOOP的な多態がどういう位置付けなのかを疑問に思っただけ。
Smalltalkを持ち出すってことは>>169も多態ってことになるんだろうが、そんなこと言ったらPHPにオブジェクト指向が導入される前からある言語仕様も全て多態って話になるだろ。
全ての変数は内部的に数値なのか文字列なのか配列なのかオブジェクトなのか、、、によって実行時に動的に振る舞いが決まるわけだからな。

なんかもう、どうやったらポリモーフィズムって言えるかの競争になってるな。
それを阻む奴は、とことん攻撃するみたいなｗ

なんか>>91の「PHP4でポリモーフィズムってどうやるの？」を思い出した。
散々暴れて散々叩かれて消滅したが、実は何かをわかってて釣っていたのだろうか。
いや、それはない（反語）。

で、PHPのポリモーフィズムって結局何なのさ？
オブジェクト指向を謳うなら一言説明がほしいとこだ。>PHP

ポリモフォーフィズムも知らないで、よくJAVAならとか言えるよな。
だからJAVA厨は嫌われるんだよ。
PHPでOOPやってる奴なら常識なのに。

>>183
ポリモフォーフィズムって何ですか?

知らねぇのかよｗｗｗ
お前も多態とか言って誤魔化しとけよｗｗｗ

>>180
ポリモーフィズムというのはOOが持つ特性であって、
開発者がポリモーフィズムであることを意図していない機能は
それに「見えるような」振る舞いをしたとして、
あなたがそれをポリモーフィズムだと言っても、
それはあくまで主観（というかあなたの勝手な認識）でしかない。

ポリモーフィズムって別に普通の関数でも実現できるよね。
引数や実行される環境によって振る舞いを変えればいいわけだし。
メンテナンス性などを考えればOOPな方がいいだろうけど。

PHP4での例とすれば、PEAR::DBなんかはポリモーフィズムじゃない。
DB::connectは渡されたDSNから判断して、DB_commonを継承した
各DBのサブクラスをインスタンス化して委譲することによって
多くのDBに対応している。

↓勘違いしてたらツッコミよろ↓

>>183-185
微妙にﾜﾛﾀ

>>186
俺の言いたいのはあくまで
>PHPでOOP的な多態がどういう位置付けなのかを疑問に思っただけ。
であって
>(〜中略〜)ってことは(〜中略〜)全て多態って話になるだろ。
はただの推論なんで、そこに茶々いれられても。
（そこつっこんだわけじゃなかったならｽﾏｿ）
まー言語の開発者がポリモーフィズムを意図したかどうかに焦点があるべきなのは同意。
ただ直接聞くわけにもいかないからここで話してるわけで。


>>187
同意。たしかにそういうのもポリモーフィズムと言えると思う。
PEARに限らずPHPを使う側が意図してポリモーフィズム的な振る舞いを実装することはできる。
あとはPHPの言語仕様自体にポリモーフィズムがどう盛り込まれてるかって話。
はっきり言ってｱﾌｫな俺にはなかなかわからない。

>>188
>あとはPHPの言語仕様自体にポリモーフィズムがどう盛り込まれてるかって話。

俺はJavaを知らない（つーかRubyもC++も知らん)のだけど、Javaにはどのように
盛り込まれているの? インターフェイスがそうなのか? それとも抽象クラスやメソッドを
定義できること?

>>169のを使うと
Oya obj = new Ko();
obj.func();
で子クラスのメソッドが呼ばれる。
C++の場合は親クラスのメソッドにvirtualっていうキーワードをつけないと親クラスのメソッドが呼ばれてしまう（objがOya型として宣言されているため）。
ルビーは知らない。

結局、ポリモーフィズムって何？

ポリモフォーフィズムだろﾊｹﾞ

ポリモフォーフィスムス

自作自演か…

188 名前：180[sage] 投稿日：2005/06/12(日) 04:43:28 ID:???
>>183-185
微妙にﾜﾛﾀ

で？

誰かPHPのポリモーフィズムの解釈を語れよー！
誰もわかんないのかよー！
俺もわかんないよー！
ﾔｹｸﾝのｱｹﾞ

>>196
みんな偉そうなこと言ってポリモーフィズムの定義を知らないんだろ。
ホント口だけだよな。

ttp://homepage1.nifty.com/CavalierLab/lab/vb/clsmdl/polymorphism.html

>>197
よし、ﾁﾐのポリモーフィズムの定義とやらを聞こうじゃないか。

>>198
VBかよ

>>197
OOPに標準とかあるのか知らないのが、とりあえず
ttp://www.computerlanguage.com/webexamples.htm
での検索結果によると、
>the ability of a generalized request (message) to produce different results based on the object that it is sent to

ま、OOP的に言えば、同じ名前のメソッドでもインスタンスの動的な状態（実行時の状態）に応じて適切にメソッドが呼ばれるってことだと解釈しておけばいいんじゃないの？
とりあえず俺も>>197の意見が聞きたい

>>197
ﾜｸﾜｸ

依然PHPでのポリモーフィズムは謎なわけだが。

function f(&$obj) {
  $obj->method();
}

f を呼び出したとき $obj がどのクラスなのかに応じて適切な method() が呼び出されるわけだが。

漏れもそれを言おうとしてたわけだが。

だから何なんなんだと小一時間(ry
わけだが。

この前、SRAの石井が書いたPHP+ポスグレの本読んだ。そこにMVC構造した雑誌記事管理システムのプログラムコードが載ってた。
そのコード読んで思ったんだけど、ビュークラスやDBクラスを分けてオブジェクト指向っぽく取り扱ったところで、糞分かりづらいだけでまったく意味ねえな、と。

石井！ｶﾞﾝｶﾞﾚ！

OOP的な意味でのポリモーフィズムってのは基本的に、
いろんな型のデータを区別せずに扱えますよ、
ということだと認識してる。
同じ扱いなのに、実際のふるまいがポリモってるよ！という感じ？

だもんで、型がない場合は、その時点でてけとうに
ポリモーフィズムが実現されすぎちゃって困ってる、
という状況なんだと思われ。

型で制約されている場合でも、仮想関数表なんかを管理しとけば
どっこいポリモれちゃうんですよ奥さん、と。

（もともとは関数型言語方面で、このリスト型だとどんな型の値でも
ぶらさがりますよ、とか、関数を引数の型の微妙な違いで
オーバーロードできますよ、とかいうのがポリモーフィズム
だったらしいけど、OOP方面ではふつうそういうのまで
ポリモーフィズムとは言わない、よね？）

こんなにポリモーフィズムなんて言葉が使われつづけるスレも珍しい。

>>209
同意。
実装をする側がクラスごとに適切に書いておけば、それを使う側はオブジェクトごとにいちいち区別しなくても同じように使えて正しく動く。
それがOOP的ポリモーフィズムの利点だわな。
ま、
>ポリモーフィズムが実現されすぎちゃって困ってる
のかどうかは微妙な線だが、PHPなどの型なし言語はもともとポリモーフィズム的振る舞いをしていたから、殊にPHPでOOを導入する時に「この部分がポリモーフィズムだよ」という必要がなかったってこっちゃな。
>もともとは関数型言語方面で、（・・・）、とかいうのがポリモーフィズム
ってのは初めて知った。

>>210
まー、多態性って言う方が多いだろうからね…

ｿｰｽｷﾎﾞﾝﾇ

そんな小難しいモンでもないやん
違ったモノに同じ命令で言うこと聞かせられるようにすることだよ。

動的束縛が強いとそれがあたりまえになって、特に意識しなくなるからなあ

動的束縛に強いとか弱いとかあるのか？
あと>>214だと静的束縛と区別できん。

ぶっちゃけポリモーフィズムってよくわかんない。
でも>>214でなんか少しわかった気がする。
動的束縛がなんちゃらとか、なんかすでにポリモーフィズムをわかっている人にしかわからない言葉を説明に使わないでほしい。
難しそうなことをいろいろ知ってるのはわかったから、それをわかりやすく説明できるようになってほしい。
でないとあんたらの頭の良さは全然伝わらないってことに気づいてほしい。

オブジェクト指向の入門本とか見ると
ある親クラスを継承した子クラスがすべて同じ名前のメソッドを持っていて
オブジェクトが変わると同じメソッドでも振舞いが変わるというように
理解したんだけど違う？

× 振る舞いが変わる
○ 振る舞いを変えることができる(メソッドのオーバーライド(override : 覆す、無効にする))

>>217
もともとここは初心者に説明するためのスレじゃないし
話の流れ的にも >>197 の講釈を待ってる間に野次馬ががやがや言ってるだけかと

素直に「動的束縛ってなんのことだかわからないので教えてください」と頭を下げれば
親切な人が教えてくれるんじゃないか

動的束縛ってなんのことだかわからないので教えてください orz

>>220は本当は知らないので、親切じゃないので教えないとか厨じみたことを言って逃げると見た。

>>218
別に同じクラスを継承する必要ないし。

ﾎﾟﾘﾓｰﾌｨｽﾑｽとはちょっと違うけどさあ、
リスコフの置換原則は次のように謂う、
「派生クラスは、ユーザーが基底クラスとの違いに気付かずに、
基底クラスのインターフェイスを通じて使用できるものでなければならない。」
とゆうことは、
継承したクラスで独自にメソッド増やすのはよろしくないってこと？

「パブリックなメソッドを増やすのは」に訂正します

いや勘違いしてた。
基底クラスのメソッドは
継承クラスも基底クラスと同様に実装しておけってことで、
新しいメソッドを持つなって言ってるんじゃないね。そりゃそうか…

とりあえず、書き込む前に、自信を持ってくれ。

藁

結局、動的束縛を説明できない厨スレはここですか？

ほんの今の今まですげえ意地んなって明快で対称的な説明文をめざして書いてて
あーなんか静的束縛の説明が微妙にあやしーと思って一旦エディタに移動させたら
失敗して消えて頭もまっしろんなってる厨のいるスレはまさにここですYO

>>230がドジってる間に、とりあえず型のある言語で静的束縛・動的束縛の解説。

◆まずは下準備として、親クラス←子クラス←孫クラスという継承関係とする。
↓のように、親クラスでfuncというメソッドを宣言し、孫クラスでのみオーバーライドする。

class Oya { func() {return "親";} }
class Ko extends Oya { }
class Mago extends Ko { func() {return "孫";} }

◆ここで子クラスのオブジェクトobjを宣言してみる。
↓のように、ユーザ入力など実行するまで未定な要素をからめたコードを書く。

Ko obj; /* 子クラスのオブジェクトとして宣言。 */
switch ( ユーザ入力 ) {
case "子": obj = new Ko();
case "孫": obj = new Mago();
}

/* ここで問題。 */
obj.func();

◆さて、実行時にユーザが"孫"と入力した場合について考えてみる。
objにはnewによって孫クラスの実体（の参照）が代入されました。
obj.func()は"親"を返すのか？それとも"孫"を返すのか？
もう一度書いておくけど、objは親でも孫でもなく、子クラスとして宣言されたオブジェクト。

答え：
静的束縛なら"親"。
動的束縛なら"孫"。

なぜか？
◆静的束縛は、実行する以前に、
「objは子クラスなのだから、子クラスのfuncを呼び出せばいーだろ」
と決めつける。
子クラスは親クラスを継承している（つまり含んでいる）ので、親クラスのfuncが呼ばれる。

◆動的束縛は、実行時に、
「objが参照しているのは孫クラスの実体だから、孫クラスのfuncを探そう」
と柔軟に対処する。
孫クラスでfuncはオーバーライドされているので、その孫クラスのfuncが呼ばれる。
もちろん、もしオーバーライドされていなければ継承元クラスのfuncが呼ばれる。

つまり、静的＝実行前、動的＝実行時ってこと。
束縛という言葉が意味不明にきこえるかもしれないが、これは英語のbindingをｱﾌｫな人が和訳したため。
元々は「結びつける」というくらいの意味。
C++はデフォルトで静的束縛。JAVAはデフォルトで動的束縛。

まとめ。
静的束縛＝実行前にメソッド決定＝今時ｲﾗﾈ
動的束縛＝実行時にメソッド決定＝多態性の実現

ちなみに動的束縛・静的束縛の話題は、PHPのような型なし言語とはカンケーない。
よってスレ違い。
以上。

なんでメソッドのオーバーライドの問題が
型のあるなしと関係あるん？

>>234
誤爆ですか？

　　　　　　　　　 ,,iiii,,,,,iii,,　　　　　 ,,,,,,,,,_　　　　　　　　　
　 .＿＿＿＿＿_ﾞ!lllll!l!llll!!　　　　 ,llllllllllllllliiiiiii,,,,,,,、　　　
　 .llllllllllllllllllllllllllllllllllllllll｀　　　　　 ﾞﾞﾞﾞﾞ!!!!!!llllllllllllllll!　　　　
　 .l!!!!!!!!!!!!!!!!!!!!!!llllllllll　　　　　　 .,iiiiiii,,,,,,,,ﾞﾞﾞﾞﾞ!!!l゜　　　　
　　　　　　　　　　llllllllll　　　　　　 lllllllllllllllllllliiiii,,,　　　　　
　　　　　　　　　　llllllllll　　　　　　　 ｀ﾞﾞﾞﾞﾞ!!!!lllllllll゜　　　　
　 ＿＿＿＿＿__,llllllllll　　　　　.,illllliiiiiiii,,,,,,,, ﾞﾟﾞﾞ′　　　　
　 lllllllllllllllllllllllllllllllllllllllll　　　　　l!!!!llllllllllllllllllllliiiii,,,,,,、　　
　 '!!!!!!!!!!!!!!!!!!!!!!!lllllllll| 　 　 　 　 　 ﾞﾞﾞﾞﾞﾞ!!!!lllllllllllll!: 　　　
　　　　　　　　　　　　　　　　　　　　　　　　　ﾞﾟﾞﾞﾞ!!°　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　 .,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,、　　　　　　 ,,,,,,,,,,　　　　　　　　　　
　 .lllllllllllllllllllllllllllllllllllli、　　　　　 lllllllllll　　　　　　　　　　
　 .'ﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞlllllllllllﾞ′　　　　　 llllllllll　　　　　　　　　　
　 　 　 　 　 ,illllllllllﾞ｀　　　　　　 .llllllllll|　　　　　　,,,i,,　　
　　　　　　,,iillllllllllﾞ｀　　　　　　　 llllllllll|　　　　 ,,,iilllllllli,　
　　　　 ,,,iillllllllllllllllii,,,　　　　　　 .lllllllllll　　 .,,,iiilllllllllll!!ﾞ゜　
　　,,,,,iilllllllllllll!!!llllllllllllii,,、　　　　 llllllllll|.,,,,iiillllllllllll!!ﾞ’　　　
..liillllllllllllllll!!ﾞ’　 ﾞﾞ!llllllllllllii､　　　 .llllllllllllllllllllllll!!ﾞﾞ｀　　　　
: ﾞﾞlllllll!!!ﾞﾞ｀　　　　 ﾞﾞ!lll!!ﾞ゜　　　　.ﾞ!lllllllllll!!!ﾞﾞ゜　　　　　　　
　 .ﾞﾞ゛　　　　　　　　 : 　　　　　　 ｀ﾞﾞﾞﾞ″　　　　　　　　　

>>233
型あり/なしなんか関係内だろ。
PHPは動的束縛だよ。

型なし＝＝型に束縛されない

オブジェクト指向してみたいのですけど初手からつまづいてます。
・DBからデータを取得する場合、１要素づつオブジェクトにいれて、
それの集合体オブジェクトに追加していくものなのでしょうか。
・そうだとしたら検索する関数は、１要素づつのクラスのメンバでしょうか、
集合体のクラスのメンバなのでしょうか。
例えば請求書オブジェクトは、請求明細一覧オブジェクトをメンバとしています。
請求明細一覧は、請求明細のあつまりです。
請求書オブジェクトを生成する際の請求明細一覧を生成するロジック？が
わからないんです。どなたかよろしくお願いします。

　_, ._
(　ﾟдﾟ)　　・・・・・？

まず利点と欠点をよく見ないとダメだよ。かなりエスパー能力を要する質問だと思うYO。

その明細一覧というのがが、均質な項目をイパーイあつめた単なる表のような
データであって、かつ、一種類のメソッド群でさばききれる(多態性がいらない)んであれば、
たぶんそうこまかくする理由ってみつかりにくいんじゃないか。という気はするYO。
たいして効率に影響しなくて使いやすくてメンテ等もしやすければいいんだろうけどね。

>>239
めちゃめちゃ混乱してますな。

「請求書オブジェクト」という概念は捨てた方がいいんではないかと。
全て1つのオブジェクトに突っ込んでしまうのではなく、オブジェクトを役割ごとに分けるのも必要。

検索部分は検索結果とは別個のオブジェクトにすることが多いし、
検索結果は1レコードを保持できるオブジェクトとして設計することが多いと思う。
検索オブジェクトから検索結果オブジェクトのインスタンスがたくさん返ってくるイメージ。

それらをまとめて管理したいなら、複数の検索結果オブジェクトを1つにまとめる専用の
オブジェクトを更に別個に設計したりするわけだが、検索結果が多い場合や1レコードあたりのメモリ
占有量が大きい場合は、そういう概念で設計すると検索結果を全部メモリに読んでしまい
メモリを圧迫する結果になる。
1レコードずつDBから読んでは捨て読んでは捨てした方が効率がいい場合もあるわけ。

>>240-242
独学の悲しさか何がわからないのかわからない程混乱してます。
もっとシンプルな例えとして「部署一覧」や、「部署コードから部署名」を検索する場合、
・部署一覧クラス（部署単体クラスの集まりをデータにもつ）
・部署クラス（部署単体のクラス）
・DBクラス（DBへアクセスしてSQLを実行する）
が必要かなと思うのですが（間違ってますでしょうか？）
■DBクラスのSQLを実行するfunction query($sql)は
何を返すべきなんでしょう。
1.部署オブジェクトの配列（さらに部署一覧オブジェクトに読み込む）
2.部署一覧オブジェクト
3.部署名の配列。それを改めて部署オブジェクトに読み込む（さらに
　部署一覧オブジェクトに読み込む）
4.部署名の配列。それを部署一覧オブジェクトに読み込む。
■部署一覧を取得するfunction bushoList()と、部署名を検索するfindBusho($key)は
1.両方とも部署一覧クラスのメンバにする
　もし該当部署がひとつしかなくても配列がひとつしかないとして処理する
2.findBusho($key)がひとつしかないことがわかっていれば
　bushoList()は部署一覧クラス・findBusho($key)は部署クラスのメンバにする
3.両方とも部署クラスのメンバにして、複数の部署名の場合に
　部署一覧オブジェクトを生成してそれに入れ込む。
なにを悩んでいるかわかっていただけますでしょうか。
エスパー能力をあてにしてすみません、お願いします。
多分、
>>241
細かくする理由が無い場合、どういうクラスにしたらいいのかわからないです。
>>242
読んでは捨て読んでは捨てというのは具体的にどうしたらいいのか
わからないです。

単純に請求書一覧を得るとか部署一覧を得るとかなら配列を使うなりして
できるのですが、オブジェクト指向だとどうするのかがさっぱりです。

>>243
> ■DBクラスのSQLを実行するfunction query($sql)は何を返すべきなんでしょう。 

1〜4のどれでもいいのではないかと。データの内容や量、処理の内容によって
どれを選ぶかもプログラマの腕にかかってるわけで。

あと、DBオブジェクトとデータにアクセスするオブジェクトは別々に設計した方がいいのではないかと。

> ■部署一覧を取得するfunction bushoList()と、部署名を検索するfindBusho($key)は 

自分だったらDBクラスを持った部署データを専門に扱う「人事課」みたいなオブジェクトを作るかな。

$jinji = new jinji();
$bushoList = $jinji->bushoList();
$bushoList2 = $jinji->findBusho('shomu');

bushoListやfindBushoが何を返すかは最初の疑問の答えを参照。

> 読んでは捨て読んでは捨てというのは具体的にどうしたらいいのか

例えば、検索結果を全部一度に配列にぶちこむのではなく、ループの中で
1つの変数に1レコードずつ結果を代入して処理する。ループが回るごとに
その変数は上書きされるから配列にぶちこむのに比べてメモリを食わない。

そんな面倒なことPHPでやっても意味ないよ。
クラスに関数をまとめるだけで十分だよ。
オブジェクト指向の勉強するなら、JavaとかRubyとかにした方がいい。

>>245
大規模開発になると避けて通れなくなるよ。PHPのなんちゃってオブジェクト指向でも
利用する価値はある。

最近、「クラスに関数まとめるだけ」で適当に作ったサイトがつぎはぎで巨大化するにつれ
保守が間に合わなくなって破綻したのでなんとかしてくれっつー依頼が多い。
まあ逆にフレームワークとかテンプレートエンジンとか詰め込みすぎて負荷でパンクした
サイトも知ってるけど。

> オブジェクト指向の勉強するなら、JavaとかRubyとかにした方がいい。 

これは同意。

どうしても集合的データの扱い方についてOOPしたいぜしたいぜというなら、IteratorパターンとかVisitorパターンなぞを調べてみるも吉

追加開発で収拾つかなくなってきたら、その時点で全面的に書き直せばいい。
PHPのよさは手軽にかけることなんだから。

それはもしや伝説の秘技「道路の掘り返し」では・・・！

>>244
つ、ついていけない…。「これ以上どうやさしく説明すればいいんだよ」
と怒られそうですが。（丁寧に説明いただいてるは語感からわかります。
感謝です。）
■DBオブジェクトとデータにアクセスするオブジェクトって
どう違うものなのでしょうか？（あ、何か日本語も変だ）
■人事課オブジェクトを作るというのは…
今回の程度の場合、細分化して部署クラスとかを作るんじゃなくて、
（例えばそれはデータメンバの変数にしたりして）操作するクラスを
つくるという解釈でいいでしょうか。

クラスにするものの勘所が全然つかめない…。

PHP5は知らないけど、PHP4やPerlはオブジェクト指向で開発するには機能が足りなさ杉。
PHPでも工夫すればオブジェクト指向開発できるって言っても、そんな不毛な工夫するより、その言語に適した開発アプローチを取るべきだと思う。

age続けるのがよいかわからないのでなんとなくですがsageてみます。
>>247
「したいぜ」というか「してみたいぜ」です。みなさんは、「できるけど
やらない。」なのでしょうけど、私は「できない」のでやり方は知って
おきたいのです。
何をクラスにするのかは、案件によって違ってくるんでしょうけど、
なんというか、こう常套手段のようなものを例示してもらえないかなと
思ってるんですよ。例えばDBがあって、そこからデータを引っ張ってきて
そのデータを扱うという操作についてとか…。デザインパターンと実際の
（この例みたいなの）が結びつかないんです。
面と向かって尋ねられる人がいればもう少し理解がはやいのかなとも
思うのですがいないもので。

O/Rマッパとか使ってみれば？

>>252
とりあえず、DBへアクセスして結果を取得するクラスに関しては自作するより
PEAR::DBを使うことをおすすめする。

>>252
>こう常套手段のようなものを例示してもらえないかなと

常套手段のサンプルコードとかは、巷ではPHPよりJAVAの方がずっと多いんじゃないかな。
だからちょっとがんばってJAVAやってみるのも勘所をつかむにはいいかも。

あと私見だけど、自分でクラスつくるときには、
クライアント側（class Bushoを書く側ではなくnew Bushoってやったりメソッド呼び出す側）
の人にとってどうしたら便利か考えながらやるのがいいと思う。
今の段階ではクライアントにあたるのも自分自身だろうから、よりいっそう自分の欲望に正直にできるはず。

（続き）

>>243の前半の質問の答えは>>244の言うとおり、何がやりたいかに応じてどれでもいいと思う。
後半のに関してはfindBusho()を部署一覧クラスのメンバにして
$list = new BushoList();
$kikaku = $list->findBusho('企画');
って感じで使用したらいいんじゃないかと。

もしfindBushoが部署クラスのメンバだったら
$soumu = $kikaku->findBusho('総務'); // !?
って感じで、特定の部署から他の部署を検索（？）みたいで意味不明かなと思った。
bushoList()メソッドの使いどころは、おいどんにはよくわからんとです。

まあとにかく「クライアント側でどう使ったらいいか」をよく考えてみて。
応援してるからガンガレ！

> オブジェクト指向の勉強するなら、JavaとかRubyとかにした方がいい。
PHP5のオブジェクト指向はかなりJavaを意識して作られてると思うんだけど
それでもやっぱり物足りない感じですかね？

PHPにはまだオブジェクト指向を意識して作られたサンプルコードの解説などが少ない

このスレって質問系とかちょっと頭の悪い書き込みとかがあった時だけ回るの早いな。
どーれ試しに。。。

$obj = new MyClass();

と

$obj = & new MyClass();

の違いって何ですか？

つ [ マニュアル ]

>>259
PHP5でやったらStrict error
Strict Standards: Assigning the return value of new by reference is deprecated in C:\home\php\test.php on line 5

>>260
恥さらしたな。

は？マニュアルに書いてあるだろ

>>250
> ■DBオブジェクトとデータにアクセスするオブジェクトってどう違うものなのでしょうか？（あ、何か日本語も変だ） 

DBオブジェクトってのはデータベースに直接アクセスするモノでしょ？
どんな命令でもquery関数に渡せば実行しちゃうような。

それだとqueryに変なモノを渡された時に困るので、DBオブジェクトは直接
使わないようにして、queryを出す専用のオブジェクトを作るわけ。
部署管理なら、部署管理データを操作する専用のオブジェクトを設計する。

> 今回の程度の場合、細分化して部署クラスとかを作るんじゃなくて、

いや、部署オブジェクト（部署１つ分）のインスタンス（群）をリクエストに応じて生成するオブジェクトですね。
「こんな部署のリストください」と言ったら「はい、これとこれ」と言ってDBを勝手に検索して結果を渡して
くれるような存在。こういったオブジェクトには、部署データの更新なんかも任せれば良いかも知れない。
こうすれば、メインルーチンではDBへのSQL文をどうすればいいとか考えなくて済むし、
それもオブジェクト指向のメリット。SQL文絡みのエラーが出れば、それは「人事課オブジェクト」の
設計のせいだとすぐ分かる＝バグの原因の特定が容易。

>>251
> PHPでも工夫すればオブジェクト指向開発できるって言っても、そんな不毛な工夫するより、
> その言語に適した開発アプローチを取るべきだと思う。 

全然不毛ではないよ。ある程度以上の規模になると開発効率が全く違う。
本当に不毛ならなぜPEARがほとんどOOで書かれているのかと。

Perlのようにただパッケージを拡張しただけみたいな物でも充分使いではあるよ。
問題は機能の多彩さではなく、OOな考え方でプログラミングが可能かどうか。
機能はその補助（そしてあるときはOOな考え方を強制・補正する束縛）に過ぎない。

構造化プログラミングな思考で書かれたモノと正しいOOな思考で書かれたモノでは
開発効率も保守性も全然違う。

>>264
>問題は機能の多彩さではなく、OOな考え方でプログラミングが可能かどうか。
>機能はその補助（そしてあるときはOOな考え方を強制・補正する束縛）に過ぎない。

なかなか的を得てる表現だと思った。

>それだとqueryに変なモノを渡された時に困るので、DBオブジェクトは直接
>使わないようにして、queryを出す専用のオブジェクトを作るわけ。

メソッドの引数にSQL文をとらなければいいだけだと思うが。
作成するDBクラス自体に汎用性を持たせたいなら別だけど。
OOP練習中の>>250にはやや冗長かと。

>>263
ためしに該当部分のURLさらしてみたら？

>>263
リンクぐらい書かないとね
http://jp.php.net/manual/ja/language.oop.newref.php

>>267
PHP5の話かとおもった・・・＿|￣|○

>// create a reference inside the global array $globalref
>global $globalref;
>$globalref[] = &$this;

>// 内部への参照グローバル配列 $globalref を作成
>global $globalref;
>$globalref[] = &$this;

。。。なんかこれ、日本語がやばくないか？
「グローバルな配列 $globalref の中に参照(&$this)をひとつ作る(入れる)」ってことだよね？

あー誤訳だね

ちなみにPHP5では>>259は冗長なだけで、STRICT外せば完全に同じになるわけ？

>>259
最初のはインスタンスのコピーを返すが、2番目のは参照を返す。じゃなかったっけか。

$obj = new MyClass();
$obj2 = new MyClass();
$obj->setName("hello");
$obj2->setName("world");
$obj->printName();

実行結果: hello

$obj =& new MyClass();
$obj2 =& new MyClass();
$obj->setName("hello");
$obj2->setName("world");
$obj->printName();

実行結果: world

試してないけどこんな感じでは？

>>261
てきとー訳
> Strict Standards: Assigning the return value of new by reference is deprecated in C:\home\php\test.php on line 5 
> 厳密な標準: newの戻り値を参照で割り当てるのは推奨されません。場所 C:\home\php\test.php の 5 行目

>>270
これもやってないけど、PHP4と同じ振る舞いをするんではなかろうか。

そもそもWEBプログラミング自体にオブジェクト指向開発の必要性が薄い。
WEBプログラミングっていうのは、ユーザの入力を受け取って、それをDBに入れて、DBから出したものを加工して表示する。
このシーケンシャルな処理の繰り返しに過ぎない。
JavaのStrutsを例にとっても、あれをオブジェクト指向って印象は受けない。
入力データのチェックと画面遷移の仕組みを用意してあるだけだから。だけど、WEBプログラミングにはそれで十分なんだよね。
あれ以上の機能を持たすと、オーバースペックになって使いづらくなるから。

http://jp.php.net/manual/ja/language.oop5.basic.php

ほうほう

WEBアプリでのオブジェクト指向開発の参考例って、PHPはもとよりJavaでも見かけない。
それは必要ないから、WEBアプリでは適用しづらいからだと思う。
FLASHとかAjaxみたいなのは別だろうけど、HTTPリクエストドリブンなWEBアプリだと使いどころが見つからない。

漏れの記憶によれば、はじめごろの応用例ではセッションオブジェクトとかが出てたような気が。

お、なんか発見
http://zope.jp/dictionary/SESSION%20object

型がないとか、インターフェイスがないとか、それはオブジェクト指向の本質とは関係ないかもしれない。
けれど、オブジェクト指向開発が必要なケース、大規模開発のときに、これらの機能がないのは厳しい。
あるものとしてコードを書けって言っても、そんな優秀な人ばかりじゃないし、優秀な人でもミスはするし。
それはPerlでuse strictなしで1000行のプログラム書けっていうようなもの。
これを逆にたどって言えば、PHPでオブジェクト指向開発の意義が薄いってことになる。

お！来た来た！
レベルが下がってくるとこのスレは盛り上がるんだよなｗ

>>272 >>274
いつの時代までそんなこと言ってるつもりだ？ｗ

>>272
んで、PHPファイルごとにDBオープンするコード書いて使いまわしが効かなくなって
開発ごとにスクラッチから起こしたり、入力、確認、完了、エラーで4枚似たようなスクリプト
用意してデザイン変わったら4枚とも書き直しだったりするんだよね。
確認画面で値チェックして完了画面ではフリーパスなスクリプトもしょっちゅう見るし。
OOを使わずに「なるほど」と思える大規模なWebプログラムって見たことないな。

完全にオブジェクト指向にする必要性は感じないが、メインルーチンをControlに見立てて
ViewとModelを分離するだけでもかなりすっきりするし保守性も上がる。
こういう風に書いた成果物は使いまわしが効きやすいし。

「そういうのはオブジェクト指向とは呼ばない」と言うなら見解の違いだろう。
少なくともWebアプリケーションでもOOでロジックを分離するメリットはある。

俺も完全に再利用可能な汎用オブジェクトを設計するのは、一部の例外（DBアクセスなど）を
除いてWebアプリケーションでは向いてないと思うけどね。PHP用フレームワークやWeb系PEAR
ライブラリの巨大さ、煩雑さを見るまでもなく。

>>277
> それはPerlでuse strictなしで1000行のプログラム書けっていうようなもの。

え？？？うちは.plの新規ファイルを立ち上げると、

#!/usr/bin/perl
use strict;

が自動的に挿入されるようになってますが？それで何十万行も書いてきましたが？
なんか、strictが面倒と思ってる人ってグローバルスコープの変数や関数使いまくりの
ぐちゃぐちゃなコード書いてそうだな……。普通に書いてればstrictでもエラーなど滅多に出ないんだが。

> え？？？うちは.plの新規ファイルを立ち上げると、
> #!/usr/bin/perl
> use strict;
> が自動的に挿入されるようになってますが？それで何十万行も書いてきましたが？
> なんか、strictが面倒と思ってる人ってグローバルスコープの変数や関数使いまくりの
> ぐちゃぐちゃなコード書いてそうだな……。普通に書いてればstrictでもエラーなど滅多に出ないんだが。

そうだよ。だけど、use strictなしでも、変数の使い方に注意すれば、同じプログラムは書ける。
とはいっても、それはかなりプログラマーの集中力を要する。
同様に、型無し、インターフェイスなしの言語で大規模開発をするのは、難しいと思う。ってこと。

PHPのOOは単に中規模向けなんじゃないのか？大規模向けじゃなくて。

>>280
> そうだよ。だけど、use strictなしでも、変数の使い方に注意すれば、同じプログラムは書ける。 
> とはいっても、それはかなりプログラマーの集中力を要する。

いやいやいや、スコープ無視してグローバル使いまくりの方が最終的には疲れるでしょ。
保守性下がるし。ウチはuse strictでエラーが出るようなコードは他の人にも認めてないよ。
もちろん使い捨てのものとかは除く。PHPもファイル間でグローバル共有するのが好きな人が多くて困る。

> 同様に、型無し、インターフェイスなしの言語で大規模開発をするのは、難しいと思う。ってこと。

つまり、そもそも難しいのに構造化プログラミングで書いたらもっと大規模開発は難しくなる、ってことでしょー。

>>279
自己レス
> 俺も完全に再利用可能な汎用オブジェクトを設計するのは、

一度、入力→確認→完了のステップを管理するMVCモデルのクラスを設計したことが
あったんだが、それぞれ継承してメインルーチンから呼び出すと最低でも3*2+1=合計7ファイル、
フォームとかDBとか含めると1処理辺り10枚平気で超えるのでバカバカしいと思い止めた。
(まあフレームワークとか使ったモノをトレースするともっと凄い枚数出てくるけど)。

現在、メインルーチン＝Controlの役割＋Model＋View＋テンプレート＋フォーム＋DAOの
6枚のファイル構成が多いかな。

>>281
まあ本物の大規模開発ならPHPなぞ使わないわな。PHPで片付く案件の中での「大規模」

>>279
> >>272
> んで、PHPファイルごとにDBオープンするコード書いて使いまわしが効かなくなって
> 開発ごとにスクラッチから起こしたり、入力、確認、完了、エラーで4枚似たようなスクリプト
> 用意してデザイン変わったら4枚とも書き直しだったりするんだよね。
> 確認画面で値チェックして完了画面ではフリーパスなスクリプトもしょっちゅう見るし。

画面遷移や入力値チェックのフレームワークがあるのはいいと思うよ。
そういうフレームワークを自作するときにオブジェクト指向で作るのはいいと思う。
別にオブジェクト指向開発がまったくいらないって思ってるわけじゃないよ。

> 完全にオブジェクト指向にする必要性は感じないが、メインルーチンをControlに見立てて
> ViewとModelを分離するだけでもかなりすっきりするし保守性も上がる。
> こういう風に書いた成果物は使いまわしが効きやすいし。
> 「そういうのはオブジェクト指向とは呼ばない」と言うなら見解の違いだろう。
> 少なくともWebアプリケーションでもOOでロジックを分離するメリットはある。

Javaサーブレット+JSPとかだと、唯一のコントローラを作って、そこから別のビジネスロジックを呼び出すとか、JSPファイルを呼び出すとかするけど、
あれをそのままPHPに当てはめる必要はないと思う。
アンケートフォームで画面遷移するようなのだと、そういうのが便利かなと思うけど。
こういうのをファサードパターンとか解説してある本もあるけど、そうなの？って思うよ。
別にif文で条件分岐して、requireすればいいだけじゃん。って思う。
画面表示部分を分けたほうがいいのはその通りだけど、分離できないこともある。JSPのカスタムタグとか、あれが本当に便利な仕組みなのかな？って思う。
まあ、何百画面もあるような大規模なサイトなら便利なんだろうけど。

>>283
> 別にオブジェクト指向開発がまったくいらないって思ってるわけじゃないよ。 

んー、であれば大体同意。ガチガチにどれかのデザインパターンに押し込むような
真似はしなくてもいいと思う。

> 分離できないこともある。

だよね。smartyみたいに泥沼化するのは嫌なので、テンプレートからある程度View側に
文字列を取ってこれる仕組みを用意して、あとは実装依存にしてる。
大規模開発ならテンプレートエンジンを使うのもアリだけど、かえって面倒な場合が多い。

> JSPのカスタムタグとか、あれが本当に便利な仕組みなのかな？って思う。 

使ったことはないけど、あんま便利そうには見えない。

DAOの考え方ってStrutsが元？

>>279-280
おまいら、同じこと考えてるのに話が噛み合ってないように見えますよ？

>>277
意訳
「use strict なしでもキッチリしたコード書けるけど、
　間違えてもエラー返ってこないからミスしやすい。」

で、>>277はstrictが面倒と思ってるわけではなくて、むしろ逆かと。

>>286
確かにそんな気がしてきた。サンクス。

オマエラサァ
PHPでOO語るならPHP4じゃなくてPHP5を前提にしてくれる？
PHP4なんか過去のものなんだけど？

>>288
客先のサーバが全部PHP5で動くようになったら考えるよ。

PHP4でOOを行うほどPHP5に移ったとき有り難味があるとか。
それ以外PHP5になにかあったっけ?

Apache2のスレッド処理に対応したとか?

>>290
>PHP4でOOを行うほどPHP5に移ったとき有り難味があるとか。
>それ以外PHP5になにかあったっけ?

そのOOの話がこのスレの話題であるべきもののひとつだろ。
スレッド処理etcはスレ違い。

>>289
>客先のサーバが全部PHP5で動くようになったら考えるよ。

こちらでﾄﾞｿﾞ
ttp://pc8.2ch.net/test/read.cgi/php/1118038954/

>>271
>・・・
>実行結果:？world
>試してないけどこんな感じでは？

いいえ。

>これもやってないけど、PHP4と同じ振る舞いをするんではなかろうか。

いいえ。

>>292
いぇーい

PHPのマニュアルにPHPはOOPLではありませんって書いてあるのにはどういう意図があるの？
奴らは「PHPのOOは中途半端」とかいわれるのを恐れているの？
それともPHP6でOOPLになる予定なの？

>>296
PHP5は完璧にOOPLだと思うが。

気になったが、みんなの大規模とか中規模を区切る単位ってなんなの？
曖昧すぎでわからん。

>>290
SQLite標準装備、SimpleXMLで高速XML処理

>>295
俺もOOPLじゃない理由はない気がするけど。
なんでマニュアルにOOPLじゃないと書いてあんだろう？
http://www.php.net/manual/ja/language.oop.object-comparison-php5.php

どこに書いてあったか忘れてたから探すのに手こずった。
日本語版の方ではPHP4のOOPのサブカテゴリだけど英語版の方ではPHP5側に移動されてるからいつリンクが切れるかわからんな。
一応英語版はこっち。
http://www.php.net/manual/en/language.oop5.object-comparison.php

>>298
ホントだしっかり書いてあるな。
このスレの存在意義すら危うくなるな。

>>298
OOでない書き方ができてしまう言語はOOPLじゃないというポリシーなんじゃない？

>>300
当たってそうな気もする。
そうするとPHP厨はC++もOOPLと呼びたくないわけか。

早くPHP5がもっと広まってこのスレで活発な意見交換が
できるようになればいいのにな。

>>302
ならPHP5の話題ｷﾎﾞﾝﾇ

__get() と __set() が微妙に気に入っている漏れがいる・・・

OOする時、Listクラス作る？
配列で事足りるけど、OO的に操作できないので
何か気持ち悪い V.S. 面倒の気持ちが戦っているんだけども

OO的に操作できないってどゆこと？

普通の配列だと
$obj->method()
の形で要素をいじれないでしょ？

なんか配列のラッパクラスみたいなもの（？）をつくるってことかな？
まあ>>305で言っている通り配列で事足りるわけだし、漏れは作ろうと思ったことないな。
Listクラス作っても計算量を減らせるわけでもなさそうだし。
なんなら配列をメンバにもてばそれまでって気が・・・。
Javaみたいになんでもかんでも継承して使いたい的な考え？
漏れにはよく利点がわからないけど、なんかの役に立つってなら知りたいかも。
解説ｷﾎﾞﾝ。

グローバル変数が嫌いな人はクラス

関数は？

もうね、いつのまにかOOPでしか出来なくなった

・・・・・・そ、そうか
よくPHPでｶﾞﾝｶﾞﾙな・・・・・・

ちなみにListってどう実装してんの？

class Node { private $data, $next; }
で$nextに参照いれるとか？

class List { private $array; }
だったりしてｗ

>>301
いや、逆にOO厨がPHPなんて全然OOじゃない！とか
言い出しそうなので先手を打っといたって感じがする
（あるいは既に叩かれたので書き足したとか）。

C++をOOPLじゃないと攻撃するPHPユーザは見たことないが、
PHPやC++をOOPLじゃないと攻撃するOO厨は沢山いるんじゃん？

print "abc";

こういうのもOOじゃないって怒る人いるよね。

"abc"->print();

すべからくこうすべきだと。

そうすると>>294の答えは
> 奴らは「PHPのOOは中途半端」とかいわれるのを恐れているの？
の方でおｋ？

掲示板をオブジェクト指向で作ろうとしてるんですが
POSTのチェックはifの連続以外になんかないですか

なぜifの連続・・・？

>>316
名前がありませんとか長すぎますみたいなやつ
if(! $name) {...}
else($name > 100){...}
みたいな

それでいいじゃないの？
まあ俺だったら空欄系は空欄系で、文字列長さ系は文字列長さ系で、不正文字系は不正文字系でまとめるけど。

どうでもいいけどそのコードテキトー杉だなｗ

>>317
俺もそういうifの連続にはうんざりしてる。
そういうのを専門にあつかうPEARライブラリってないのかね？

strLengthCheck($str, 5, 100);

function strLengthCheck ($str, $min, $max) {
　　if(strlen($data) < $min and strlen($data) > $max) {
　　　　return "長さが変だよ";
　　} else {
　　　　return 0;
　　}
}

こういうことにしても結局同じになるんだよなー

>>317
>>319
つ http://www.planewave.org/translations/quickform/html_quickform.html

ちと重いし使いにくいけどな。
こういうの参考にして自分なりにパッケージ作ってもいいし。

>>314
アドホックな使い方が出来るのがPHPの良さだし、
雑種的なものとして成長してきたから、
「必ずOOPを推奨するものでは決してありません」と言いたいのでは？
敷居の広さをアピールしているように俺は受け取ったが。

俺は長さのチェックだけ見ればこんな感じにしてる

$length_limits = array(
  'name' => array(5, 10),
  'message' => array(0, 500),
  ...); // この部分DBやファイルに入れといて取得してもいいし。

foreach ($length_limits as $key => $limits)
{
  list($min, $max) = $limits;
  $len = strlen($_POST[$key];
  if ($len < $min or $len > $max)
    // 長さが変だよ
  else
    // 変じゃないよ
}

っていうかそんなに面倒だと思ったことないけどな。

面倒っていうかifがだらだら続くのが嫌な感じ

何でifがそんなに続くんだって

>>322
一理あるな。
PHPはOOPでもいけるけど、使わなくてもいけるってのは大きな利点。
俺的にPHP5のOOはけっこうｲｲと思ってる。
中にはPHPはプリミティブ型がオブジェクトでないとか言う奴いそうだけど、そこまで不便でもないし。
まー型なし言語って意味で仲間のJavaScriptみたいなプリミティブ型の実装もけっこう好きだけど。
ガッチガチのOOしたいならOOPLを選べばいい。

>>322
同意。

>>325
チェックの条件を正規化してないから。でしょ多分。
んでも俺はクラス化してるけど、パスワードチェックの部分なんかはかなりif文並んでるよ。

※うちで必ずやる客が入力したパスワード検証
・英文字＋αになっているか（英文字だけ、制御文字、バイナリ、日本語コードなどはNG）
・0123とかabcdとかasdfgとかqwertyとかが含まれていないか
・同じ文字が4つ以上連続していないか
・ユーザー名と同じでないか
・ユーザー名の逆順と同じでないか
・メールアドレスの左側と同じでないか
・メールアドレスの左側の逆順と（略
　　　　　　　：　めんどくさいのでやめ

て感じで推測されやすそうなのは全部弾き飛ばしてる。大きいシステムになると
ローマ字＋英語のdic使って単語の組は弾いたりするよ。

>>327
そこにあげた項目ほとんどが結局はpreg_matchの類だろ。
だったらパターンだけ配列にいれてforeachで回せばifなんか激減だろ。
あ、いや、>>327に言ってるわけじゃなくて。>>324がifじゃ嫌とかいう話だったから。
>>327はifが並んでても気にしてないみたいだから好きなだけ並べてください。

>>328
文字数のmax・minチェックは？
必須チェックもあるだろ？
日付の妥当性チェックなんてのもある。
あんたが言うほど単純なものじゃないんだよ。

WEBコンテナがないのも問題。リクエストの度にオブジェクトの作り直し。意味ナシ。

>>330
WEBコンテナってどんな概念なの？

>>329
パスワードのチェックを一生懸命頑張ってるのはわかったよ。
そこまでやると利用者にとってはﾑｶつくだけの機能だけどなｗ
ちなみに俺はifの話をしてるだけなので。

ifは３回で済むやんその部分・・・

と言ってみる。
ちなみにもう一回言うけど、あんたがifを並べて書く分には文句ない。
>>315から始まったifダラダラが嫌な方々に対しての話だから。
それとも>>329=>>327=>>324=>>320=>>319=>>317=>>315だった？
それだったら必死こくのもうなずけるｗ

なんかOOPしたら
Singletonやたら多くね？
RequestやらSessionやらControllerやら、
基幹部品ほとんどSingletonになるやん。

>>333
まあ WebProgramming ってのはそういうものな気がする

漏れが1クラスで2つ以上のインスタンスを作るのって composite 系ぐらい

>>332
>>321と>>327だけっす。>>329は俺じゃないよう。

>>335
あ、そいつは失敬・・・orz
なんか俺が書いた332の文章読み返してみたら、そうとうｲﾊﾟｲﾊﾟｲだな。
反省。

>>333
たしかに制御部分なんかはシングルトンばっかだけどコンテンツと直接関連するとこはけっこうインスタンスつくるな。
インスタンスつくればつくるほど（ＯＯじゃない場合に比べて）重くなっていくのがｳｻﾞｲけど。
ＰＨＰ５だとその辺いかがなもんだろ？

やっぱそうだよな〜
Singletonは実装がちょっとだけ面倒だな。
継承で実現できないから毎回同じルーチンをコピペしなきゃならないし。
>>336
4のなんちゃってOOよりは速くなってるはずだよ。
俺もインスタンスのリストも作ってるけど
DBから読んでいっぺんにオブジェクト全部作るより、
一つずつインスタンス作っては表示した方が、メモリ消費量は少ないよなぁとか思いだしたら
一層Singleton傾向が強くなっていくんだよな。

ググったら、シングルトンは安易に使うな、みたいなことが
結構書かれててビビる。
でも便利すぎるから使いまくりな俺。
大丈夫、ResultやらControllerやらConfig何個も作るなんて
ｱﾘｴﾅｲｱﾘｴﾅｲ……
ほとんどデータ格納系となんかの基底クラスだけだ、シングルトン使ってないの。
ヤバいか。ヤバいかも。

>>338
Singletonは便利な反面、保守性を低くしがちでもあるから諸刃の剣だよな。
継承できないのもｲﾀｲ。アクセス制限もｼﾝﾄﾞｲ。
でも便利・・・。
誰かもっとﾋﾞｭｰﾃｨﾎｰなデザパタ考案汁！
とりあえず使いすぎない程度にほどほどでいった方がいいと思うけど。

>>337
基本的には一つずつインスタンス作って表示でいきたいんだけどね〜。
ちょっと特殊なソートをやるときってどうしてもまとめて読み込むしかないんだよな。
ソートが必要だと一般にＤＢにやらせてもどうせ同じだけメモリ食ってるだろうし。
（詳しく知らんけどたぶん）
っていうかＰＨＰにソートをやらせると速度激減ｗ

Singletonが便利なのは少ない変更で非グローバルに戻せること。
その逆も楽。

あっすまん。PHPだと無理だ。

コネクションプーリングないからダメポ

できなくもない。＞コネクションプーリング

最近のブログみたく、
一つの画面に複数の要素が入ってきて、
要素構成が動的に変化する場合、
viewにどんなオブジェクトを渡すのがいいかな？
たとえば同じRankingオブジェクトでも
メインコンテンツになったりサブコンテンツになったりするので、
Model層でView的な意味あいを考えなくちゃいけないというかさー
ModelにいながらViewしてんじゃんみたいな気持ちになるんだよな
うまいことできねーかな

うーん、そういうのもModelの仕事ってとらえてもいいんで内科？
Viewは出力しかしないって方向性で。

>>340
何を一人でつぶやいてるんだか。

PHP5はなぜ速いのか教えてください。

>>346
作れるサービスがクソなのしかできないので、数人しかアクセスしないから。

>>347
クソじゃないもの作れるようにがんばろうね！

PHPでMVCやる人たち。
MもVもCもクラス作るんですか？
そして全部シングルトンですか？
教えてくれた人に投げキ○ス。

全部Singletonのわけはないが
基本クラスになるでしょ。

Viewにあたる部分はincludeのみってのは邪道ですか？

View=プレゼンテーションロジック＋テンプレート
だからincludeのみなのは
ちょっとおかしいかも
Modelで意味レベルの情報をViewに渡して
Viewは表示用に整形して、テンプレートに組み込む感じ。

どこかのスレでメインルーチンをControllerとみなすとか書いてあったな。

>>349
>>279です。
VとMはクラス作ってやってます。簡単なものであれば、Cはメインルーチンに突っ込んでます。
メインルーチンはこんな感じ。

$form =& $_POST;
$action = new Action();
$result = $action->execute(&$form);
// 省略するけどここで$resultによってエラー処理などを行う
$view = new View();
$view->execute($form);

フォームの「入力」「確認」「完了」「エラー」のように複数のアクションがあるものは、
MVCを1つずつ作ってメインルーチンからCを呼び出してます。
継承させるとコストが掛かるし呼び出すファイルの枚数考えたらバカバカしいので、
テンプレートのようなコードをMVCの３つ用意しておいてページをつくるたびにコピーして書き足してます。
ただしCを書き直す場面はほとんどないです。

全部シングルトンっちゃシングルトンだけど、本来のシングルトンのように
明示的にインスタンスの複製を禁止するような機構は組み込んでません。

>>353
俺のことかな。

けっこうみんな色々だな。
PHPだしラフに書くことが多いみたいね。
なんかちょっと前まで、このスレ読んでて「みんなシングルトンしっかり書いちゃってるのか？」とか疑問に思ったりした。
まあ結果的にインスタンスを一個ずつしか作ってないってことかな。
そんな漏れはincludeしまくり野郎。
ガンガンファイル数増えるね。
メソッドの中でのincludeはＯＯのありがたみを感じるな。

シングルトンがインスタンスを一つしか作れないことを
強制するものだということは分かるんだけど、
どんな利点があるのか良く分からないです。
詳しい解説キボンヌなんですが。

シングルトンは、一つしかないインスタンスに、
プログラムのどこからでもアクセスできる、ってのが
便利なんだと思う。
俺も>354みたいな感じで処理してるけど、
resultオブジェクトなんかは、そこら中でインスタンス作ってると
Viewで処理するときに混乱しやすいから、Controllerの最初の方で
インスタンス化しておいて、プログラムが走ってる間はそのインスタンスに
アクセスして処理すると。
最終的に全クラスのエラーや処理結果が格納されるから混乱しない。

> シングルトンがインスタンスを一つしか作れないことを
> 強制するものだということは分かるんだけど、

それが利点。
たとえばシングルトンにするクラスが他のクラスのインスタンス情報をプログラムの開始から終了まで一括管理してる場合、ヘタにnewされちゃうと管理してた情報が水の泡になってしまうことにもなる。
だからそれを防ぐためにシングルトンにする。

まあ通常はコンストラクタをpublicじゃなくすことで、外部での勝手なnewを禁止するのが常套手段。
だがしかし、PHP厨はただ単純にnewを一回しかやらないことをもって「シングルトン」と呼んでいるらしい。
何か違う気もする。

シングルトンなんて言っても、WEBで適用できる範囲は限られてるからね。
HTTPだと、リクエストごとにオブジェクト作り直しなんだから。

Singleton=newはprivateにしてClass::getInstanceでインスタンスを取得するモン
という認識だな
単に一回しかnewしないと自分の中で決めているだけだったら
後から見返した時、呼び出しだけ側だけ見ててもわかりにくいし。

PHPで真面目にデザパタ組んでる人たち。
結局Singletonだけですか？
Composite使いがどこかにいたような。
Listを作る人もいたような気がするのでIteratorも書くのかな？
教えてｴﾛい人！

>>361
Conpositeパターンは階層構造をサポートしたwiki作る時に使った記憶があるな。
Iteratorは特に意識しなくてもたまたまそういう実装になってしまう時がある。
DBによらない（DBならLIMITで対応できるから）リスト表示でページャをサポートする時など。

そもそも俺はデザインパターン原理主義ではなく、考えた末の実装がたまたまどれかの
デザインパターンに一致することの方が多い。基本的なデザインパターンは一通り
頭に入れてあるが、設計する時にパターンの一覧表とにらめっこしてどれに当てはめるか
考えたりするような真似はしない。

Mojavi3がデコレータを採用してたぞ
あんまり見てないけど
ActionChainがなくなったらしいので、その代わりになるようなものなのか

MojaviとPhrameは結局どっちがよろしげ？
両方使ったことあったらそれぞれの長所短所を挙げてちょうだいな。

フレームワーク関係のサイト色々回ってみたところ
時代の趨勢は
Mojavi>>>>>Phrameって感じ
Phrame触ってみたことないので中身は知らないけど

Mojavi相当便利らしいね。
漏れも使おうっと。
できたら>>363について詳細キボンヌ。

いやだ

>>366
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スクリプトよりもタチの悪いグチャドロのコードになったり
非常に便利に使えたりの差が大きいと思う。

まだ触ってるだけの段階だけど
たしかにViewだらけになりそうと思った
でもView名は必ず変えなくちゃいけないというわけでもないから
色んな状況を一つのViewクラスで受けてもいいじゃん。
わりと融通がききそうという印象はあるな

Mojavi実験中。

>>368
> 基本的に全ページ同一のindex.phpから呼ばれる設計になるので、Webの階層構造の利点を捨ててしまっている。

DocumentRoot下をちゃんと階層分けしてそれぞれのファイルにアクセスしてもらうように作るのは厳しいかな？

> mojaviのファイル階層が深くて作業しにくい。階層構造になってるのにファイル名長すぎ。
> 同じような内容のViewがずらずら並んでしまう。

禿同。

思ったけどcontrollerの中の〜Exists()をオーバーライドして〜Action.class.phpなどを強制的にやめてファイル名短くするってのはどうかな？
元々付属してきたファイルのケアしなきゃならんのは逆にしんどいだろうか？
まだ始めたばかりなので色々模索中。

1つめ、ページコントローラーとしても使用可能
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

StrutsみたいなのってJavaで使う分にはメリットあるけど、PHPで使うには大げさすぎる。

Viewクラスやたら増え問題だけど
全部VIEW_SUCCESSを返して(Requestに状況説明ほりこみつつ）
一つのViewクラスで処理するとかすればいいんでないの？
俺が勘違いしてる？

>>368
> 基本的に全ページ同一のindex.phpから呼ばれる設計になるので、Webの階層構造の利点を捨ててしまっている。
どんな利点があんの？
同一から呼ばれてるからこそのフィルタ処理とかのメリットがあるんだが、それ以上のメリットがあるの？

>>368
＞（Action数） * （Actionの戻り値数）個のViewを定義しなきゃならんので、
これ間違いね。
例えば、追加と編集のフォームやバリデーションなんかはViewのロジックはほとんど同じだから、
追加でAction&Viewを作ってやって、編集ではforward&VIEW_NONEでOK
編集用のViewは作らなくてすむ

>>374
同一のファイルから呼ばれなくても同じクラス再利用すればいいのでは？

>>376
＞同一のファイルから呼ばれなくても同じクラス再利用すればいいのでは？
いってることが違うんだけど、どう言えば理解できるかなぁ…

ｽﾏｿ、言葉足らずだった。

> 同一から呼ばれてるからこそのフィルタ処理とかのメリットがある

の部分だけにつっこんでみた。
>>368への反論としての意味は考慮してなかった。

ちなみに漏れは>>368じゃないです。

>>376
index.phひとつpで経由してるから、個別の処理をクラスとして定義できて、forwardやactionchainみたいな
処理が可能になってるわけだけど、バラバラにしちゃった場合どうすんの？
あ、あとmod_rewriteでいじくる場合もこっちのが楽っぽいよね

index.phひとつp
↑まちがえた

同じController使えば同じでしょ。
dispatchの引数色々変えられるし。
ファイルわけとけば継承した自作Controller呼べる選択の余地もあるし。
とか言って実際やってみたわけではないがｗ

>>382
だからそうじゃなくて、個別処理を再利用して連携させて使いたい場合どうすんの。

dispatchの引数は勘違いｗ

＞自作Controller呼べる選択の余地もあるし。
これはあんまりメリットにならんよね。
Controllerが違う時点でMVCから外れちゃってるし

てかactionChain理解してる？

ひとつのコントローラだけでリクエストを受けるのは、分かりづらい面があるね。Strutsにもそういう批判あるし。
Strutsの場合はサーブレットを基点に考えられてるから、そうせざるを得ないかもしれないけど。
ユーザやデザイナ、更新作業するオペレータって、ディレクトリ構造になれてるからね。戸惑うことが多いだろうね。
SEO的にも問題があるし。

フレームワークが有効な場面もあるけど、PHPとかPerlのようなスクリプト言語のもってるアドホックな開発のよさを消してるような感じは受ける。
MojaviとかSmartyはむしろもっと機能を減らした方がバランスがいいんじゃないかな。

>>383
たぶん話がくいちがってるな。
まず俺は「ファイル分け推奨派」側ではないので。べつにindex.phpで問題なし。
ただファイル分けしたいとかいう意見も面白いと思った。
同じサーバ上で複数の異なるサービス展開したいとか、URLレベルではModule/Actionの組み合わせ以外でアクセスされたいとか個々人で事情があるんだろうし。
まーMojaviの標準から外れた方法使う分手間はかかるだろうが、大したことないでしょ。
で、その上で俺の言いたかったのは、再利用するなら同じクラス（または継承クラス）使えばいいだけでしょ、という話。
フィルタだろうがアクションだろうが。
別にファイル階層化の方が利点があるかどうかには俺は言及してない。

>>387
まーね。
とは言っても小規模ならフレームワーク使わなくてもいいわけだし、MojaviやSmartyはPHPの可能性を広げてるって見方もあると思うけど。
「不必要な機能は使わなければいい」ってのは当たり前に思えることにもかかわらず、実際にはそれが明確になりにくいから「無駄に多機能」って印象も生まれるんではないかと。
高機能・多機能にすればするほど重くなるのは確かだが、MojaviやSmartyで「無駄に重くなってる」って感じはしないかも。

>>389
俺はアクセスカウンタでも自作フレームワーク使ってるけどね。
MojaviもStrutsもそれ自体の機脳をおぼえなくてはいけないので
冗長すぎると俺は思う。

覚えるべき量は少ないのに、覚えさえすれば楽できるのが冗長ですかね？
片っ端から全部覚えようとするから冗長に思えるのでは？

>>368です。色々ご意見ありがとうございました。

> Webの階層構造の利点

これについては、URIにおいて階層構造でドキュメントの位置を特定できるという
本来のWebの意義を捨てるのはどうなのかなあという事です。
階層ごとにアクセス制限をつけるといったこともやりにくいですよね。

>>371の方法はスマートですね。なければ作れよと。自分がプログラマなのを忘れてました。

>>373
それだと何のためにActionがリザルトコード返してるんだよ？って問題になりそうなので。
エラー処理をVIEW_SUCCESSに処理させるのって見通し的に問題ありません？

>>391
冗長すぎるというよりも、Webの世界ではmojaviが当てはまるほどの規模の開発があまりないって事ですかね。
いまだに「会員登録」「一覧表示」「ドキュメント管理」「買い物システム」みたいな案件が多いですから。

先般mojaviで頼まれた案件は、自作のフレームワークの方が工数1/4くらいで済みそうでした。
昔作った計1000ページ近くに及ぶ顧客・企業・オーナーを結ぶデータベースへのアクセスインターフェイス、
あのくらいの規模だとmojaviでやったら工数減ったかも。

Mojavi3でSmarty使うには実際どうしたらいいんですか？
まずパッケージの中身見たらSmartyViewが空っぽでした。
とりあえずPHPViewをほぼ真似てSmartyViewを自作。
しかし、Smartyのキャッシュ機能のせいで、ActionとかFilterとか編集したときにそれが反映されない。
仕方ないので編集中はSmartyのキャッシュを無効に切り替えて対応。
なんか今後も振り回されそうな悪寒もあり。
よりよい方法はありませんか？

「もうはーび」のイントネーションがわからない。
とりあえず「もはび」と語尾上がりで読んでしまう。
桶？

>>394
素直に「もじゃび」にしといたら？

素直じゃないじゃんw

「じゃ」ときたか・・・

しかし「ja」を「は」と読むのは今風じゃないな

Tejas

Ajaxも「あじゃっくす」「えーじゃっくす」なんだから「もじゃび」でいいんじゃない？ｗ

Aja Kongもアハコングでええやん

どうやらMo[hj]av[ei]らしい

略してﾓｼﾞｬと呼んでますがなにか？

俺はﾓｼﾞｬﾋﾞﾝて呼んでる

　　　　　　|ﾊ,_,ﾊ
　　　　　　|´∀｀';/^l
　　　　　　|u'''^u;' 　|
　　　　　　|∀ ｀　　ﾐ　　ﾀﾞﾚﾓｲﾅｲ･･･
　　　　　　|　 ⊂　　:,　　　　ﾓｼﾞｬﾓｼﾞｬ ｽﾙﾅﾗ ｲﾏﾉｳﾁ
　　　　　　|　　　 　ﾐ
　　　　　　|　　　　彡　
　　　　　　|　　 　,:'
　　　　　　|''~''''∪


　　　　　　　　　　　　　　　l^丶 　　　　　　　　　　　
　　　　　 　ﾓｼﾞｬﾓｼﾞｬ　 　 | 　'ﾞ''"'''ﾞ y-―, 　　　　
　　　　　　　　　　　　　　 ﾐ　´ ∀ ｀　　,:' 　　　　
　　　　　　　　　　　　　(丶　　　　(丶 ミ　　　　　
　　　　　　　　　 （（　 　 ﾐ　　　　　　　 ;':　　ﾊ,_,ﾊ
　　　　　　　　　　　　　　;:　　　　　　 　ﾐ 　';´∀｀';,　　
　　　　　　　　　　　　　　`:; 　　　　　　,:'　　ｃ　 ｃ.ﾐ　　
　　　　　　　　　　　　　　　U"ﾞ'''~"＾'丶)　　　u''ﾞ"J


　　　　　　　　　　　 /^l
　　　　 ,―-y'"'~"ﾞ´　 |　　　ﾓｼﾞｬﾓｼﾞｬ
　　　　 ヽ　　´ ∀ ｀　 ﾞ':
　　　　　ﾐ　　.,/)　　　､/)
　　　　　ﾞ,　　 "'　　　´''ﾐ　　　ﾊ,_,ﾊ
　　（（　 ミ　　　　　　　;:'　　,:' ´∀｀';
　　　　　 ';　　　　　　彡　　::　っ　,っ
　　　　　　(/~"ﾞ''´~"U 　　 ι''"ﾞ''u

ていうか、もじゃびだろ

ぐぐると「モゥハーヴィ」が正式ですと書いてあるとこが多いが、意外に「モジャビ」派が多そうだな。
もうねぇ、語源とかどーでもいいよ。
俺たち日本人はアルファベットを見るとローマ字読みしたくなる人種なんだよ。
モジャビ、モジャビ。
モジャビで決定。

>>405
わかったわかった。

>>407
日本人は律儀な方だと思うよ。アメリカ人なんてグルジア共和国
とかヨハネ・パウロ二世とか全部英語読みだもんな。
「mojavi pronounce」でググったらこんなん見つけた。
やっぱり奴らはモジャヴィで抵抗ないらしい。

http://forum.mojavi.org/index.php?showtopic=1077

つーかググった結果が33件って。mojaviでググっても
日本語のページばかりだし、日本でしか流行ってないのか。

>>408
そこの書き込み読ませてもらったけど、モハーベ砂漠（アメリカにある砂漠）に倣ってｈで発音する派もいるみたいじゃん。
ちなみにモハーベ砂漠のMojaveの発音は「モゥ・ハァ・ヴィ」って感じのようだ。
ハァのとこにストレスで。
http://www.answers.com/mohave
↑発音も聞けるｗ

あと、「33件かよーっ！？」って思って俺もググってみたら実際はもうちょい出たよ
http://www.google.com/search?hl=en&q=mojavi
Results 1 - 10 of about 45,200 for mojavi. (0.04 seconds)

とりあえず俺はモハービでいくとするかな。

>>409
> あと、「33件かよーっ！？」って思って俺もググってみたら実際はもうちょい出たよ

いや、33件しか出なかったのは 「mojavi pronounce」でググった結果について。
mojavi単体で45,200ってのもかなり少ないね。
日本語googleの結果が1万件くらいだから1/4弱が日本語のページってことになる。

mojavi使いは日本人ばっかか。
日本人の情報収集力の高さと見るか。
単に新しいもの好きですぐとびつきたくなるタチと見るか。

PHPで、クラス名からインスタンスの生成ってできますかね。
ちょっとしたフレームワークを作ろうと思って、
Factoryに引数を与えるとその名前でクラスを生成してくる、
みたいなのを考えてるんですが。

new $classname; でいけたかな？
できなくてもeval()使えば確実。

$aaa = new ClassA();

のように一度作ったオブジェクトを削除するにはどうしたらいいんですか？
unsetだとだめっぽいんですけど。

要するにあれだな。もともとカリフォルニアはメキシコ領だったからスペイン語風の綴りが残ってるっていう感じ？

>>414
unsetの何がダメなのさ？

>>415
いつの間にかアメリカの歴史の話になっている。
恐るべきスレだな・・・。
みんなもWebProgばっかやってちゃダメだぞ。

オブジェクト指向的に書くと、PHP4よりもPHP5でやった方が早いですか？
別に速度は変わらないんでしょうか。

自分で測れ

>>413
Thx, eval関数の中でnewすることで作ったよ！
PHP4は型制限が緩いから俺様フレームワーク作るのは結構簡単だーね。
他人に使ってもらって使いやすいってのは難しいけど。
インターフェイスとか無いし。
PHP5で追加されたんだっけ。

>>418
速度に関しては何とも言えんな。
PHP5のオブジェクト指向に関する利点は、カプセル化、抽象クラスとインターフェース、__autoloadあたりの「機能」面だと思う。
オブジェクトの参照をうまく扱うようになったみたいだからメモリの使用量は減ると思うけど、その恩恵が得られるのは大量のオブジェクトを生成した場合くらいだな。
まあ元々Webプログラミングではオブジェクトを無闇にガンガン生成しないってのが鉄則だから、メモリに関しても速度に関してと同様に大して利点と言えないかもね。

>>420
あのさぁ、マニュアルに思いっきり載ってるんだけど。
http://www.php.net/manual/ja/language.oop5.patterns.php

俺ならevalではなくnew $classnameだな。

>>422

お前馬鹿だろ

>>412
Mojavi3ではファクトリーの実装でINIファイルをパースして、適切なクラス名のオブジェクトを生成するPHPのコードを自動生成してるみたいだ。
INIを編集しない限りは生成されたPHPファイルをそのままrequireしてるね。

ま、Mojaviの場合はシングルトン実装するために結局はnewInstance($class)メソッドの中で
$object = new $class();
とやってるけど。

っていうかPHP5ｲｲな。
シングルトンをラクラク継承できる。

>>423
はい。>>423の勘違いぶりよりは幾分マシですが。

勘違いしてるのはお前だ池沼

>>425
ずいぶんストレスがたまってるみたいだな。
もしくは頭が悪いのか？

ホントに頭悪いのなお前

シングルトンて継承できなくね？
staticな$instanceは、継承したところで基底クラスにしか存在しないだろ？

インスタンスメソッドからスタティックメソッド呼んだりしなきゃいけるんでね？

シングルトンは己の実体をstaticな変数に置くだろ？
継承したクラスからgetInstanceすると、すべて同じインスタンスをgetしてしまうから、
継承は出来ないんじゃないの？
424は自分でやってみてから言ってるのか？

Javaだとでけるな。親クラスのコンストラクタをprotectedにしたり、シングルトンを保持するスタティック変数と、それを扱う部分はオーバーライドせにゃならんが

$GLOBALに放り込むってのをどっかで見たな

つーか、違う変数に入れればいんでね？

>>428 >>430
基本的に基底クラスとそこから派生したクラス全てに関して、プログラムのなかで一つしかインスタンスが存在しないものを考えてた。

class Singleton
{
  private static $instance = null;
  protected function __construct() {}
  public static final function newInstance( $className )
  {
    if ( self::$instance !== null )
      throw new Exception( '２つ目のインスタンス' );
    
    self::$instance = new $className();
    
    if ( ! ( self::$instance instanceof Singleton ) )
      throw new Exception( 'クラス名が変' );
    
    return self::$instance;
  }
  public static final function getInstance()
  {
    if ( ! isset( self::$instance ) )
      throw new Exception( 'まだ生成されてない' );
    
    return self::$instance;
  }
}

派生クラスで個別にインスタンスほしいなら、finalを消して>>431のようにやればできるけど、それじゃこの親クラス意味ないね・・・。
コンストラクタに引数渡したい場合ちとツライが、Mojaviでは引数を共通の方法（連想配列）で渡すことで対処してた。

うーんと、親クラスで子クラスのインスタンスを管理するんであれば、
protectedなスタティックメソッドつかえばなんとかなるかな？(てきとう)

一応カンタンな使用法。

class ChildSingleton extends Singleton
{
  public function saySomething()
  {
    echo 'something';
  }
}

$obj = Singleton::newInstance( 'ChildSingleton' );
$obj->saySomething();

// 以下は全てエラー
$obj2 = new Singleton();
$obj3 = new ChildSingleton();
$obj4 = Singleton::newInstance( 'Singleton' ); // ２つめのインスタンス
$obj5 = Singleton::newInstance( 'ChildSingleton' ); // 同様

その他のメソッドもスタティックではなく、通常のインスタンスメソッドでＯＫ。
ちなみに今の状態だと、Singletonクラスの派生クラスにpublicなコンストラクタを書くと、そいつはシングルトンでなくなる。
それを禁止したい場合は、基底クラスのコンストラクタをfinalにすればよい。

ひとつ見えたことがある。PHP 5では基底クラスのコンストラクタが呼ばれないことがあるよね？
そこが穴になりそうな予感。でもそんなことなかったらすまぬ。

↓ここの例だと、基底クラスのコンストラクタが必ず呼ばれることを利用して派生クラスを縛ってる。
http://www.hyuki.com/techinfo/singleton.html

>>437
その人の本、分かりやすくていいけど
変な宗教のプロパガンダやってるのはどうなのか…

>>422
5のSingletonは__cloneも防がなきゃならなかったのか。
これはしらんかった。

MからVへのエラーコンテナってどう実装してる？
ﾓｼﾞｬはRequestオブジェクトに一括してほりこんでるけど。
俺はRequestとResultも分けてるから、
Errorクラスも別に作った方がキレイかなとも思う。
しかしErrorはResultの一部とも考えられるし…とか思うと
無駄に迷う。

Java言語による主の祈り。。。。なんだこれは？

HolySpiritualOutputStreamﾜﾛｽ

>>440
mojaviのようにビューへ処理の結果が通知されるようになっている。エラーならエラーと。
んで、エラーの内容はResultにぶち込んでる。
大規模な開発になったら考えるけど、あまり変に凝らない方が結局
保守しやすいコードになったりする。

結城浩位知っとけよ。

>>436
あ、そうか。つーか「コンストラクタにfinal」の意味が飲み込めなかったが、それが裏技的にアリなわけか。
そうするとコンストラクタはテンプレメソッドにしておいて、派生クラスごとの初期化には
コンストラクタから一定の初期化メソッドを呼ぶようにすればよいとかそういう感じかな

>>443
確かにOOPの罠の一つは「凝りすぎる」ことだと思う
純文学的プログラミングに陥ると
いつまでたっても完成しないもんなぁ…

>>443
うん、それで充分だね。やばい方向に行ってた。
さんくすちんぽ。

>>444
彼が書いたWikiのソースコードを読んでみたことがあるんだが、
とてもじゃないけどOOを理解してる人のコードじゃなかったね。
昔のコードなのかもしんないけど、名前空間がとっ散らかってて
ロジックも一貫性がなくて悪いコードの見本みたいな感じだった。

>>446
コードを書くたびにどんどん仕事量が減っていくようなら正しいプログラミングが出来てる。
汎用ライブラリを作ったはいいけど、何だかんだで案件をこなすたびに書き直しを余儀なくされて
バージョンが分散してどれがどれやら分からなくなっちゃってる人、自分が書いたコードなのに、
時間が経つと内容が把握するのに時間が掛かっちゃう人は何かが間違ってる。

あと凝ることは大事だと思うけど、OOに囚われるあまり手段が目的化しちゃってる人は多いね。
「1)納期に間に合って2)正確に動いて3)保守が簡単」ならば手段は問わないわけで。
その手段としてOOが提供されているのであって、OOであることを目的にしちゃいかん。
「上の3つの要素を満たすコードを書いた結果、たまたまOOになってた」ってのが正解。

最近特にWebプログラミングにおけるOO化が進んでる気がする。
ちょっと前までPerlでガリガリ系のプログラマがPHPに以降し始めて
OOPを必死で習得しようとしてるのかな。（俺もそうだけど）
一世を風靡したKENTさんなんてビジネスロジックとプレゼンテーションの
分離すら理解できてないみたいだけど今は苦労してるんだろうな。
もう隠居したかなｗ

>>446の場合はただスキルが足りないだけだと思う。

>>450がOOPを使いこなすための目から鱗なコメントを準備中ですので、
みなさん、お楽しみに！

必死な>>446がきましたよ

はっはっはっ！
漏れは>>446じゃないがなｗ

誰かﾓｼﾞｬ3の使い方を解説しているサイト知りませんか？
本家のサイトにはチュートリアルみたいなのないし、ググってもﾓｼﾞｬ2が中心で・・・。
日本語か英語で解説してあるサイトが知りたいです。
よろしくお願いします。

>>363
Viewの中にあるdecorate()メソッドはどういうときに使うのですか？
ﾓｼﾞｬﾊﾟｯｹｰｼﾞ内のクラスでも使用している箇所はないようなのですが。

>>449
> ちょっと前までPerlでガリガリ系のプログラマがPHPに以降し始めて 
> OOPを必死で習得しようとしてるのかな。（俺もそうだけど）

PerlでもOO的な書き方はできるし、(Jcode.pmがOO的なので
大抵のPerl書きはOOの恩恵にあずかってるはず)、逆にPHPも
ロジックが混在した汚いコードは多いよ。一概に言えないんでは？

俺もMVCを自分なりに考えてやってた頃はVとMを
どう分けるのかがいまいち分からなかった。
MからCに制御を戻さずにそのままVに移してたから一つのクラスになってた。
Mojavi見てやっとイメージが掴めた。
あと体得してきたノウハウ↓
・オブジェクトを擬人化して考える
・インターフェイスから考える（インターフェイスが出来たら実装は出来たようなもん）

>>454
APIリファレンス見ながら地道にソース読んでいくしかないと思う

Mojaviのソースは確かに参考になるね。
俺はStrutsとか触ったことないからよくわかってないのかもしれないけど、なるほどと思えるところがたくさんあった。

しかしMojavi3でどうしても解せないのがActionやViewのexecuteが、Controllerの中ではなくFilterの中で呼ばれていることだな。
いやむしろExecutionFilterの存在自体が謎だ・・・。
Controllerの中でやってしまえばよかったのでは？
まーこれに関してはMojavi内部での処理なのでどーでもいいといえばどーでもいいのだが。

あとFilter書くとき、条件が通ったら$filterChain->execute()呼んで、ダメだったときは$controller->forward()ってのもちと解りづらい気がするが、ちまたのMVCでもそういうものなの？

もう一つついでに、Viewとか他のクラスの中からその時々のActionをContextから直に取得できないのがツライな。
$this->getContext()->getController()->getActionStack()->getLastEntry()->getAction();
ってちょっと待ってくれよ・・・。
取得しないほうが吉ってことなのかな？
それとも俺なんか見逃してる？

データベース使うとSELECTとかWHEREとかそういうのがダラダラしちゃうんですけど
こういうのうまいことする方法ってないですか

>>459
おーい！ｽﾚがちがいますよーっ！
SQLを隠蔽したクラスを作るor使いましょう。

おまいら！最近出たWeb+DBプレスはおすすめですよ
Ajaxの記事が気になって買いにいったら
PHPのフレームワークについてかなり詳しく書いてた
そこで俺は勘違いに気付いたのだが
Actionクラスはプレゼンテーション層だから
あまりロジックは書かない方がいいんだな。
Actionに書いた方がいいのかとロジッククラスをバラして
もりもり書いてたよw

>>458
コマンド実行は
フィルタと本質的な違いはないからでは？＞ExecutionFilter
俺はソース見た時、なるほどなぁ〜と思ったよ。

MojaviのContextクラスのアイデア（基幹オブジェクトの参照のコンテナ）
ってなかなか便利だな。各オブジェクトにこいつだけ渡せばいいもんな。

>>461
やべ、俺も誤解してた部分あるかも。
頭に入れとこ。ＴＨＸ。

>>462
フィルタってキタナイやつをストップさせて、キレイなやつを通してやるのが目的じゃないの？
コマンド実行ってのはどうとらえたらよいのだろうか・・・？
まーMojaviのソースって、手本になるような美しさがあるかは別として、発想力に富んだ内容だと思う。
うなづける部分が多いね。

>>463
同意。Contextってネーミングもウマイ。
俺的にはgetAction()欲しかった。
自分で追加するのは簡単だけど、Mojavi３完成時に辻褄合わなくなるのも嫌だしな。
俺は根性なしだ・・・。

>>461
ｶﾞｰﾝ
俺も勘違いしてた。
ロジックは別に書くべきなのか。

そうそう、MVCと三層構造って別パラダイムなんだよな。
ごっちゃにしてる奴も多いと思う。
今ロジックの中でRequest読んでデータ処理するように書いてたんだが、
Requestは多分プレゼンテーション層かな？
Action段階で取り出して、ロジックに渡した方がいいのかな。
今度はActionとロジックの区分けに悩みはじめたよw

どうも四層になってるらしい。
中間層がWeb層とビジネスロジック層に分かれてるとか。
てことはやっぱりRequestはActionだろうな…ﾊｧむづい。

Model = ビジネスロジック
View = プレゼンテーション
Control = コントローラー
ではないのか？

>>468
「Model = ビジネスロジック」ってのは間違ってまっせ。

>>469
じゃあModelとは何よ？

MVCのモデルの中に閉じ込められるビジネスロジックというのは、
業務のキモとしてのデータの取り扱い方という形だけになるんだと思う。
ビジネスロジック呼ぶものがそれ以外にもあったとしてもね。

>>471
Modelのその他の役割は？

そんな難しい話してないで感覚で作ろうぜ

MojaviってStrutsの劣化コピーだよ。

GUIのあるアプリケーションのMVCとWEBのMVCを一緒に考えるのはおかしい。

結城浩はオブジェクト指向プログラミングに関する書籍で実績がある人だから。
好き嫌いはあるだろうけど。

http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/app-arch/app-arch2.html
なんとなくまとまってるような気がするべ

SafafiでMojaviJapanのサイトを見ると化けまくりな件について

>>478
ソース見たら、11行目、metaのcopyrightのところが文字化けしてんな。
MSBが立ってる文字が3バイトあるのでUTF-8の「©」でも突っ込んだんではないかと。

http://pc8.2ch.net/test/read.cgi/php/1117945031/669
これ書いたの漏れなんだけど、なぜphpでMVCにこだわるの？
その答えは散乱しちゃうから、上のスレにレスくれれば良いとして
MVCについて出来る範囲で答えますよ。

漏れはphpは最近始めたばかりで、今まではJavaばっかり。

>>466
>今度はActionとロジックの区分けに悩みはじめたよw 
教科書のような説明だと、Actionにロジック書くのはNGだけど書いても
嫌がられない場合もあるよ。
それはロジックが大したこと無いとき。MVCで、なんで役割ごとにバラバラ
にするかって？それは、再利用性、保守性を上げるため。
再利用もしないし、コードの見通しが悪くなるほど量も無いし、
変更も頻繁に入らない。そんなコードは堂々とActionに書いちゃって良いと
思うよ。

>>461
＞Actionクラスはプレゼンテーション層だから
＞あまりロジックは書かない方がいいんだな。

別にそんなことはない。

50行くらいならActionの中に書いてもいいよ

mojaviの場合はaction自体も再利用しやすいじゃん。
だからそういうふうに書けばいいんじゃないの？

>>483
Actionクラスを再利用するケースなんてないと思うけどな。
再利用するくらいなら、そのActionにマッピングされたURLを使い回せばいいし。

諸君、Actionには何を書くんですか？

>>485
ビジネスロジック

前に誰かいってたけど
evalの動的クラス定義おもろいな
テンプレートだけ作れば、actionもviewも用意しなくてもいいようにでけた。

>>487
そうするとテンプレートのファイル名まで命名規則が必要だな

>>484
>>375

>>488
必要もなにも、普通規則つけてるだろ

>>487
> evalの動的クラス定義おもろいな
そこにevalを使いたがる香具師の心境がわからん罠

>>487
なんか恐ろしい穴になりそう

>>492
allowedActionListでも作れば無問題

>>487
キモ過ぎ。
あんたとは一緒に仕事したくないな。

>>494
もっと説得力のある批判なら受付可

>>487は本当に独り言の好きな香具師だな、
と漏れも独り言を言ってみる。

＞evalの動的クラス定義おもろいな
$class()でいいやん。

＞テンプレートだけ作れば、actionもviewも用意しなくてもいいようにでけた。
身の毛もよだつキモさだな。

↑new $class()とevalの根本的な違いが分かってない奴

evalｲﾗﾈ

evalには無限の可能性がある

その通り。可読性を下げる可能性までもある

mojavi3で新規登録とかでよくある
パスワードと確認用パスワード
を比べるみたいな設定ってどうやったらいいの？

夢広がりんぐevalメディア

>>502
Action::validate()の中でやるかValidator書くかのどちらかかと思ふ。

evalは実行パフォーマンスも悪いし、ちゃんと対策ほどこさないと任意のコード実行される恐れがあります。

というわけで、まだeval使いたいｱﾌｫな人いますか？

eval なんて確実に自分が書いた変数しか入らない場合でしか怖くて使えない。
注意していても万が一ってのがある品・・

お前の関数ほど恐ろしいものは無いのにな。

mojaviって何を基準にモジュールを変えるもんなんですか？
掲示板なら管理画面と本体みたいな感じでいいんですか？

確かにモジュール分割悩むよな
てかモジュールいらなくね？とすら思う

eval使えない奴はﾁｷﾝ野郎

使えない奴なんか見たことない
使えるけど使わない
使う必要すらない
使う奴のほうがﾁｷﾝ
>>511は何にevalを使ってらっしゃるの？

>>512
うるせえｶﾏ野郎

Mojavi3でActionやModelの中でControllerを取得する場合、
$controller = $this->getContext()->getController();
と
$controller = Controller::getInstance();
のどっちがいいと思いますか？
他のシングルトンなオブジェクト（UserとかRequestとか）もどうしようか迷います。

$controller = $this->getContext()->getController();
がお作法通り。
基本的にContextﾀﾝの管理物はContextﾀﾝにお伺いを立てるが筋。

>>512みたいな阿呆がでるのはゆとり教育のせいか？

eval使いは屑。
プログラマを騙るな雑魚。

>>517
そういきり立つなよ。

キレ易いのもゆとり教育世代の特徴だな。

>>515
なるほど、そういうことですか。
Controller::getInstance()はMojavi内部で使用されるものととらえておけばいいのかな？
なんかちゃんとしたドキュメントがまだないから、Mojavi内部用なのか我々ユーザー向けに提供されたインターフェイスなのか迷うことが多いな。
getActionとかgetViewとか新しいインスタンスを生成しちゃうし、おそらく内部用だよね。
でもgetModelもインスタンス生成だけど、こっちはおそらくユーザー用だし。
なかなか難しい・・・。

>>517は言葉は悪いが同意。
evalは保守性、可読性、共に下げる原因になる。
何でもできる「自由さがアダになった点」ではグローバル変数と同類。
ちなみにnew $classname;との比較としてevalを語るならいいが、evalの優位性も語らず不毛に単体で支持するのはスレ違い。

だまってろ池沼

>>520
荒らすな。ｳｻﾞｲ

黙れクソガキ

>>522
必死杉厨ｷﾓ(ry

最近言語障害者がこのスレにはびこってるな。
消えてくれるとありがたいのだが。

バーカバーカ
ﾌﾟｯﾌﾟﾌﾟﾌﾟｰ

>>523

ﾏｼﾞでｷﾓｲなｵﾏｴ

>>526　ｸﾙｼｿｳﾀﾞﾈ

Mojavi3を使い始めたんですが、UserやRequestを自作した場合、どのように設定したらよいのかわかる人いますか？

フレームワーク使ったOOPでいいのは
ログが取りやすいことだな〜
特にDBのクエリログは激しく便利

PHPのオブジェクト機能を教えて下さい。

>>530
なんだその質問はｗ

同意

PHPのオブジェクト指向ってなんですか？
PHPでオブジェクトってどう使ったらいいのですか？

>>533
マニュアルを読んで納得して使う。

なんかビギナーっぽいんで
オブジェクト指向自体の勉強から始めた方がいいと思う
本屋にGO

ぶっちゃけオブジェクト指向・デザインパターン・フレームワーク
を知らない奴はプログラマを騙らないで欲しい。

たしかにマニュアル読んでしか使ってないし、ビギナーでもあるし、プログラマを騙らないので
オブジェクト指向・デザインパターン・フレームワークを教えて下さい。後で本も買いますので。

そんなのこんなところで教えられるもんでもないだろ
どんだけコンパクトな知識やねんw
OOなんて知の最高峰みたいなﾓﾝで
ほとんど哲学の領域にまで踏み込んでるのに

わかりました、後で本買って読んでみます。

ところでPHPでオブジェクト指向っぽいサンプルコードをどのたかちょこっと
書込んでいただけないでしょうか。本と照らし合わせてなにが
オブジェクト指向たらんのか調べてみようと思うしだいです。

>>539
あちこちにあるだろ。
ググるなりすればすぐに見つかるからてめぇで探せ。

それができないようなヤツにプログラミングなど無理。

ごめん、sage忘れた。

>>536
20年前からアセンブラ一筋の人が漏れの師匠なのだが
その人はプログラマと呼んじゃいかんのか？

>>539
{>>539}->read(new book(OOP))->try(new things);

>>543
わざわざありがとうございます。
とりあえず>>540に指摘されましたので、Webを散策して勉強中です。

メソッドが自分自身の参照や新たなインスタンスを戻り値として返す場合
>>543みたいに「インスタンス変数->メソッド()->メソッド();」
みたいなメソッドコールを連結して記述できるのは、PHP5だけですか？
PHP4だと、Parse errorが出てしまいました。
しかたないので、メッソドの戻り値を代入したテンポラリインスタンスを用意して
メッソドコールしましたけど、なんか美しくないんですよね。
とりあえず、今は、>>543風に示すとこんな状態です。

{>>539}->read(new web(OOP,PHP))->try(new environment(PHP4));

ちなみに作ってみたコード
<?PHP
　class test{
　　var $value;
　　function test($argv){
　　　$this->value = $argv;
　　}
　　function set($argv){
　　　$this->value = $argv;
　　　return $this;
　　}
　　function show(){
　　　return $this->value;
　　}
　}

　$test = new test("Hello World<br>");
　print $test->show();
　//print $test->set("Hello OOP World")->show();
　$tmp = $test->set("Hello OOP World<br>");
　print $tmp->show();
?>

自分と同じクラスのインスタンスが文字列の代わりに指定された場合も実装してみました。
<?PHP
　class test{
　　var $value;
　　function test($argv){
　　　return $this->set($argv);
　　}
　　function set($argv){
　　　$this->value = $this->is_class($argv)?$argv->show():$argv;
　　　return $this;
　　}
　　function show(){
　　　return $this->value;
　　}
　　function is_class($obj){
　　　$status;
　　　if(get_class($obj)==get_class($this)){
　　　　$status = 1;
　　　}
　　　return $status;
　　}
　}

　$test1 = new test("Hello OOP World<br>");
　$test2 = new test($test1);
　print $test2->show();
?>

>>544
悲しいけど、PHP4ではそれが現実なのよね

is_classはこれだけでよかったですね。

return get_class($obj)==get_class($this);

>>547
やっぱり、そうなんですか...残念。

しかし、試しにテストプログラム作ってみましたけど、面白いですね。
まだ、継承とかは使ってないですけど、>>546のコードを実装する時に
コンストラクタとsetメッソドが同じようなコードになるので
いっそのことコンストラクタで、setメソッドを呼出せば
修正箇所は1箇所になるよなとか、valueプロパティは、最小限の呼出にして
自分内部での参照もshowメソッド経由でアクセスすれば、$valueの意味を変えたり
$valueは非公開プロパティでもいいなとか、後のメンテナンス性を考慮した
実装を考える事ができますね。

継承も使ってみました。多能性もあります。
<?PHP
　class test{
　　var $value;
　　function test($argv){
　　　$this->set($argv);
　　}
　　function set($argv){
　　　$this->value = $this->is_class($argv)?$argv->show():$argv;
　　　return $this;
　　}
　　function show(){
　　　return $this->value;
　　}
　　function is_class($obj){
　　　return get_class($obj)==get_class($this);
　　}
　}

　class sub_test extends test{
　　function sub_test($argv){
　　　$this->test($argv);
　　}
　　function show_replace($str){
　　　return preg_replace('/<!--\[replace\]-->/',parent::show(),$str);
　　}
　　function show(){
　　　return "[".parent::show()."]";
　　}
　}
　$test1 = new test("Hello World");
　$test2 = new sub_test("Hello World");
　print $test1->show()."<br>";
　print $test2->show()."<br>";
　print $test2->show_replace('【<!--[replace]-->】<br>');
　$test2->set('Hello OOP World');
　print $test2->show_replace('『<!--[replace]-->』<br>');
?>

みなさん、アドバイスありがとうございました。
おかげでオブジェクト指向プログラミングの基礎を理解できることができました。
デザインパターンやフレームワークもおいおい学んで行きます。

>>550
多能性・・・ﾀﾉｳｾｲ？

しかし、昨日質問を投げかけてからここにいたるまでまる1日以上掛かってしまいました。
みなさんは、このレベルだったら30分もあれば理解できるんでしょうね。さすがだと感心しました。
自分もこれから精進しようと思います。でも自分がプログラマだとは騙りませんの御安心ください。

>>550
さっそく自分がなにか理解違いしていましたか、失礼しました。
一応自分の理解では、多能性（たのうせい：ポリモーズヒズム）を以下の意味で使っています。

異なるオブジェクトに同じメッセージを送った場合に
そのオブジェクトの特性に会わせて振る舞いを設定できるということなので
>>550の場合、親クラスであるtestクラスのshowメソッドと
子クラスであるsub_testクラスのshowメソッドという同じ名前の
異なる振る舞いをするメソッドを実装しました。

testクラスでは、valueプロパティの値をそのまま戻り値として返しますが
sub_testクラスでは、valueの値の前後に"[]"を付けた値を戻り値として返します。

>>555は>>553のレスです。

>>555
×多能性（たのうせい） - ポリモーズヒズム(?)
○多態性（たたいせい） - ポリモーフィズム

「能」の下に心をつけるのを忘れないでください。

解釈としては>>555でおｋ。
狭義には「同じインスタンスに同じメッセージを送った場合にオブジェクトに応じた振る舞いをすること」
という風にもとらえられるけど、大した問題じゃない罠。

>>557
間違い指摘、ありがとうございます。

4はmethod()->method()の書き方出来ないのか。
知らなかった。

>>557
狭義の多態性(こんどは間違って無い)が気になったので、自分なりにサンプルを書いてみました。

PHP4を使っているためか、自分が未熟なためか(たぶんこちらでしょう)、
最終的にevalに頼らざる状態になりましたが、一応動くものができました。
こんな感じの実装でいいでしょうか？

受取ったオブジェクトの種類によってsub_testクラスのshowメソッドの振る舞いが変化します。

<?PHP
　class test{
　　var $value;
　　function test($argv){
　　　$this->set($argv);
　　}
　　function set($argv){
　　　$this->value = get_class($argv)?$argv->value:$argv;
　　　return $this;
　　}
　　function show(){
　　　return $this->value;
　　}
　}

　class sub_test1 extends test{
　　function sub_test1($argv){
　　　$this->test($argv);
　　}
　　function show(){
　　　return "[".parent::show()."]";
　　}
　}
　class sub_test2 extends test{
　　function sub_test2($argv){
　　　$this->test($argv);
　　}
　　function show(){
　　　return "{".parent::show()."}";
　　}
　}

　class sub_test extends test{
　　var $show_class;
　　function test($argv){
　　　$this->test($argv);
　　}
　　function set($argv){
　　　$this->show_class = get_class($argv);
　　　return parent::set($argv);
　　}
　　function show(){
　　　eval("\$tmp = $this->show_class::show();");
　　　return $tmp;
　　}
　}
　$str = 'Hello OOP World';
　$test1 = new sub_test(new sub_test1($str));
　$test2 = new sub_test(new sub_test2($str));
　print $test1->show()."<br>";
　print $test2->show()."<br>";
?>

↑なんか禿しいやり方だなｗ

こんな感じでどうでしょ？

print get_value(new sub_test1($str)) . "<br>";
print get_value(new sub_test2($str)) . "<br>";

function get_value($obj) { return $obj->show(); }
// 同じインスタンス（$obj）に同じメッセージ（show）だけど違う結果が返る

っていうか漏れの書いた「狭義の」ポリモーフィズムなんて敢えてPHPで実現する必要ないと思う。
PHPにおけるポリモーフィズムの是非に関するｱﾌｫ話はこのスレの前半にﾁﾗﾎﾗでてるよ。

>>563-564
なるほど、いちいちコンストラクタ経由で初期化しなくてもいいわけでなんですね。
インスタンス・メソッドで直接オブジェクトを受取ってそのまま受取ったオブジェクトのメソッドをコールしちゃうわけですね。

つまり用語の定義を理解してその実装ができていればいいわけで、こうであるべきという実装方法というのはないわけなんですね。
ただ、シンプルに実装できれば、後のメンテナンス性とか考えた場合はいろいろ利用価値がありますよってことですね。
サンプルコード大変参考になりました。

＞漏れの書いた「狭義の」ポリモーフィズムなんて敢えてPHPで実現する必要ないと思う。

ふつふつと好奇心が涌いてやってしまいました。

＞PHPにおけるポリモーフィズムの是非に関するｱﾌｫ話はこのスレの前半にﾁﾗﾎﾗでてるよ。

ちょっと読んではみたんですが話の流れが不毛だったので途中で断念しました。

また色々試してみます。助言ありがとうございました。

PHP4のSingletonで、コンストラクタを直呼びされた時に
エラーにしたいのですが
どのような方法があるでしょうか？

http://www.doyouphp.jp/sample/sample_class_dp_adapter.shtml

このサイトを見ると「Abstract::set」でJavaでいうところの
abstractを実装しているみたいなんだけどこれってPHP4でもできるの？
初めて知ったんだけど。

>>566
PHP4じゃ難しいかもね。
ま、それがprivateにしたいメソッドまで外から呼び出せてしまうPHP4の難点だ罠。
基本的にSingletonは無理だと思ったほうがいいかも。

>>567
PHP4ではオーバーライドし忘れのメソッドコール時に初めてエラー吐いて対処するしかないんだよね。
Mojavi2もそれだな。

>>568
なるほど勉強になります。

>>568
ありがとうございます。
やっぱり無理ですか…「注意する」しかないんですね。

質問というより相談です。
今、あるクラスのクラス名を考えているのですが、いい名前が思いつきません。
このクラスは時間と文字列をメンバ変数に持つだけの単純なものなのですが(Java風に書くと↓)、
いろいろな用途に使われるため、安易に名前が付けられないのです。
class X{
　　Date date;
　　String note;
}
インスタンスの具体例…
・Webページの更新履歴 (date=2005-07-06, note="ギャラリーにCGをアップしました")
・スケジュール (date=2005-07-13 18:30, note="会議室にてミーティング")
・アクセスカウンタ (date=2005-07-11, note="34")

はじめは Schedule っていうクラス名だったのですが、
上に挙げたように後々になっていろいろな応用例が出てきたので、
別の名前に変えたいと思っています。
「ある時間と、その時間に関連づけられた情報を表すデータ」という意味を表すような
よさげな名前って何かありませんでしょうか？

プログラムをしらないやつほど、デザインパターン、フレームワークとか
ほざくよな・・・・そんなの知らなくても、十分食っていける
俺はしらないが、職業プログラマとして食ってるぞ。
かっこつけたがるんだよな、そういうの使ってさ

>>571
こんなスレもあるが

クラス名・変数名に迷ったら書き込むスレ。Part5
http://pc8.2ch.net/test/read.cgi/tech/1109330204/

今思いついたんだけど、
Notation というのはどうだろうか？

noteとdateをmemoするということで

nodame

ぎゃぼー！

なんかリアクションが新しいなw

>>572
青いなｗ
もうちょっと精進しな。
井の中の蛙大海を知らず。

>>572に賛同するしないとか関係なく、>>578のレスの方がは何故か痛々しい

>>578
されど天の蒼さを知る

たしかに>>572みたいに小さな仕事しかしてなくても、
困らない程度の金は入ってくるからね。

デザパタを理解できない奴はアンチにはしる。
これ真理。

>>582
そっか！W.J.ブラウンはデザパタが理解できなかったからあんなこと言い始めたのか！

>>575
いろいろ悩んだんデスけど・・・やっぱり Notation にしましたよ。
nodameは意味不明なんで却下デス！

新しい言葉　ノダメ

>>584
歌うように使えるクラス。良い名前と思ったのになあ

>>586
お前、ただのオタクだろ、同じにおいがするぞ。友達になってくれ。

>>584
>>576のリアクションができて意味不明もないと思うが
>>586と一緒に>>587の友達になるべきだな。

PHP4でのSingleton、インスタンス内にstaticで実行フラグ持てば
再生成は防げるやん。

class hoges{

function & hoges () {
static $done = NULL;
if ($done){
trigger_error("既にありんす");
exit;
}
$done = TRUE;
}

}

インスタンス→コンストラクタだった

>>589
再生成を防いだってSingletonにはなりませんな。
PHP4では無理。

$x = new hoges();
$y = $x; // ｱﾁｬｰ

命名規則とかこじつけて、>>570の言うように「注意する」しかない。

実体の保持方法も微妙なとこだな。
考え付く限りでは、ゲッターの中で静的変数を宣言して入れとくくらいかな。

function & getInstance() {
static $instance = null;
if (! $instance) $instance = new hoges(); // コンストラクタは>>589を使うとしますか
return $instance;
}

しかしこれでは外部で先にnewされてた場合、今度はgetInstance内のnewがエラー吐くね。
結局newしないように注意するしかなくなってしまう。
そうなると再生成を防ぐコンストラクタも役に立たないな。

残るは苦肉の策でグローバル変数に保持か・・・。

PHPの場合Singletonに強制力は持たせられないけど、
ここでSingleton使ってますよという明示的な記述はできるでしょ。
言語仕様でしょうがない所は別のやり方でカバーしろよ。

PHPを使うんじゃなくてPHPに使われてる人が多いんですよ。

まあ他の言語でもいえることだけど。

>>592
> PHPの場合Singletonに強制力は持たせられないけど、

そうだね。漏れの話の論点はそういうこと。

> ここでSingleton使ってますよという明示的な記述はできるでしょ。

当たり前だね。

> 言語仕様でしょうがない所は別のやり方でカバーしろよ。

言われなくてもしますが。

よかったね

他オブジェクトの各メソッドからSingletonオブジェクトにアクセスする時、
メソッド内でgetInstanceする？
コンストラクタでプロパティーとして保持しておいて
以後そこ経由でアクセスする？
どっちがいいんかな。

コンストラクタ内に589の機構を取り入れたら
SingletonのgetInstance内で、

$instance =& new ClassName();

と書いた時、Singletonにならないことを発見しました。
どういう原理でこうなるのでしょうか？
通常new時には&は付けてはいけないのでしょうか？

と思ったらMojavi内にも「=& new」がたくさんある…
一体なにゆえ…

>>597-598
リファレンスは静的に保存することはできない。
http://www.php.net/manual/ja/language.variables.scope.php

>>599
なるほど…。PHPのリファレンスはエイリアスみたいなものだから、
異種な入れ物である静的変数とイコールにはできないということですかね。
ありがとうございました。

PHPでOOPやろうとすると、
$self->書き忘れでいつもバグが発生するのは漏れだけ？

$self->書いてもバグは消えないとおもうな

クラス変数指定するときに、$self-> つけわすれて単なるローカル変数になり、
思ったとおりに動かない、という人為的なバグがおきるんだけど。

>>603
$this->ですか？
self::ですか？
まー前者だとは思うけど。

$self じゃなくて $this だった orz
そういうことか…>>602

議論の主旨は変わりませんが

E_ALLにしとけカス
OOP云々の問題じゃねえよ

>>606
notice出せばよいのか。ごもっともです。すみませんでした

>>601
おまえは他にどんな言語でＯＯＰやってんだ？

PHP5ならE_ALLより厳しいエラーレベルが追加されたから
それを指定しておくのがよさげ。

E_STRICTは、PEARをはじめ外部ライブラリのコードがことごとく
エラーとして警告されるという諸刃の剣。

PEARはPHP4でも動くからね、
そういう互換性保ってるスクリプトは全部E_STRICTでは通らない。

classのvarを書き換えろとかnewを参照渡しするなとかうるさいからな
結局E_STRICTは表示しないようにした

Action（コマンドパターン）-ロジック-DAO
って分けてるんだけど
どこまでをDAOに入れるか、
どこまでをロジックに入れるか結構迷うなぁ。
そういうとこないですか？

>>613
PofEAAを原著で読むか、邦訳「エンタープライズ アプリケーション
アーキテクチャパターン」を読めばそのあたりの区切り方はわかってくるかも。

とりあえずは以下のWikiのTableDataGatewayとかActiveRecordとかを
読んでみては？
ttp://capsctrl.que.jp/kdmsnr/wiki/PofEAA/

>>614
ありがとう　参考にします
ちょうどJ2EEパターンの本買ってきたとこ
はっきり言ってPHP周辺の知識だけで
モダンなOOPを理解するのは不可能に近いね

どうもDAOは抽象度の高いシンプルなメソッドのみを提供し、
複雑な検索をする場合はValueListHandlerを間にかませて
キャッシュした結果セットに対して検索かけるのが流儀みたいだね…
ってPHPでそこまでやる人いるのか？？
ﾑｽﾞｶｼｽ

フロントコントローラってコントローラが一つあるだけってことですか？

>>617
コントローラの前の受付嬢

箱庭諸島SEの改造お願いしたく、書き込みます。
その改造内容というものは、Ａサイトで開催している箱庭からＢサイトで開催している箱庭にコマンドが実行できるようにするものです。
ＡサイトでＢサイトの島にミサイルを打てたり、食糧援助をできるようにしたりできたら面白いものができると思うんですね。
しかし、私にはアイデアだけでそれを実現する力があまりません。
どうかプログラムが出来る方、これを実現していただけないでしょうか？
以上、宜しくお願い致します。

>>619
コピペ？

>>620
私はここにしか書き込んでいませんのでコピペではありません。

>>619
スレ違い

よそのサーバーのデータまでアクセスできるような機構をＰＨＰって持ってたっけ？

Perlで擬似的にそういう要素を実装したものはコレ
http://bya.lib.net/yk_/index.html

データにアクセスする必要無いだろ。
受け取り側が処理すれば良いだけだし。

こういう場合ってHTTPプロトコルで受け取りするよりも
受け側のDB直接叩けるようにした方が確実だよね。
DB使ってない＆セキュリティの問題でこのケースじゃ無理だけど

何処に書き込みしたら良いか解らないので、
ココにも書き込みさせて頂きます。
実はPHPについて私自身今から勉強しても
かなりの時間がかかるかと思いまして、
って言うか多分無理に等しいと思い、
どなたか親切な方に小規模なシステムを製作
して頂きたいのですが、ダメでしょうか？？
勿論報酬は致します。交渉させて下さい。
もしやって頂ける方おられましたらお願いしたいのですが？
ノークレームと言う条件で構いませんので！！
詳しい内容はやって頂ける方がおられましたらご説明
致しますので、宜しくお願いします。

やりますけど、どんなシステムで、どのくらい払えるか教えてください。

なんでこんなところに書いてるのか分からない
楽天ビジネスとかに投げたら見積もり結構もらえるよ

請け負いますよ？
[email protected]

学校の宿題なんじゃないの？
PHPを使ってWebアプリを作ることによって
ソフトウェア工学の基礎を学ぶという
授業があった。取らなかったけど。

なんかメール来てる。
法人なら yahoo.co.jp なアカウントからメールを送るようなことしないと
思うんだが、世間一般の常識から考えてどうなんでしょう。

>>627
>>629
お返事有難う御座います。
>>629さんにはメール送りました。
>>627さんで出来ればメール下さい。
[email protected]です。
メール頂けたらシステムの説明と料金の方お伝え致します。
宜しくお願いします。

>>627 == >>629 だったりするわけだが。ｗ

＞>>627 == >>629 だったりするわけだが。ｗ
そうでしたかすいませんでした。

個人で金を扱うシステムとはますますあやすぃでつね。

>>635
やっぱり無理ですか？？
一応ある程度はHPの製作会社に依頼したのですが、
システム部分となると、値段が張りすぎて・・・
これから立ち上げようと思ってるサイトなんですけどね。

仕様とか全部公開してオープンソースで開発するのはだめ？
同じように勉強中の人たちで勉強をかねて。

面白そうだったら私もやりたい。

ヒント：２ｃｈで共同開発は成功した試しが無い

無くはないが、WebProg板では無理そうだ。
レベルが極めて低い。

>>637
確かにオープンソースで共同開発するのもいいとは思うんですけど、
結構お金掛かってまして、実際は既に１７０万円くらい掛かってます。
そろそろ予算がオーバーしそうなので誰かに協力してもらおうと思って！
ここらで公開してしまうと、いくら「著作権あります」と歌っても、
無いに等しくなるし・・・特に今回私が立ち上げようと思ってるサイト
は確実に収入になってくるのでオープンソースでの開発は難しいかと思
います。偉そうな事言ってすいませんでした。

箱庭諸島ってそんなに人気あるの？
なんか黎明期のネットゲームのような印象しかなかったんだけど

ふつーにバイトの学生雇って、作らせればいいじゃん。

どの学生が、使える人間かどうかの評価に関しては、
当該無知な雇い主さんには無理かもね。

$this->hoge ← 何でこんなに長いの？
$.hoge ← これぐらいの長さにしてくれよ・・・

新しい言語作って解決。

>>643
「$」を冗長だと思わないところがPHPプログラマらしくて素敵。

>>645
ruby 厨?

変数宣言がないんだから必要なのは当然だろ。

>>646
すぐ顔真っ赤にすんなよ PHP厨

>>647
論点ずれてるよ

それならJavaとかのが、よっぽど長いじゃん。

>>647
まったくその通り。

>>648
$が冗長とした場合の解決策は？

>>646
変数に接頭字が必要な言語の方が圧倒的に少ないと思うが……。
PHPとrubyしか知らないのか？

> すぐ顔真っ赤にすんなよ PHP厨

当該人物が、顔を真っ赤にしていたとして、この議論には何ら関係ありませんが。

そういえば何で変数の頭には$をつけるんだ？
何かに対しての混同を避けるためだと思うけど、その何かとは何？

>>654
Perlの真似しただけだろ

$で始まれば変数だって事がわかるんだから
パフォーマンスも上がるだろ。

>>656
予約語と関数と変数を見分るため？

ｳｻﾞ

rubyだってインスタンス変数には@が必要だけど。

>>659
$this->hoge に比べたら、べらぼうにシンプルで(･∀･)ｲｲ!!

その辺は趣味ってコトで。

>>654
exit;
$exit;

$some_func();
some_func();

print(abc);
print($abc);

どれも$のあるなしで挙動が違うだろ。あと、$なし言語は

print "abc $def ghi";

みたいな真似ができない。

>>655
えーっと、そこは笑うところなのか？

>>656
パフォーマンスの問題じゃないと思うが……。

phpの基本はPerlの真似だからな

今はJavaの真似を中途半端にしてるけど

パフォーマンスの問題だよ、$を見つけたら変数だってすぐコンパイラ・インタープリターが判別できるだろ

おまいら配列参照渡ししてますか？
しているとすれば
する／しないの境界はどこ？

境界はそれが速度のボトルネックになるとわかったとき。
通常はする必要なし。

ﾅﾙﾎﾄﾞ
さんくすちんぽ

$があってもなくても結局シンボルテーブルを作って参照するんだから
パフォーマンスは関係ない気がする。
あると主張するなら字句解析や構文解析のどういう部分でメリットがあるか
理由を説明して欲しい。

awkとかpythonとか$の必要ないスクリプト言語は現にあるし
それらと比較しても特に$にメリットがあるわけじゃない

php は perl の真似をした
perl は sh の真似をした

それ以上でもそれ以下でもない

>>662
> あと、$なし言語は
> print "abc $def ghi";
> みたいな真似ができない。

変数の文字列埋め込みなんてフォーマッティングや文字列連結で代替できるじゃん。

人間にとって
ぱっと見分かりやすいからだろ

>662
>$なし言語は
>print "abc $def ghi";
>みたいな真似ができない。

そういうメリットを主張する割には
defineで定義した名前は""内で使うことができないんだよな。
この辺のいいかげんさがPHPの特徴。

>>670
俺もそう思う。機械にとってどうって事じゃなくて、人にとってどうかだと思う。
ただでさえ素人（俺含む）が多いPHPerにとって、ぱっと見「あ、これ変数ね。」って思えるのは結構重要だと思う。

おまいらシェルスクリプトって変数名の後に空白入れちゃいけないんですね
まぎらわしいんじゃﾎﾞｹ！

>>668
php は perl の真似をした 
perl は csh の真似をした 
cshはshの真似をした

の方が正確ではない？

>>669
> 変数の文字列埋め込みなんてフォーマッティングや文字列連結で代替できるじゃん。 

TMTOWTDI。
それらに比べてタイプ量が少なく済み、見通しがいいのは充分メリットだと思うが。

>>671
> defineで定義した名前は""内で使うことができないんだよな。 

そりゃそうだろ……。""の中の[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]* を全部パースするのか？
第一""内で使えなくて困る場面なんてそんなにあるか？

ヒアドキュメント内とかね。

>>674
Perlの前にはawkが、その前にはsedが入ってくるような。

>>676
あれ？変数の$の話でしょ？

みんなdefine()使っているのか。

interfaceで定義したいんだけど
Javaのstatic final変数と違ってconstが使い物にならず。
PHPでJavaのstaticイニシャライザ、インスタンスイニシャライザを
真似することは不可能なんだろうか？
static メソッドを定義してSingletonパターンでなんとか
誤魔化してやるしかないんだろうか。

>>654
$をつけた理由はテンプレートとして使いたいからかと思われ。
Java用テンプレートエンジンJakarta Velocityは
テンプレート変数は$で始まるようになっている。

>>662
> >>654
> exit;
> $exit;
>
> $some_func();
> some_func();
>
> print(abc);
> print($abc);
>
> どれも$のあるなしで挙動が違うだろ。あと、$なし言語は
>
> print "abc $def ghi";


$がつくものとして上にあげたJakarta Velocityのようなテンプレートエンジン
として使うメリットはあるが、$なし言語でも
正規表現などが盛り込まれた関数や特殊な関数を使えば
その手の再現は簡単にできる。
JavaのTextFormatというクラスを思い出した。
あれを使い、かつリフレクションAPIを使えば、文字列中に$が現れたら値に変換してから表示する
というメソッドを作ることもできる。リフレクションは重たいけど。

>>665
これはまずい。
PHPはデフォルトでは配列は値渡しなのか？

Javaやりすぎて、デフォルトでは
配列やオブジェクトは参照渡しのみであり、基本型(プリミティブ型)のみ値渡し
であってこともあり、
PHPでは値渡しなどもできることを忘れていた。

やばい、バグが。


PHPではメソッドの引数にはC/C++のように値渡し参照渡しの設定はできないんだろうか？
Javaでは上と同じように、プリミティブ型のみ値渡しで
他(オブジェクトと配列)は参照渡し。

どうしても値渡しをしたい場合はObject#clone()を使ったり、オーバーライドしたりする。


PHPにはJavaのObject#clone()メソッドに相当する機能cloneもあるんだね。
これでPHPで深いクローニングができるわけか。

>>656
インタプリタ言語としてつかうならそうだけど、
JavaやC#のようなコンパイラ言語でかつ、VM上でさらにJITコンパイラによって
中間言語をさらにその場でコンパイルするような言語だと
それは最初の開発者によるコンパイルで最適化されるから
どうでもいいような気がする。

Zendエンジンなんてものもあるけど、タダで使えればねえ。

>>681
ごめん、何が言いたいかよく解らん。。
取り敢えず疑問は解決したの？

>>679
歴史的に見れば、裸の文字リテラルや予約語と衝突しないのが当初の目的でしょ。
shで裸の変数を許したらコマンドや引数はどうやって指定すりゃいいんだ。

あとは$があるとパーサが変数かどうかの判定に困らないので、文法の幅が広がる。
phpのexitみたいな括弧なしの言語構造や、Perl関数の戻り値にスカラが指定できるような
芸当は$なし言語だと厳しいでしょ。

exitは別に厳しくないか。exitって名前の変数が使えなくなるだけだな。

>>681
> PHPはデフォルトでは配列は値渡しなのか？
値渡しだけど、配列の要素を書き換えない限り、内部的には配列はコピーされないのでパフォーマンス的には参照渡しと同じ。
文字列やオブジェクトも同様。

> PHPではメソッドの引数にはC/C++のように値渡し参照渡しの設定はできないんだろうか？
&をつければ参照渡し。その点はC++に似てる。
C++では配列ならC式の参照渡し（アドレスの値渡し）で十分だけど。

とりあえず疑問文にだけコメントしといた。

http://www.zend.com/zend/art/ref-count.php

最近ＰＨＰ5に移行したんだが
たとえば。クラスtest,
メソッドtest($t){$this->t}と定義した場合
$test= class test;
でメソッドのひきすうに10を渡した場合
$test->test(10);
これでなにも表示されないんですね・・・なんかつかいずらい
いちいちメンバーを定義して
public　$tみたいに・・・めんどくせえ・・・

>>688
public $t;書いてもそのままじゃ何も表示されないとおもうけど。
echoはないわ、$this->tに値いれてないわ。おかげで主張の内容がさっぱりわからん。
まずどの言語から移行したわけ？メンバ定義なしでメンバを使える言語ってまさか・・・？

>>688
その前にメソッド名がクラス名と同じならコンストラクタになるんじゃなかったか？

>>690
php5では
function __construct() {　}
が優先される
<?php
class test {
function __construct() {
echo "testクラス作成<br>\n";
}

function test($t) {
echo $t;
}
}
$test = new test();
$test->test(10);
?>
こんなことも出来る

>>691
__construct()が優先されるけど、書いてないならこの場合test($t)が呼ばれるよ。
んで、インスタンス化した際に引数つけてないとWarningがでる。
>>688で書いてる、
$test= class test;
って書き方初めて見たのだが、それエラーするだろ？
それとも俺はPHP5しか知らないのだけど、4ではその書き方出来るの？

>>688だが・・すまんまちがったソースかいてもうた

俺がいいたかったのは
class test;
{ pubclic funciton tes($a);
{
echo($this->a);
}}
で
st= new test();
ここでメソッドをよびだした場合
st->tes(10);なにも記述しなてくて
つまりメソッドの場合$this->aってできないんだな
public $a; $this->a=$a
みたいな・・二度手間だな・・・まぁいきなり$aならこれでも表示するんだが
本みるとこの二度手間をしてる・・

なんかコンストラクタの話になってるが>>688は
> $test->test(10);
と書いているので、コンストラクタの話題を意図していたわけじゃないんだろうけどな。

>>692
> 4ではその書き方出来るの？
んなわきゃないｗ
PHP Parse error: parse error, unexpected T_CLASS in (ry
極めて真っ当なエラーですな。

>>693
その本で何を解説してるのか知らないが、大方
・プロパティ名とメソッドの引数名は同じでも問題なし
・public $a と $this->a の「a」は同じ変数を表すが tes($a) の「a」は全く別の変数
ってな感じの内容じゃないの？
どこが二度手間なわけ？

>>693
PHPの前に日本語勉強してくれと思ったのは俺だけ？

>>695
てことは
クラスの中に
メソッド　pubulic funciton hell($a)｛　echo($a."さんこんにちは");}
こういう使い方はできるんだね。現にやったらできたけど
なんかＰＨＰ5の本ではさやたら$this->
って感じでやってるから。
ＰＨＰ5の本どうでもいいけど少なすぎ＞＜

つづきだけど
本ではさ
public $a;
pubulic funciton hel($a)｛
$this->a=$a
echo($this->a."さんこんにちは")｝
みたいな使いかたをしてたから
なんでこんな二度でまをふんでるんだろうかと
本がわるいのかもしかして

しかしおまえらいいやつばかりだな・・
俺みたいなやつの質問にこたえてくれて
会社でＰＨＰつかえるやついなくてな、皆javaばかりで
おれだけＰＨＰだから肩身せまくてな
これからもよろしくたのむよ

>>693,697
$aをメソッド内のローカル変数として使いたいのか
それともフィールド変数として他のメソッドからも使いたいのか
どっちが目的なのかわからん。

>>699
この程度の内容にPHP4、PHP5、Javaで違いはないんだが（書式以外で）。
オマイがカスすぎて他の社員から相手にされてないだけではないのか。

>>699
>会社でＰＨＰつかえるやついなくてな、皆javaばかりで
>おれだけＰＨＰだから肩身せまくてな

ｵﾏｴ、どうみてもPHP使えないだろ？　下手するとPHPだけじゃなくプログラミング自体素人か。
Javaは絶対習得できそうにないからPHPでもやらせとけ、って感じしかしないのだが。

というかアレだ。
本の読み方を間違ってる。

まぁな
もともと営業ではいったからな
プログラミング歴は3週間目だ。
これで月給38万ももらってていいのか。

>>704
営業で入ったにしても日本語が下手すぎるね。
まぁ給料貰えるうちに頑張れ。

なんでthisを多用するかって事だけど、先の例だと
setterっぽく使いたかったのかな？変数ｐｕｂｌｉｃだけど・・・。
その本を読み進めて行くと、多分その疑問は解凍されると思うよ。

http://www.thinkit.co.jp/free/tech/3/8/1.html
インピーダンスミスマッチについてどうお考えですか？

仕事でPHPでオブジェクト指向で進めようとしていますが、
PHPの効率のよさはオブジェクト指向ではないやり方によるものだった
ってことはありませんか？

>>704
営業で入って、プログラミング歴3週目で、>>688 で書いている
"最近ＰＨＰ5に移行したんだが" が激しく一致しない。。。

>>707
3週間前PHP4の本渡されて勉強した後、最近新たにPHP5の本渡されて勉強しはじめたんでないか？
彼の中ではすでに「最近PHP5でクラスを自作しました」とかになっていると思われ。

>>706
規模による。

>>704
いい身分だな。
何も教えてやりたい気分も萎えそうだが
オブジェクト指向を理解していない奴と一緒にソフト開発することほど
ウザイことはないから少しだけ教えてやる。

>>698
それはお前がつまらんサンプルに踊らされてるだけだ。

>>697
PHP5でオブジェクト指向ををやるのに本が少なすぎる？
ならJavaの本を買え。
結城浩の「Java言語で学ぶデザインパターン入門」
これ嫁。これ読めばPHP5で無理矢理オブジェクト指向するよりも
オブジェクト指向は素早くすんなり理解できる。
何と言ってもオブジェクト指向といえばJavaと言われているくらいだからな。

>>698
純粋論者はインスタンスフィールド$aをprivateにすべきだと主張する傾向にあることをよく覚えておけ。
そのときは$aに対するgetter/setterを定義するることをお忘れ無く。
PHP5からは__getや__setなんてものもあるらしいな。
どんなメリットがあるのかわからんので
自力でgetA(), setA($a)を定義してはいるが。

メソッド引数で定義されている$aはローカル変数で
フィールドの$aとは異なる。
そのときの重複を避けるために$this->aという記法を用いる。

PHP5では
Javaのfinalに相当する最初の一回しか代入を許されない変数を定義できないのだろうか？
でないと不変クラスを作れない予感が。

PHP5ではオブジェクト指向言語としての
機能が強化されてもnamespaceが使えないのが非常に残念だ。
Facadeパターンなどを実現しづらい。Javaですっきりと実現できる
デザインパターンがPHP5ではあまりにも中途半端でアクセス権の管理があまりにも杜撰になる。

PHPでアクセス権云々考えてもしょうがないだろ。
PEARみたいな公式の出すらPHP４との互換性保持のため
ほぼ全てのフィールドがvar宣言。メソッドも同様。

PHPプログラマはJavaに毒され過ぎ。

Perlもあんなにヘボいオブジェクト指向でがんばってるんだから、
無理にJava目指すことは無いんじゃないかな。

OOPを知りつつ、OOPの考え方で
OOPじゃない簡単な実装だってできるだろうし。

>>718
> OOPじゃない簡単な実装だってできるだろうし。
理論ガチガチじゃない簡単な実装
に自己訂正。

PHP はパチ物臭くてナンボだろ

>>714
できるようだが。
ttp://www.php.net/manual/ja/language.oop5.final.php

>>716
PEAR::MDB2というのがあるが、
今ベータ版。
MDB1がPHP4対応であるのに対してMDB2はPHP5対応。
よってこれからのPEARはPHP5によってすべて生まれ変わる。

>>721
あのーfinalなクラスやメソッドを定義できるのは知ってるんですけどー
やりたいことはfinalなフィールド(メンバ変数、プロパティ、属性)やローカル変数を定義したいんですけどー

constしか使えないんですかぁ？
const CONSTANT = 'aa';
とかはできるんだけどさあ。

const CONSTANT2;
と宣言だけしておいて

コンストラクタで
public __construct(Type $constant){
　$this->CONSTANT2 = $constant;
}
と後から代入するってことができないんですけどー

こういうこともできなくて困ってるんですけどー
const CONSTANT3 = CONSTANT2.'連結'

こういうこともできなくて困ってるんですけどー

pulic void doMethod(final Type type){
　type = "aa"; //typeはfinal宣言されているので
　　　　　　　　　　//あとから代入するとエラーになるように、誤作動防止機能
　　　　　　　　　　//として使える。
}


これをPHP5でやると？

pulic function doMethod(constant Type $type){
　$type = "aa"; //typeはfinal宣言されているので
　　　　　　　　　　//あとから代入するとエラーになるように、誤作動防止機能
　　　　　　　　　　//として使える、はずなのだが。
}

見事にエラーですか。
困っちゃったねえこりゃ

>>718
そこでPerl6ですよ。
ParrotVirtualMachineといい、コンパイラといいバイトコードといい
もろJavaのパクリですが。

>>724
Singletonでなんとかならんか？
ってか、phpならそうやって使うのが普通だと思うが？
なぜjavaに拘る.

# finally欲しいなぁ

>>726
同意。
Javaはコンパイル型。PHPはインタプリタ型。
だから同じ書き方・動作じゃないのは当たり前なんだけど。

例えば Javaでいう Interface みたいのを
スクリプト言語に入れるのは、なんか違うよね。
そういうのはコンパイル型の言語で素直にやりなよ、ということ。

>>725
それだったらGroovyとかでも良いような気がするんだけどねー

>>727
うっせー
仕事でPHPを使わされとるんじゃい！
PHPはJavaより使いにくすぎなんじゃい！

Java2ＰＨＰなる
JavaソースをPHP5ソースに変換するツールはおらぬのか？

>>727
なんでInterfaceがいらないの？
子クラスにメソッドの実装を強制できないじゃん。

>>731
いらないんじゃなくて、ナンセンスだってことでしょ。
スクリプト言語なのに、メソッド実装を強制するような事が。
実行時に文字列を読み込んで、
その場でインタプリタがクラス作っちゃうような事もできるのに。

Interfaceみたいのは、別にあっても良いと思うけど。
速度に問題出なければ。

思うのだが、PHPでOOPしようとするのは、
Java使いがPHPを使う場合、またはPHP使いがJavaを学ぶ為って感じがする。
自分がそうだったし。
PHPでOOPだのDIだのなんだのすると速度的にかなりマイナスだしね。

ポイントは、コンパイラかインタプリタかということよりも、
静的型付けか動的型付けかということのような気がする。

正解。ポリモルフィズムとか全然意味無い。

Rubyの「実装されてないメソッドがコールされたら、こいつに委譲する」ってのが楽なんだよなぁ

それはPHPでもできるだろ。

__callや__set、__get、__autoloadは効果的に使ってみたい機能だな

王道はプロパティを全部privateかprotectedにして、セッタ/ゲッタとか、
setXXX(), getXxx() を__call()でオーバーロードするとか、そんな感じですかね。
DAO設計するときに役立ちそう。

__autoloadはオーバーライドできないのがネックだよなあ。
dev-mlでもそのへんの改善案を検討しているみたいだけど。
基本的にPHPのマジックメソッドはどれもちょっと抜けてて使いにくい。

>>732
おまい、デザインパターンをなめてるでしょ。
interfaceが無いと多重継承ができないんじゃＹＯ！

>>738
require()が無駄にリストアップされてしまう問題を
__autoload()によって解決できるとおもったらそれできんのかい？
>>740もオーバーライドができないってことは、かなり痛すぎる予感。

Javaの真似をして
とりあえず、すべてのクラスの頂点たるObjectクラスを実装して、
そのクラスにとりあえず__autoload()を
入れておくってか。

以後、すべてのクラスは、継承宣言をする予定がないときは、
かならずObjectクラスを継承するように予定変更する、と。
で、ObjectクラスにはJavaのObjectと同じように、
hashcode(), equals(), finalize(), wait(), notify()などを実装する。
少なくとも、equals()は重要。

Comparableインターフェースなども作っておく。でcompareTo()メソッドも
実装できるように。Cloneable, Serializableインターフェースも。


__autoload()を無理矢理オーバーライドするなら、
これしかないか？

__autoload()を他のメソッドでラップし、そのメソッドをサブクラスオーバーライドする。
でオーバライドしたらまたそのサブクラス内で__autoload()を実装し、オーバーライドした
メソッドを呼び出す。

っていうやりかたはうまくいかんか？

>>741
PHPで多重継承が必要な場面に遭遇したことないけど。
それが>>732の言わんとしてることじゃないの？

>>742
__autoloadのラッパ・・・？それじゃ__autoloadの意味ないじゃん。
ファクトリメソッド作るなら、そのメソッド内でrequireしたほうが話は早いわな。
とりあえず何を主張したいのかが不明瞭。
>>738と>>740への批判みたいなことを言いたいのだろうか？

>>741
多重継承しないように設計すれば良いだけでしょ。
Javaでしかデザインパターンしたこと無いのかも知れないけど…。

多重継承しないようにすればいいっておい、
委譲や集約だけに任せるってのかい。
そっちのほうがもっとナンセンスに見えることもないか？

デザインパターンでも多重継承つかったサンプルが沢山あるのに。

それに、オブジェクトをディープコピーできるようになることを示すCloneableインターフェース、
オブジェクトを直列化できることを示すSerializableインターフェース、
これらが使えんだろ。
こういうインターフェースを定義したい場面ってのが結構ある。

あるクラスを継承したいが、すでに他のクラスによって継承されているので
これ以上継承できない、っていうとき、片方のクラスがインターフェースになっていれば助かる。

とくにマーカーインターフェースは使える。
>>732はメソッド実装を強制するためだけにインターフェースを使うつもりでいるらしいが、
マーカーインターフェースはメソッドなんかいらない。
Serializableはメソッドなんか一つもない。まさにクラスにマーカーをつけるかのように
インターフェースを実装できる。
このように、一つのクラスに、継承しながら複数のインターフェースを実装したい場合があるときに、
インターフェースは役に立つ。

デザインパターンの本を良く読んでいるならインターフェースを使ったサンプルはよく見かけると思うが。
インターフェースは便利だから使う。抽象クラスだけでは限界があるとき、
非常に役立つ。
無計画に使いすぎるとインターフェースの乱立が生じてとんでもないことにはなるが。
使い方さえ気をつければ非常に使える。

それから、定数を定義するときもインターフェースをよく使う。
実装はしないがタダ定数を置くだけ。define()を使えという意見もあるが、インターフェース名::定数名
という構文規則が守られちょっとわかりやすくなる。

PHP5ではすでに抽象クラスも定義できるようになってしまった以上、
インターフェースも使えないのはなにか違和感がある。
ここでクラスだけにしたら、クラスに多重継承させることを許してしまう。
というか、クラスで多重継承ができることを許さないといけなくなる。
そうするとC++のような混乱が生じ、ダイヤモンド継承とかわけのわからんことになる。
だからインターフェースは必要なんだと。

そこまでやりたきゃPHP使わんでJava使えば良い。
デザパタは大事だけど、PHP採用してるような現場でそこまで厳密なOOPが必要か？
とも思う。
現状のPHPが中途半端な状態にあるのは分かるけど、
中途半端なら回避すれば良いだけでしょ。

仕事でどうしてもPHP使えと言われていて、PHPの今の実装はこうです。となってる。
デザパタ知ってるなら、その考えを使って、
いま組めと言われている言語にあった、無理の無い設計をするのが普通じゃないのかな。
うまく骨抜きにして言語に合うように実装する。そんだけだろ。

コンパイル言語ならコンパイラが最適化してくれるから
「プログラミングで注意すべき部分を冗長にマーキングする」でかまわんけどなぁ・・・

ZendEngineにキャッシュが搭載されるのはPHP6からだっけ？

>>746
うむ。「インターフェイスがないと多重継承ができない」とか聞くと違和感覚える。
普段どんなインターフェイスの使い方してるのか気になったりする。

Interfaceがいらないとか言ってる奴はデザパタとか知らんのだろうな。
Adapterパターンとかな。（代替手段として委譲するのもあるがな）

interfaceは多重継承の代替案ではない

PHPのinterfaceは、そのinterfaceの実装クラスを作る人には役に立つ。
ところがそれら作られたものを使う人（クラス）には役に立たない。

>750
代替って言うか常に委譲の方で良いじゃん。
interface不要って事だ。

こういう事でしょう。

execute()を持つAというinterface
それを実装したクラスB1とB2が有ったとする。

で、利用するコード
$a[] = new B1();
$a[] = new B2();
$a[] = new C1();
foreach ($a => $obj) {
$obj->execute();
}

ここでC1はたまたまexecute()を持つAを実装でないクラス。
PHPはこれでエラーが起きない。

そもそもコード中にAというクラス名が一度も出てきていないから
何をしたいのかも明確にできない。type hintingみたいな機能もあるけど
Javaと違ってmainメソッドを必ずしもクラスにする必要は無いわけだし。

>>755
まあわかってやれよ。こういうことだろ？
interface A { public function execute(); }
class B1 implements A { public function execute() { ・・・ } }
class B2 implements A { public function execute() { ・・・ } }
class C1 /* doesn't implement A */ { public function execute() { ・・・ } }
$a = array(new B1(), new B2(), new C1());
foreach ($a as $obj) $obj->execute(); // interface Aなんて初めからあってもなくても結局変わらん

つまり、PHPのinterfaceはインスタンスの型を制限する役割は全く果たせないってこった。
ただJavaライクな文法があれば、Javaに慣れている人間同士で意思の疎通や理解がしやすくなり、結果的にデザパタも組みやすくなるって面もある罠。
その点では大きな利点といえる。
しかし、飽くまで可読性・保守性に関する利点であって、PHPの言語仕様上の利点ではない。
現にPHPでデザパタは多くの場合、単に「通念的」にしか実装できないことが多いが、その限りでは文法上どんなデザパタもinterfaceなしで実装できることになる。

>>754
まあ PHP 的には以下のようにするのが限界かな。

foreach ($a => $obj) {
if ($obj instanceof A) {
$obj->execute();
}
}

もしくは duck-typing な感じで、

foreach ($a => $obj) {
if (method_exists($obj, 'execute')) {
$obj->execute();
}
}

とか。

よく考えてみたら、>>754 のコードを Java で書いた場合、

■$a をコレクションにして Iterator を使った場合

while ループの中で A obj = (A) iterator.next(); とした時に
C のインスタンスが ClassCastException で引っかかる

■$a を A の配列にした場合

配列に C1 のインスタンスを代入しようとした時点でエラー

となるわけで、どっちかっつーと PHP の扱い方のほうが便利じゃない？

>>758
だろ。

ってことは、interfaceの存在意義は何なんだ？

>>758
だからその「便利じゃない」って点こそが肝なんだよな、結局。
書けるコードに制限を設けることで意図を明確にできるわけで。

つまりinterfaceはPHPの型宣言なしという言語仕様に馴染まないって事でしょう。

>>756
インスタンスの型を制限する役割はないといっても
メソッドに引数で制限できるから
インターフェースはわりと使えるもんだよ

>>754のコードを意図的に書きたい場合、
JavaならばC1の書き直し、
状況によってはinterface A自体の見直しも必要になってくる。
AやC1が外部のライブラリならその修正も困難。
（まあ、そのためにAdapterパターンがあるのかもしれないが
Adapterパターンの多用は冗長になるなどの欠点をしばしば指摘される。）

そういう点でPHPのような動的な型付け言語は柔軟性があるのだと思う。
でも>>754のコードが意図的なのかどうかというのを
コメントなしに伝える事が不可能な点が問題。
メソッドの引数で伝えるのは状況が限られる。

柔軟性か信頼性かって事だ。

>>763
それはJAVAを理解してないだけでは

そうなの？具体的なことがないと何とも反論できん。

コンストラクタ内で
$this->hoge = "fuga";
って初期化やるのと、
プロパティー宣言部に最初から
var $hoge = "fuga";
ってやるのと、どう違うの？
何となく、プロパティー宣言部に書いておいた方が速い気はするけど
何か問題はある？

Interfaceいらないとかいってる奴はオブジェクト指向語らなくていいや。

シングルトンパターンが一つしかインスタンスを生成しないことを
いいことにインスタンスを引数で持ちまわすのではなくて
使うたびにgetInstanceするのって間違ってますか？

>767
JavaとPHPとその他一部を除く多くのオブジェクト指向言語を否定するわけね。

>>769
むしろ肯定してるんですが？

>>766
おｋ

>>767
Javaに毒されすぎ。
それはもはやオブジェクト指向じゃなくてクラス指向だよ。
要らないとは言わないし、あると便利な局面があるのも分かるけどPHPとJavaは別の言語なんだから。

>>768
むしろ常套手段かと。

>>771
ありがとう

>>768
というか、本来そうするもの

>>768
もちろん。

>>767
少なくとも>>741や>>745みたく「Interfaceがないと多重継承ができないからダメだ」とか
言ってる奴にはオブジェクト指向語らないで欲しい。

>>774
駄目なのか良いのか？

>>776
俺も思ったw

>>776
>>774 はたぶん、「もちろん　まる」って読むんだと思うよ…

複数要素をいっぺんにセットするメソッドって
どう実装してる？

1　setPropertyと別に、setPropertiesを作って、可変長引数を受け取る
2　setPropertyと別に、setPropertiesを作って、一つの配列（コンテナ）を受け取る
3 setPropertyを、可変長引数の受け取りもできるようにする
4 setPropertyを、配列（コンテナ）の受け取りもできるようにする

どれが一番いいんだろ？

Mojaviなんかでは
setErrorとsetErrorsを用意して
配列で受け取ってる＝2
みたいだけど。
それが無難ですかね。

>>779
俺も2かな。
どんなプロパティなのかにもよるけど、3や1もありうる。
4だけは混乱したから使わない。

PHPにはインターフェイスが実装されていますよ

ものすごく都合よく解釈した広い意味で

>>749,751
非常に嘆かわしいことに、インチキなJavaの入門書には、
「JavaではC++の多重継承の代用品としてInterfaceというものがあります」
なんて、腐りきった解説が今でもあったり・・・　すごく哀しい。

相当、古くに出版された本では？
Java登場初期の頃にそう言われていたのは事実。
デザインパターンとかが普及してきてから変わってきた。

言われていたって、間違った本が出版されてそれを鵜呑みにしていた奴がいただけだろ。
昔はそれが常識で事実だったみたいな言い方はよくない。

そもそもinterfaceが多重継承の代用になるという
発想が意味分からないな。

C++使ったことないからそもそも多重継承なんて知らん。

多重継承って孫クラスまでできると考えていいのでしょうか？

test

ttp://www.cmagazine.jp/src/kinjite/cpp/scale.html#index1
C++だが、参考になると思う。

SQLの記述で
$sql = "select * from $table"
みたいに
$sql = "select * from $this->table"
と書いたらエラーになるのってキモくね？
この気持ちをどうしたらいいですか。

>>791
後者の書き方でエラーにならないほうがキモいだろ。

>>791
$sql = "select * from {$this->table}";

定数も何らかの形で直接文字列に埋め込めると嬉しいなぁ

>>793
うおー
tnxです

テーブルごとにDAO作ってたんだけど
（StatementDAO,ThreadDAO等）
結合しなきゃならないケースが出てきた。
結合の場合、DAOってどうすればいいの？

>>796
DAOというよりはDataMapperに近い考え方なのかな。んで、
「さて結合の場合はどうしよう？」ってのがO/Rマッピングの課題の1つじゃなかったっけか。

自分の場合、例えば都道府県名とかあるレコードの属性に関する情報はgetterで結合しちゃってる。
呼び出しを冗長にしたくない場合はgetDetail()なんかのメソッドを作ってそっちを結合専用にしている。

複雑な結合を含むselectが必要な場合は、そのselectがどのテーブルを基にしたものかを判断し、
そのテーブル(用のクラス)にメソッドを追加してる。

>>783
ちょっとまて。

それではclassだけで多重継承ができるという誤解を生むぞ。

A extends B, C, D,E {}
を許す結果になるぞ。

それに>>788は勘違いしている。

それから、>>775は
>>741や>>745が
「Interfaceがないと多重継承ができないからダメだ」と言っていると
勘違いしているがそんなことはどこにも書いていない。

「interfaceがないと多重継承ができない」とは書いてはあるが
それがダメだなんてことはどこにも書いていない。
勘違いしすぎ。だから>>788や>>753, >>727のような誤解をする者が出てくる。

>>783をはじめとしてお前ら本当にマジレスしているのか？
ネタとしてもおかしいぞ。

interfaceを使わずにPHP5で多重継承しようとしたら
こんなメッセージが出たぞ。

Parse error: syntax error, unexpected ',', expecting '{' in C:\Program Files\Apache Group\Apache2\htdocs\PHPTest\src\ExtendedClass.php on line 10

//ClassExtendsTest.php
class ClassExtendsTest {
}

//ClassExtendsTest2.php
class ClassExtendsTest2 {
}

//ExtendedClass.php
require_once("ClassExtendsTest.php");
require_once("ClassExtendsTest2.php");
class ExtendedClass extends ClassExtendsTest, ClassExtendsTest2 {
}

//Main.php
require_once("ExtendedClass.php");
$x = new ExtendedClass();

これでもPHP5でintarfaceがなくても多重継承ができるっていうならそのやり方を説明してくれ。

>>779
PHP5にもメソッドオーバーロード機能があればねえ。
同じクラス内で引数の型と数が異なる同じ名前のメソッドを複数定義できたのに

まったく、多重継承に関してどいつもこいつも信じられないことを言う奴が多すぎ。
>>783のように本が間違ってインチキだのデマまき散らす奴までいるし。

>>786
このコードの意味がわからんのか。interfaceで多重継承している例だ
class A extends B implements C, D, E, F, G{}

だがこのような実装多重継承をするとJavaでもPHP5でもエラーになる。
class A extends B, C, D, E, F, G{}

>>787
そういうことを言う奴がinterfaceがいらないとか浅はかなことを言うんじゃない。

>>788
それはただの単一継承をなんども繰り返しているだけだ。

>>799の例は、
クラスExtendedClassがクラスClassExtendsTestとクラスClassExtendsTest2
とを同時に多重継承しようとしている例だ。だが、PHP5では
classによる多重継承が禁止されているためエラーとなる。
よって、「interfaceでないと多重継承できない」わけだ。

783は正しい

( ﾟдﾟ)・・・

interfaceの複数インプリメンテーションは
多重継承とは言わないんじゃないか？
何も「継承」はしてないぞ。

だいたいJavaやPHP5は
複雑さを取り除くためにわざわざ多重継承を使えなくしてるのに
「多重継承の代用品としてのinterface」を用意する理由があろうか。
頭の固い若者が突然張り切って飛び込んできたという印象を受けるな。

そもそも単なる継承でさえ使う場面は非常に限られているからね

>>801
extendsとinterfaceの違いをよく考えろ。
interfaceはextendsの代用品じゃない。
783はあくまでも正しい。

つーか、PHP5ってオーバーロードできねーの？

>>808
func_get_argsとかfunc_num_argsで場合分けするしかない。

pearの本でてたのでかいました。

>>801
どこらへんがデマ？

いや、マジで。

>>801
> このコードの意味がわからんのか。interfaceで多重継承している例だ
> class A extends B implements C, D, E, F, G{}

勘弁してよ。
C-Gからは、メソッドもプロパティも全く継承していないじゃん。できるわけがない。

C-Gは、インタフェースとしての受け口を決めたというだけで、実体としては空っぽ
なんだから。存在しないメソッドやプロパティを継承できるわけないさ。

なるほど、「インタフェースを継承している」という言い方はできなくもないが、
でも、それはここで話している『C++の多重継承』の『継承』じゃないと思うぞ？

で、過去のいきさつとしては・・・

C++は、仕様を拡張していく過程でよく考えないまま多重継承を盛り込んでしまって
(最初から多重継承があったわけじゃない）、後で「なんだこりゃ、こんなバカな仕様、
作り直して多重継承は廃止しろ！」という極論まで出て、そのときの大論争の中で、
「そうか、C++において多重継承が有用で、かつそれなしでは実現が困難だと思わ
れる事例というのは、実は単一継承とインタフェースの実装という形で綺麗に
まとめることができるんじゃないか。でも、一度規格に入れてしまったら、もう手遅れ
だよなぁ・・・　orz」と、いうような流れになったのが、10年くらい前のこと。

当時のC++開発者コミュニティの激論は、本にもなっているよね。

その反省のもとにJavaでは、継承とインタフェースを切り分けたわけじゃん。
そこら辺を踏まえたうえで、インタフェースも継承の一種だと主張するなら、そりゃ、
まことにごもっともなんだけど・・・　>>801 って、そこまで考えた上で言ってる？

つーか、PHPでinterface使って生産性あがるのか？
自己慢でinterface導入するなら迷惑だぞ。

生産性は落ちるかもしらんが、バグ防止と保守性は上がると思われ

PHPのinterfaceで強制できるのは、
実装すべきメソッド名とそのパラメータ数(arity)
でFA？

ぶっちゃけオブジェクト指向は必要ないとおもわん？
てかPHPﾚﾍﾞﾙでは設計とかもいらないだろ
俺はいきなり頭のなかにあるプログラムを書いていき
そして、修正し、うまくいかないときはその機能をすぱっと
きりすてる。デザイナーデザインしたやつも、わからないと
消すよ。ぶっちゃけ上司はそれでもわからんからOKでしょ。

>>815
具体的に。

>>816
PHPの言語仕様上だけの話ならFA。

Javaにおけるinterfaceの一番のメリットはポリモーフィズムでしょ。
PHPでは型宣言が無いためその恩恵をほとんど受け入れられない。

だから、例えば『PHPでGoFのデザインパターンを使ってみました』
なんてのは大抵のパターンにおいて意味がない。

>>817
何を作るか次第でしょう。
そりゃ単なる掲示板を作るだけなら要らない。
MVCでいうMの部分が複雑なロジックになるなら必要になってくる。

>>812
> >>801
> > このコードの意味がわからんのか。interfaceで多重継承している例だ
> > class A extends B implements C, D, E, F, G{}
>
> 勘弁してよ。
> C-Gからは、メソッドもプロパティも全く継承していないじゃん。できるわけがない。

おいおい、本当にinterfaceというものがどういうものかわかっているのか。
まったく信じられん。

Javaでは空のインターフェースは問題なくコンパイルできるぞ。
よくいわれるマーカーインターフェースという奴だ。
メソッドを一切持たないinterfaceのことをマーカーインターフェースと呼ぶのだ。
Javaのマーカーインターフェースの例としてはSerializableだ。
当該のオブジェクトがシリアライズ可能であることを示すためだけに使われる。


> C-Gは、インタフェースとしての受け口を決めたというだけで、実体としては空っぽ
> なんだから。存在しないメソッドやプロパティを継承できるわけないさ。

言っておくが、上記のコードでも問題なくプログラムは動くぞ。
JavaであってもPHP5であってもだ。エラーも警告も一切出ずにな。

interfaceにメソッドやフィールド(プロパティ)がないと継承（実装）が使えないと勘違いしているとは
もはや驚くとしか言いようがない。呆れるとまでいいたくなるくらいだ。

821はアホな子なのか、それともわざとか？
そんなことはぜんぜんいってないだろと

>>816
TypeHinting併用で引数の型をある程度限定できるけど・・・

>>821
さすがにここまで支離滅裂な長文を書いてくれると、苦笑いするしかないな・・・
あはははは・・・

> interfaceにメソッドやフィールド(プロパティ)がないと継承（実装）が使えない

っていう内容を含むレスはおまいが初めてだよ。

>>821
interfaceをimplementsするのは「インターフェースの継承」。
classをextendsするのは「インターフェースと実装の継承」。
812のいう「『C++の多重継承』の『継承』」は、インターフェースを除く「実装の継承」のこと。
だから「全く継承していないじゃん」になるんだが、理解できてないあたり821はC++やったことないだろ？

おそらく「継承とは何ぞや｣という日本語のレベルで、意思の疎通がとれてない
んだろうけど・・・　なんだかなあ

継承の意味に関して意思の疎通がとれてないのは>>821だけだったようだが

821みたいな奴とは絶対リアルで付き合いたくないと
ひしひしと思った初秋…

>>821
いっぱい釣れたネ

確実にいえることは、>>783が嘆いているような本が実在していたばかりか、
しかも嘆かわしいことに、その本の犠牲者も実在していたということだな。

>>828
821は、たぶん、職場で浮いている理由が自覚できないまま、「なぜ自分は
部下や同僚や上司からバカにされているんだろう」と、いつも自分が不当に
扱われていることに悩んでいるのかも知れない。

でもあきらかに>>812は勘違いしているよ。

↓この一文が勘違いしている証拠。

> なんだから。存在しないメソッドやプロパティを継承できるわけないさ。

>>825
おまえさ
『インターフェース継承』って言葉使わないの
それを略して継承っていうこともあるんだよ。
その程度のことで揚げ足とっておけば自分の無知を隠せるとでも
思ってるのかねインターフェース不要派は。

ようは、PHP5でクラスだけで実装多重継承ができるかどうかって話だろ。
>>812はできるんだと思い込んでいるらしいが>>799でできないとすでに証明されている。
それにもかかわらず>>812はこんな変なことを言って誤魔化している。

> C-Gは、インタフェースとしての受け口を決めたというだけで、実体としては空っぽ
> なんだから。存在しないメソッドやプロパティを継承できるわけないさ。


むしろお前らのほうがアホだろ。

classのextends = 実装継承
interfaceのimplements = インターフェース継承

これらを総称して『継承』と定義しよう


そうすればこれまでの話はすべてかみ合う。

●class
実装多重継承できない。実装単一継承のみできる。
abstractであるでないにかかわらずメソッドのオーバーライド可能。
空のクラスも継承できる。
スーパークラスにabstractになっているメソッドがある場合は必ずオーバーライドしなければならない。
●interface
インターフェース多重継承が可能、実装多重継承できない。
インターフェース実装方法はimplementsの後にインターフェース名をカンマで区切って列挙する。
空のインターフェースでも実装できる。それをマーカーインターフェースと呼ぶ。
abstractになっているメソッドをオーバーライド可能。
メソッドに実装を記述することはできない。定義のみ。
フィールドはすべてpublic static final
クラスがメソッドをもつインターフェースを実装した場合はそのクラスにかならず
そのメソッドをオーバーライドしなければならない。

>>812は
インターフェースC,D,E,F,Gに少なくとも
何かメソッド、フィールドが無ければ
class A extends B implements C, D, E, F, G{}
と書いてもエラーになると勘違いしている可能性があるね。

そして>>775は
class A extends B, C{}
という実装多重継承をする記法をPHP5で
行ってもエラーにならないと勘違いしている可能性が非常に高い。