PHPでOOP
PHPを使ってプログラミングするとき、 プロシージャ指向(手続き型、構造化プログラミング)でもできますが、 オブジェクト指向を使った場合の恩恵を享受するために、 PHPでオブジェクト指向プログラミングの勉強をしてみましょう。 <目的> PHP5でオブジェクト指向プログラミングを行なうための知識を習得する。 (PHP4のOOPもOK、このスレが1000に行く前にPHP6が出たらPHP6のOOPもOK) <方向性> ・このスレは、プログラミング初心者、PHP初心者の勉強の場として利用することを前提にします。 ・PHPのOOPの話題に限定します。 (Ruby、Python、Javaなど他言語のOOPについては、その言語のスレッドでお願いします。) ・PHPのOOP学習に役立つ本、WEBサイトの紹介をお願いします。 <その他> ・略記は、「OO」=「オブジェクト指向」、「OOP」=「オブジェクト指向プログラミング」でお願いします。 ・質問をする人はなるべくトリップを付けましょう。 ・荒らし、煽り、叩き、気違いは無視・無干渉でお願いします。 このスレで、今日から貴方もOOP!!!\(^o^)/ >>243 >ttp://www.geocities.jp/narutobakijp2/ ↓動作サンプルを設置しました。 http://ssurl.net/so2o ↓コードに関するコメントのまとめ(>>184-226 辺り) http://ssurl.net/h8bu >>262 非常に乙です。m(_ _)m >>226 だけど >>1 さんにここまでやって貰っちゃって申し訳ないし これぞOOPってサンプルを必死に実装してアップするんでしばしお待ちを・・ >>263 はやくアップしろよなw 俺がそれ見て勉強して、いつかエロイ人になったら お前を雇ってやるよ! 感謝しろ >>262 動作サンプルまでつけていただいて、ありがとうございます。 過去ログも、そのままコピペするんじゃなくて、色をつけたり 分類したりすると非常に分かり易いですね。 ShiftJISだったりとか、スペース2個というのは標準じゃないとかは 気づいてたのですが、そこまで治していただいて申し訳ないです。 >>266 別にわかんなくったって、やってけるから大丈夫。 無理に背伸びする必要は無い。 フレームワークの解説に関するサイトを見つけました。 ここで概要をつかんだ後、実際に触れてみるといいかもしれない。 ASP.NET vs. Struts フレームワーク徹底比較[前編] http://www.atmarkit.co.jp/fdotnet/special/aspstruts01/aspstruts01_04.html この文章書いてる人、ネットワーク関連の書籍でよく見かけるよね。 >>261 > OOPに対する基本的概念への理解があまりにも無さ過ぎると思うんだ。 > >>255 にしても、Executeメソッドに呼ばれる仕組み作ってんのに、 > なんで新しいメソッド実装して直接呼びたがるんだろう? > あれほどインタフェイスだけで実装するんだと(ry ちいたんのフレームワークは、Modelにinsertやdelを持ってるからそれを 参考に設計してみたんだけど。 ttp://php.cheetan.net/manual/model.php 俺はこれから勉強していくところなので理解がないのは認めるが、 このあたりはどういう見解なのかを教えて欲しい。 今回作るMVCフレームワークは、学習用なのでもっと簡潔な レベルなのを想定しているとか、ちいたん作っている人がOOPに 関する理解が無いだけだとか。 >>269 フレームワーク実装に正解も不正解も無いと思うけどね・・ 例えば ・クラスを使った構造化的メソッド呼び出し $model->insert(); $model->del(); よりも ・ポリモーフィズム $insert->execute(); $del->execute(); のほうがインターフェイスが規定されていて 簡潔で安全だと説明したかったんだよ。 insertメソッドやdelメソッドを呼ぶ文脈が規定されていたらどう? insertオブジェクトのexecuteメソッドならオブジェクトが 文脈をコントロール出来るでしょ? どうかな? 学習用だからこそ『呼ばれる仕組み』で実装しようとしているんだよ。 >>270 レスサンクス。となると、 class CInsert extend CView、class CDel extend CView、・・・ みたいな設計にするということ? ちょっと大雑把になってるけど、CInsertはこんな感じに実装するとか。 (テーブルのフィールドは、a,b,cという場合。) class CInsert extend CView{ var $field_a; var $field_b; var $field_c; function setItem($field, $data){ if($field == "a"){ $field_a = $data; } if($field == "b"){ $field_b = $data; } if($field == "c"){ $field_c = $data; } } function _OnExecute($param){ $fp = fopen($file_name,"a"); $write_line = $field_a . "," . $field_b . "," . $field_c; fwrite($fp,$write_line); fclose($fp); } } じゃ、用件仕様はこんな感じで良いのか? [認証] →・ID、パスワードにて認証 ・認証成功で[メニュー]へ移動 [メニュー] →・(新規)[個人情報入力]、[検索指定]画面へ移動するボタンがある [個人情報入力] →・名前、性別 を登録 [検索指定] →・氏名のキーワードを含む検索、性別指定が出来る。 [検索結果] →・条件に一致するデータを一覧で出す。 ・個人情報を修正したい場合は、ここから[個人情報入力]へ移動する。 ・個人情報を削除したい場合は、ここで削除ボタンを押す。 >>271 今こんな感じ。 [DataModel.php] <?php /** * データModel抽象クラスです。 */ class DataModel extends Model { # @access private var $_items; # @access public var $file_name; # @access public function setItem($key, $value) { $this->_items[$key] = $value; } # @access public function getItem($key) { return $this->_items[$key]; } } ?> [InsertModel.php] <?php /** * データ追加Model抽象クラスです。 */ class InsertModel extends DataModel { # @access sealed function & _onExecute(&$param) { return $this->_OnInsert(&$param); } # @access protected function & _onInsert(&$param) { trigger_error('オーバーライドして下さい。', E_USER_ERROR); } } [SampleInsertModel.php] <?php /** * データ追加 サンプルクラスです。 */ class SampleInsertModel extends InsertModel { # @access protected function & _onInsert(&$param) { // ここで初めてユーザ定義のメソッドを実行する。 // FWからここが呼ばれるまで待ってるのがポイント! // INSERTイベントの処理ハンドラに記述するともとれるね。 return $this->_saveData(); } /** * ユーザ定義のプライベートメソッド */ # @access private function _saveData() { // リクエストは以下のインターフェイスで取得。 $value = $this->getItem('hoge_data'); // ここで初めてHogeHogeする。 // DBオブジェクト呼ぶなりご自由に! return $data; } } ?> 細かい指摘になるけれど、継承関係の勉強中なので質問で書き込みします。 [InsertModel.php] class InsertModel extends DataModel function & _onExecute(&$param) のところは、 return $this->_OnInsert(&$param); となっているけれど、 return $this->_onInsert(&$param); が正しいという解釈で良いのですよね? >>273-275 ソースのサンプルサンクス。 イメージしてたよりも継承が多いですね。 全体ソースコードの可読性よりも、クラス単位での 再利用性を考えた場合は、このような構成になる のでしょうね。早く慣れないといけません。 まだ中身が出来ていない状況なので、修正の必要はあるだろうけど、 こんな感じでドキュメントもまとめていくと、分かりやすくなるだろうね。 ■SampleInsertModelクラス[SampleInsertModel.php] Model - DataModel - InsertModel - SampleInsertModel ◎概要 DBへのデータの記録、読み取りを行うクラス。 ◎メンバ一覧 [publicコンストラクタ] SampleInsertModel() [publicメソッド] setItem($key, $value):setter。フィールド名を指定し、データを登録する。 getItem($key):getter。フィールド名を指定し、データを取得する。 Execute($param):setItemでセットしたデータをDBに記録する。 ◎使用例 $model = new SampleInsertModel(); // クラスのインスタンスを生成する。 $model->setItem('Name', 'Tarou'); // [Name]フィールドに[Tarou]を登録する。 $model->setItem('Sex', 'man'); // [Name]フィールドに[man]を登録する。 $model->Execute(); // setItemで登録したデータをDBに書き込む。 >>263 ひとまず出来ました・・疲れました・説明は後でアップしようと思います・・ ttp://proxy.f3.ymdb.yahoofs.jp/bc/4525b767_dfac/bc/452a/PHP%a5%d5%a5%ec%a1%bc%a5%e0%a5%ef%a1%bc%a5%af.zip?BCUjxqHB4brtVvJJ >>279 乙です。じっくりソースを読んでみます。 せっかくプログラムを作っていただいたのだから、みんなでその説明文章をまとめるといいかもね。 例えば、こんな感じでhtmlで書いておいて、ファイル名をクリックすると、その詳細の説明のページに飛ぶとか。 [abstract] [controls] 空 [models] DataModel.php、DeleteModel.php、InsertModel.php、SelectModel.php、UpdateModel.php [views] HtmlQuickFormSmartyView.php、RenderView.php [controls] MainControl.php、SkeletonControl.php [data] 空 [framework] Base.php、Control.php、Model.php、View.php [lib] Request.php [models] SampleInsertModel.php、SampleSelectModel.php、SkeletonSelectModel.php [smarty] [cashe] 空 [templates] index_tmple.html、output_tmple.html [templates_c] 空 [views] HtmlQuickFormSmartyIndexView.php、HtmlQuickFormSmartyOutputView.php IndexView.php、OutputView.php、SkeletonView.php app.log、appconf.php、csv.txt、hoge.txt、index.php、Main.php、userconf.php >>281 >>279 ですがphpDocumentorで今作っているのでちょっと待っててね。 phpDocumentorにソース読み込ませて吐かせただけです。 ttp://proxy.f3.ymdb.yahoofs.jp/bc/4525b767_dfac/bc/452a/PHP_FW_DOC_01.zip?BCKv5qHBVNsncE.h フォルダ内のindex.htmlです、荒いですがご容赦を。 とりあえずトライアルなんでまだリファクタ出来そうだけど・・ [コントローラの処理] _form_onLoad _buttonHoge_onClick [モデルの処理] _onSelect _onInsert [ビューの処理] _onRender 上記のイベントハンドラにユーザ処理を記述して フレームワークに呼んでもらう構造になってます。 >>216 を実装したつもりです・・・ 有名なハリウッドの法則です。 [カプセル化]は良いとして、やはり[継承]と[ポリモーフィズム]を うまく使うのは最初難しいかもしれない・・ これらの実装もデザパタとしてライブラリ化されたものに過ぎないけどね。 OOP FW ソース ttp://proxy.f3.ymdb.yahoofs.jp/bc/4525b767_dfac/bc/452a/OOP_FW_02.zip?BCE07qHBz_6Z6R84 OOP FW ドキュメント ttp://proxy.f3.ymdb.yahoofs.jp/bc/4525b767_dfac/bc/452a/OOP_FW_DOC_02.zip?BCE07qHB2C3Z36pC すいません再アップしました、ドキュメントにControlが反映されてませんでした。 全体構成の把握はまだ出来てないけれど、只今、ソース解析中・・・ いちゃもんつけるつもりじゃないけれど、気になった点を2つ。 Control.phpのPOSTされたSubmitボタン名取得のところは クラス化されてないのはどうしてなのでしょうか? さらに非常にクラスが多くなって面倒になるから? class Control extends Base var \$_view_calss; このメンバはあえてclassにしてない理由はあるのでしょうか。 >>287 POSTされたサブミットボタン名取得部分は説明の通りです・・ 今その部分をC#でのデリゲートで実装しようと思ってます。 Viewクラスexecuteのところもこのままでは$eパラメータが コントローラから任意に渡せないので検討中です。 オブジェクトにexecute以外のパブリックメソッドを 実装しないのが目標です・・(※アクセサ以外) クラスの継承関係が結構複雑になってますね。 Documentsいただいても、追いかけていって、全体構造を把握するのが結構大変。 例えば、SampleInsertModelからその元を追っていくと、以下のような継承構造。 Base - Model - DataModel - InsertModel - SampleInsertModel 俺のメモとして、SampleInsertModelを追いかけていった様子をまとめておく。 ■Base(抽象)クラス[fw/framework/Base.php] ●パブリックメソッド & execute(&$param, $e) →アプリのログを記録する。_onExecute(&$param, $e)を実行 ●プロテクテッドメソッド _onExecute(&$param, $e) →サブクラスでオーバーライドして使用。 ■Model(抽象)クラス[fw/framework/Mode.php] ●プロパティ $src_file_name; // 読み込むファイル名 $dst_file_name; // 書き込むファイル名 ■DataModel(抽象)クラス[fw/abstract/models/DataModel.php] ●フィールド $_items; // コントロール値のハッシュを保存 ●パブリックメソッド setItem($key, $value) // コントロール値を受け取り、$_itemsに代入 getItem($key) // $_itemsの値を返す。 ■InsertModel(抽象)クラス[fw/abstract/models/InsertDataModel.php] ●シールドメソッド & _onExecute(&$sender, $e) →onInsert(&$sender, $e) ●プロテクテッドメソッド & _onInsert(&$sender, $e) →オーバーライドして使用する。 ■SampleInsertModelクラス[fw/models/SampleInsertModel.php] ●プロテクテッドメソッド $ _onInsert(&$sender, $e) →ここにユーザ定義のコードを記述する。_saveData()を実行 ●プライベートメソッド _saveData() →現在未実装。 こうやってみてみると、クラスを継承する際の設計思想が見えてくるな。 どの段階で実装を替えるかを考えた場合、どのクラスを置き換えれば良いかも分かる。 しかし、俺はこれまでフレームワークの構成などをじっくり読んだりしたことが無いので、 つい、ここまでクラスを継承させるメリットがあるのかなとか思ってしまう。 なんか、1つのメソッドを実装するのに、1回継承してるって感じだよね。 例えば、Model(抽象)クラスの $src_file_name を別のものにする場合、 それ以降のクラスが全部影響するかの確認が必要なわけだから、 Model(抽象)クラス以降のものをすべて一つのクラスにまとめて書いても 同じなんじゃないかと思えてしまう。 こういうのとは別な場面で、継承しているメリットがあるってことかな? ちょっと紹介しておきますね。 フレームワークを使った開発のメリット、デメリットを教えてください http://q.hatena.ne.jp/1188498291 特集:第1回 フレームワーク「Struts」の基礎を知る (3/8) フレームワークのメリットとデメリット http://www.itmedia.co.jp/enterprise/0310/06/epn03_3.html Control の & _onExecute(&\$param, \$e) で \$this->_view_calss = \$view_calss; というコードがあるけれど、右辺の \$view_calss って、 何処でも定義されてないですよね? このまま動かすと、nullが入るだけのように思えるんだけど。 Viewクラスの継承関係で、かいつまんだ一覧を書いておきます。 個別にはDocに書いてはあるけれど、こういう書き方みると分かりやすくない? Base - View - RenderView - IndexView ■Base(抽象)クラス[fw/framework/Base.php] (省略) ■View(抽象)クラス[fw/framework/View.php] ●プロパティ $post_file; // POSTするファイル名 ■RenderView(抽象)クラス[fw/abstract/views/RenderView.php] ●プロテクテッドメソッド & _onExecute(&$sender, $e) // _onRender(&$sender, $e)を呼ぶ & _onRender(&$sender, $e) // サブクラスにてオーバーラードする。 ■IndexViewクラス[fw/views/IndexView.php] ●コンストラクタ $this->post_file = 'index.php'; ●プロテクテッドメソッド & _onRender(&$sender, $e) // オーバーライド →html出力する。テキストボックスと送信ボタン >>293 1行上のフックハンドラ実行の結果を渡している。 ロードメソッド[MainControl::_form_onLoad(&$sender, $e)]が(POSTパラメータが 無い場合に呼ばれるメソッド)呼ばれるまでの経緯をたどってみたが、非常に複雑だ。。。 [fw/index.php]が実行される。 Mainクラスのインスタンスが生成され、execute(&$app, $e)が実行される。 Base:: & execute(&$param, $e) にて、 Base:: & _onExecute(&$param, $e)が実行される。 これは、Main::execute(&$app, $e)にてオーバーライドされている。 Controlクラスのインスタンスが生成され、execute(&$app, $e)が実行される。 Base:: & execute(&$param, $e) にて、 Base:: & _onExecute(&$param, $e)が実行される。 これはControl:: & _ onExecute(&$param, $e)にてオーバーライドされている。 Control:: & _onExecute(&$param, \$e) にて、Control::_hookedUpControler(&\$sender, \$e)を呼び出す。 Control::_hookedUpControler(&\$sender, \$e) にて、Control::_form_onLoad(&$sender, $e)を呼ぶ。 これはMainControl::_form_onLoad(&$sender, $e)にてオーバーライドされている。 MainControl::_form_onLoad(&$sender, $e) が実行される。 継承関係 Base - Control - MainControl Base - Main >>298 見れるはずですが・・以下はどうですか? Eclipceでのデバッグ画面です ttp://proxy.f3.ymdb.yahoofs.jp/bc/4525b767_dfac/bc/452a/OOPFW_DEBUG.jpg?BC3YDrHBI.a6ljXl >>298 どうでしょうか? ttp://briefcase.yahoo.co.jp/bc/oopfw これは、>>1 さんのサイトでは、「入力フォームを作ってみる」とは 別で、「フレームワークを作ってみる」の演習という位置づけにした 方がいいかもしれないね。 これからの流れとしては、上のほうにあるように、このソースを 解読・改変していくための補助ドキュメント作成の方向と、 このフレームワークを使ってみる人のためのドキュメント作成 (チュートリアルみたいなもの)になるだろうね。 出来る範囲でみんなで手伝っていってみましょう。 このフレームワークは、MFCみたく、あらかじめ準備された クラスのメソッド中に書き加えていくスタイルなのかな? それとも、VBみたいにそういうソースコードを全部隠蔽 してしまう方向でいくのかな?ちょっと気になった。 こうやってソースを読んでみると、これまで抽象的に聞いていた フレームワークを使ったプログラミングのメリットとデメリットが実感できるね。 今まで、システムを組む際はOOPやフレームワークを使う方向にするべきだと 思ってたけれど、そうでもなく、状況や目的に合わせて選択する というのが良い事が分かってきたような気がする。 小規模で全体概要を把握したいとか、移植性を考える場合は、フレームワークよりも、 クラスライブラリを使うスタイルの方が良い場合もありそうだ。 MVCでフレームワークを自作する方向と、クラスライブラリを自作する方向の 2つの方向をやってみて、それぞれのメリットとデメリットを確認していけば、 システムを作る場合の検討材料に出来ると思う。 何でもフルスクラッチしていき、なるべく依存性は無いようにし、(言語の バージョンくらいに収めるとか)その組み合わせでアプリを作る、みたいな。 再度リファクタしてみました。 ttp://briefcase.yahoo.co.jp/bc/oopfw [Controlクラス] ・リクエストオブジェクトの参照の重複の削除 ・サブクラスでのフックハンドラ処理修正 ・Viewオブジェクトの実行方法修正 ※これはViewオブジェクトハンドリングの自由度をました反面、 ユーザからの取り回しが煩雑になったかもしれませんね・・ [Modelクラス] ・継承関係の見直し、ItemBaseクラスの導入などです・・ MVCの継承関係が美しくないですが・・ >>291 リファクタしながら構成を練っていってますが 継承クラスでの責任が小さい単位で分割されていると 大きく修正が入った時も楽だと思います。 >>303 MFCもVB6もフックハンドラに処理を記述していく方式なので それを参考にしています、サンプルFWも自由にいじってもらって 参考にしてもらえたら良いと思います。 >>305 クラスライブラリ方式もいいかもしれないですね。 フレームワークのメリットとデメリットにおいて、なるべく具体例を書いた形でまとめてみた。 【メリット】 1.ビューとロジックの切り分けが出来る。(共同作業時に便利) http://www.atmarkit.co.jp/fdotnet/aspandvs/aspandvs01/aspandvs01_01.html 2.定型的なコードを何度も書かなくてよくなる。 例えば、ASP.NETでは、POSTの値を取得して・・・などの事を考えなくて良い。 テキストボックスやボタンも、画面にドラッグするだけ。 3.ソースコードが自動的にフレームワークの規約に従った記述方法となり、 全体的な処理構成が把握しやすく、メンテナンスが楽になる。 例えば、構造化プログラミングならば、まず全体構成(どの関数がどんな役割を 持っているかなど)を把握し、そこから問題部分を探すことになる。 フレームワークの場合は、まずはこのイベントハンドラの部分を見れば良いなという事が分かる。 【デメリット】 1.フレームワーク自体の使い方を学ばなければならない。 ・言語の基本ルールとは異なった、フレームワーク特有の記述方法があるため、すぐに組めない。 ASP.NETでは、IsPostBack の概念を学ばなければならない。 http://www.atmarkit.co.jp/fdotnet/dotnettips/043postback/postback.html ちいたんでは、function action( &$c )とか、$c->という書き方と機能を把握しなければならない。 http://php.cheetan.net/manual/tutorial.php ・フレームワーク自体にも得手・不得手など特徴があり、それを把握しなければならない。 ASP.NETはIISが必要な為、自動的にサーバOSはWindowsが必須となり、依存性がある。 ASP.NETとStrutsの比較は、以下のサイトを参照 http://www.atmarkit.co.jp/fdotnet/special/aspstruts01/aspstruts01_01.html 2.フレームワーク自体に問題があると対処が困難。 例えば.NET Framework のバグは、開発元の不具合修正を待つしかない。 オープンソースのフレームワークであっても、ソースコードが大量な為、把握が出来ない。 QA方式で書いてみた。 Q:どんな時にフレームワークを使った方がいいの? ・短期間で仕上げなければならない時(この場合はフレームワークの使い方を把握しているのが前提) ・チームで分担してシステムを組む時 ・バージョンアップを行うなど、長期的な運用が想定される時 Q:フレームワークがあまり向かない場合は? ・個人で小規模アプリを組む時。(一度組んで終わりの場合など) ・そのアプリの全体構成をすみずみまで把握しておきたい場合 ・サーバの移植を想定しなければならないなど、環境があまり固定出来ない場合 このような状況の場合は、クラスライブラリの使用を検討すると良い。 何かフレームワークを使ったとして、そのフレームワークがいつまでメンテされるか 判らないことを考えると、バージョンアップをするようなアプリの開発に向いていると いえるかどうかは、かなり怪しいと思う。 >>309 そういうケースもあるから入れるか迷ったんだよね・・・ だけど、現在の比較的規模の大きなアプリは何らかのフレームワークで 組まれている事実があるということで、書いてみた。 フレームワークのメンテが突然打ち切られるケースは無いと見ても 良いと思うけどね。事前に何らかのアナウンスがあるはず。 で、フレームワークそのものを入替える必要が生じた時は、もちろん 全部作り直しになるが、この労力は、フレームワークを使わない場合に 比べて楽だよね。という意見です。 完璧な文章がいきなりかけるわけないんだから修正しながらでいいと思う。 適当だの無責任だのいうのなら、このスレに来なくて良いと思う。 >>308 > Q:フレームワークがあまり向かない場合は? > ・そのアプリの全体構成をすみずみまで把握しておきたい場合 全体構成を隅々まで把握してなんの意味があるのだろうか? どうせ数日たったら忘れるんだし。 > ・サーバの移植を想定しなければならないなど、環境があまり固定出来ない場合 > このような状況の場合は、クラスライブラリの使用を検討すると良い。 PHP4、PHP5両対応のフレームワークもあるし、 いろんなデータベースに対応している場合もある。 フレームワークの開発というのは、そもそもが環境が固定されていないので そういう場合にはなおさらフレームワークを使ったほうが良い。 >>315 > 全体構成を隅々まで把握してなんの意味があるのだろうか? > どうせ数日たったら忘れるんだし。 じゃ、この項目は消しておきます。 > PHP4、PHP5両対応のフレームワークもあるし、 > いろんなデータベースに対応している場合もある。 > フレームワークの開発というのは、そもそもが環境が固定されていないので > そういう場合にはなおさらフレームワークを使ったほうが良い。 PHPスレで言うのもなんだけど、ASP.NETなども含めた総論という考えだったんだけどね。 Windowsサーバなのかなどを気にするとか、PHP5のみ対応のフレームワークで 開発していて、PHP4しか対応していないサーバで動かすことになる場合を という意味で、環境が固定されない書きました。 修正案 Q:どんな時にフレームワークを使った方がいいの? ・短期間で仕上げなければならない時(この場合はフレームワークの使い方を把握しているのが前提) ・チームで分担してシステムを組む時 ・バージョンアップや不具合修正など、納品後もメンテナンスが想定される時 Q:フレームワークがあまり向かない場合は? ・個人で小規模アプリを組む時。(一度組んで終わりの場合など) ・サーバの移植を想定しなければならないなど、環境があまり固定出来ない場合 このような状況の場合は、クラスライブラリの使用を検討すると良い。 あえてPHP4の構文でやってるのは、PHP4との互換性を保つため? PHP5でやっちゃうと、PHP4の環境で動かなくなるから。 >>300 >ttp://briefcase.yahoo.co.jp/bc/oopfw ソースコードを見てビックリ!(・∀・) コメントが丁寧に書いてあり、OOPを学習する上でとても助かります! 貴重なサンプルを提供していただき、どうもありがとうございました。m(_~_)m 現時点で、バージョンがOOP_FW_02とOOP_FW_03の2つあるみたいですが、とりあえずOOP_FW_02の方をまとめページに掲載させていただきました。 http://ssurl.net/8vyv >>281 http://ssurl.net/cp7a ちょっとずつ読んでますが、全部はまだ理解できないです。(´;ω;`) レスも参考にしてみます。 (=分からないことでも、検索で調べるときのヒント・手掛かりになるので) >>321 乙です。m(_ _)m >>306 ですが今後は ・認証の仕組み ・ロギングの仕組み ・エラーハンドリングの仕組み ・バリデイトの仕組み ・トークンの仕組み ・リダイレクトの仕組み ・入力→確認→完了の仕組み ・コアオブジェクトの実行権限の仕組み など実装していく予定です・・ でも、こればっかりやってるわけにいかないので 気長に見守ってやって下さい。 >>321 乙です。分かりやすくまとまっていますね。 私も少しずつ読んでいって理解しようと思っています。 他のものに比べ、コメントが多いのが助かりますよね。 >>322 読むほうも時間がかかると思いますので、 一気にやらなくていいと思います。(^^; MVCフレームワークを作っていただいてる流れとはおもいっきり違う事をいうけれど。 >>1 さんのOOPで掲示板を作るところは、もう少しクラスを分けたほうが いいと思ったので、自分なりに作ってみました。 index.phpに、いろいろと処理を詰め込んでいるような感があったので、 それを分ける考え方です。 しかし、DBはテキストベースにしているとか、書き込み欄と表示欄を 同じページにしているなど、基本構成から大幅に変えています。(^^; http://www.geocities.jp/narutobakijp2/ OOPの勉強として、簡易なBBSを作ってみました。 BBS Version1(2008.2.11) クラス間のデータのやり取りにおいて、Listクラスを使う設計にしたけれど、 PHPの場合はハッシュでよかったような気がする件。 まだまだ未熟だな・・・ 今後は、これを構造化指向へ変換したプログラムを作り、うpする予定です。 この両方のプログラムを見比べてみることで、OOPのメリットとデメリットが 見えてくるかもしれません。 OOPの継承やポリモーフィズムについての概念やそのコードの書き方に ついては分かったけれど、その設計方法のノウハウの文章はぐぐっても なかなか見当たらない。 「設計というのはそれぞれで目的次第」といってしまえばそうだけど、 hiroxpepeさんのソースや、.NET Framework や java の各クラスの 継承関係の設計を見ていると、何か共通したものを感じる。 その具体的な方針と、それを取る理由がはっきりとは分からない・・・ 何か良い文章を見かけた、もしくは知っている方は、お願いします。 ◎「メンテナンスを行う場合」の比較 【構造化指向の場合】 ソースコードに書かれている関数とグローバル変数が、どういう階層で組まれているか (どの関数でどの関数が使われているか。また、どのグローバル変数を使っているのか) は、その関数の処理内容と、その関係などを把握してからでないと、手をつけられない。 新しくグローバル変数や、関数を追加する場合。また、ローカル変数を宣言する場合は、 その名前がソースコード内で使われているかを都度チェックしなければならないので、 面倒である。 【オブジェクト指向の場合】 ソースコードそのものがクラス単位で分けられているため、手をつける場所がすぐに 分かる。他のクラスに影響するのは、そのクラスとのインターフェースを変更した場合のみ。 新しくメンバやメソッドを追加する場合は、そのクラスの中で使われているメンバや メソッドを確認するだけなので、対象となる範囲が狭く、チェックが楽。 また、プログラムそのものがクラスで部品化されるため、チームを組んで、分担作業で プログラミングがやり易い。 【注意】 構造化プログラミングであっても、関数やグローバル変数の名前の付け方を工夫すれば、 もちろん対応は可能である。そのため、メンテナンスを想定する場合は、 オブジェクト指向でなければならないわけでもない。 オブジェクト指向は、構造化指向に比べて特別に「これが出来る」というものではなく、 構造化指向で不便に感じる部分の便利機能である。 >>324 ,325 なかなか参考になりました、ありがとう。 326さんのおっしゃる通り、"設計"は経験なんかも必要になってくるので、 考えるよりも手を動かして、簡単なスクリプトを組んでみるのが最良でしょうか。 >>326 ・リファクタリング―プログラムの体質改善テクニック マーチン ファウラー著 高いけどOOPに興味のある方には絶対お勧めですよ。 ポリモーフィズム適用の具体例がコードで解説されていますよ。 構造化プログラミングではGOTO構文を使うのはNGだけど 同様にOOPではswitch構文を使用しません。 ここの部分をポリモーフィズムで実装するのです。 あなたのプログラムにswitch構文がありますか? その部分はポリモーフィズムで置き換えられますよ。 >同様にOOPではswitch構文を使用しません。 >ここの部分をポリモーフィズムで実装するのです。 これは言いすぎ。 OOの基本はモデリングであって、コーディングのスタイルじゃない。 >>329 情報ありがとうございます。 > 構造化プログラミングではGOTO構文を使うのはNGだけど > 同様にOOPではswitch構文を使用しません。 > ここの部分をポリモーフィズムで実装するのです。 > あなたのプログラムにswitch構文がありますか? > その部分はポリモーフィズムで置き換えられますよ。 この表現はすごく分かりやすかったです。 こういう感じの具体的なノウハウがあると分かりやすいですね。 >>330 「言いすぎ」というご指摘もごもっともだと思います。 しかし、OOPは、構造化指向に比べてダントツで良い所があるわけでも ないので、(このため、すべてがOOPに移項してはいない。) 良いところを説明する際は、多少は強調した感じで言わざるを 得ないところがあると思っています。 >>330 そうですね、確かに言い過ぎました・・ GOTO構文は習いませんでしたが、switch構文は習得しちゃいました。 あえてそれを使用しないで組んでみるのも勉強になるのではないでしょうか? 構造化的スタイルとOOP的スタイルを手っ取り早く理解しようとするなら それぐらいのパラダイムシフトが必要だと思うんです。 もちろんGOTO構文もswitch構文もコーディングには必要です。 switchがいらないということは、 if文もいらないな。 それともswitchを使わずに、 if文で書けばいいのかw >>328 (なんか、自分語りみたいなレスになっているけれど、 OOPの勉強方法についての意見交換にもなるかと思ったので書いておきます。) 私は、プログラミングをこれから勉強しようという時、「無駄・ムラ・無理なく 勉強する」という予備校の受験勉強の風潮を受けていましたので、先生に 「プログラミングを勉強する場合は、どんな風なやり方をしたら良いですか?」 とか「どんな順番で勉強をしていったら良いですか?」と聞いたことがあるのですが、 その先生は、「そんなことを考えている時間があるなら、その分コーディングを した方が良い」とアドバイスをしました。 実際に手を動かしてやってみると、文章や口頭の説明では言えない、何か体感的な ものが習得でき、その後の勉強方針もどうやったら良いのかが見えてきました。 「ああ、あの言葉は、こういう意味なんだな」と思いました。 プログラミングは、実技の世界なのだから、実際に手を動かしてみて見えてくるものだと 思っています。 過去に表計算をするプログラムを構造化指向で組むと、処理を関数に分けていく方法が 身についたなと思いました。なので、今度は、構造化指向で苦労をするプログラミングを してみると、OOPの良さが見えてくるのでは、と思っています。 BBSの構造化バージョンをうpしました。 ttp://www.geocities.jp/narutobakijp2/index.html OOPの勉強として、簡易なBBSを作ってみました。 BBS Version2(2008.2.11)入力したデータで改行に対応してなかったので、その部分を修正。 BBS Version2の構造化Ver(2008.2.11)上記プログラムの構造化バージョンです。 そもそも起動したら即終了するようなPHPプログラミングにOOを使う必要性が感じられない。 >>336 なんで実行時間とOOの必要性に関連があるの? >>337 それは了見が狭すぎでしょ。 >>336 じゃないけど、オブジェクトは状態を保存しておくものだから。 複雑なデータを持つオブジェクトを作っても、mod_phpはリクエストの度にプロセス生成・終了するわけで、そのオブジェクトも消える。 そもそもウェブアプリはユーザからのリクエストを受けて処理が発生しする構造だから、オブジェクトを永続化しておくことにあまり意味はない。 オブジェクト指向に興味があるなら、GUIのあるアプリケーションとか、ゲームとかを作ってみるとよいよ。 永続化されていないオブジェクトには意味がほとんどないという主張ならば、どうだろうね。 Booch先生も、「永続性」に対して、「有用ではあるがオブジェクトモデルにとって なくてはならない要素というわけではない」 って言ってるし。 (もう絶版だけど、Booch法第2版 2.2節より) >>336 だけどphpはプロセスを生成してから破棄するまでに処理を1度しか行わない関数?が多いし、 イベントが非同期で発生したりするわけでもないからOOを使うのはどうかなー?って気がする。 だいたいフローチャートで処理書けちゃうしね。 あとデータベースなりファイルなりからデータを読み込んでそれをオブジェクトの形に整形して・・・・ って処理が無駄な気がする。 実際に行う処理よりもその整形処理が長かったりするとなんか本末転倒なような。 >>341 >あとデータベースなりファイルなりからデータを読み込んでそれをオブジェクトの形に整形して・・・・ >って処理が無駄な気がする。 なるほど、それはそうだね。 いわゆるロジック的なものがほとんどない Webアプリってのは存在するし。(っていうか大半かも) フレームワークでもなんでも、整理してるつもりで回りくどいだけってのは多い気がする。 話に付き合ってくれて、どうもありがと。 > いわゆるロジック的なものがほとんどない Webアプリってのは存在するし。(っていうか大半かも) どう考えても少数だろw ロジック無しで何が作れるというんだ?w > そもそもウェブアプリはユーザからのリクエストを受けて処理が発生しする構造だから、オブジェクトを永続化しておくことにあまり意味はない。 その理屈だと、PHPに限らず、JavaでもRubyでもオブジェクト指向は要らないということになるな。 それにアプリでも終了すると消えるわけで、結局はウェブアプリと同じ。 そもそもデータベースやファイルにデータを保存するのも オブジェクトの保存・永続化なわけだが? > あとデータベースなりファイルなりからデータを読み込んでそれをオブジェクトの形に整形して・・・・ > って処理が無駄な気がする。 > 実際に行う処理よりもその整形処理が長かったりするとなんか本末転倒なような。 だからフレームワーク使うんじゃん。 >>343 単純に、SQLにパラメータ設定して、実行して、検索結果をエスケープしてHTML/XMLのタグつけて 返してるだけで出来てるWebアプリって多そうだけどな。ロジックというほどのもんでもないでしょ。 >>344 ムダなのは実装時間じゃなくて、CPU時間でしょ。 フレームワークで解決する問題じゃないと思うが。 >>345 訂正 「本末転倒」って言葉からすると、実装量なのかな。 取り消します。 >>341 > あとデータベースなりファイルなりからデータを読み込んでそれをオブジェクトの形に整形して・・・・ > って処理が無駄な気がする。 > 実際に行う処理よりもその整形処理が長かったりするとなんか本末転倒なような。 これはもともとOOPの特性じゃない? 再利用性や保守性を高めるために、他の処理とを完全に切り分ける代わりに、 構造化指向よりも、コード量が多く、動作が重くなるというのは。 これは、個人で組む小規模プログラムでは無駄でしかないが、チームで組んだり、 改変がある場合には威力を発揮する、という類のことでしょ。 確かに私もWebアプリの世界ではOOPの意味は少ないと思う。 指摘にあるように、フローチャートがかけるような処理しかしていないので、 主にPerlやPHPで構造化指向でコーディングするスタイルが流行っているのだと思う。 (PerlやPHPのOOP対応は未だに不十分なところがある) また、ネットにあるサンプルアプリは構造化指向のものが非常に多い事からも、 構造化指向で十分に組めることを意味しているのだと感じる。 通常だと、「だったら、WebアプリをOOPで組む必要ないよね。」となるわけだが、 私がそれでもあえてOOPをやっているのは、その有用性などを自分で体感する形で 確認したいからだ。 大規模なアプリとなると、WebアプリでもOOPを活用して組むことが多いと聞くが、 それは具体的にどのような場面で、どのような有用性があるからなのか。それらを確認したい。 最近は、どうも(Webアプリの世界では)OOPの有用性を見るよりも、 各種フレームワークの有用性を確認した方が良いのでは、と感じている。 > 確かに私もWebアプリの世界ではOOPの意味は少ないと思う。 > 指摘にあるように、フローチャートがかけるような処理しかしていないので、 OOPの意味が少ないの理由がおかしい。 フローチャートがかけるような処理しか”貴方が”していないから 必要ないといっているだけであって、そうではないものはOOPの意味がある。 「Webアプリはフローチャートがかけるような処理」という前提がそもそもおかしい。 > 大規模なアプリとなると、WebアプリでもOOPを活用して組むことが多いと聞くが、 > それは具体的にどのような場面で、どのような有用性があるからなのか。それらを確認したい。 OOPの有効性、そのものがわかってないだけじゃないか? > 最近は、どうも(Webアプリの世界では)OOPの有用性を見るよりも、 > 各種フレームワークの有用性を確認した方が良いのでは、と感じている。 各種フレームワークは、すべて(といって問題ないレベルで)OOPで 作られていることを知らないの? >>349 別にOO的なモデリングをしなくても複雑さが増大しないのであれば、OOを選択するのは技術的な理由ではないでしょ。 前提がおかしいと主張するなら、どうおかしいのか言わないと、それこそ意味がない。 クラスを使ってるだけで、オブジェクト指向でも何でもないよ。ウェブフレームワークは。 オブジェクト指向を謳うなら、オブジェクトをシリアライズしてDBやセッションに保存するくらいはしないと。 そんなフレームワークがどれだけある? ウェブアプリで扱うデータのほとんどはRDBMSだけど、RDBMS自体はフラットなデータ構造でまったくオブジェクト指向ではない。 だから、RDBMSからオブジェクトにいったん変換するんだけど、最終的にはHTMLというやはりフラットな構造に戻さないと行けない。 例えばgmailみたいに非常に複雑な処理が要求されるサイトなら、いったんオブジェクトにするのは有効と思うけど、gmailみたいなサイトは例外的。 ほとんどのウェブサイトは、ただDBに入った値を表示するだけでいい。 >>356 あっそ、じゃおまえがオブジェクト使わずに書けばいいだけじゃね? OOプログラミングってのは、OO的にモデリングしたものをプログラミングすることであって、 オブジェクトを使ってプログラミングすることではないでしょ。 これを区別しないのは 「VC++で作ったからオブジェクト指向だ」って言うのと同じ。 >>358 概念じゃなく具体的なコードで説明して下さいお願いします。 そんなんムリ( ゚Д゚) 本でも読んで勉強して。 今まで読んだ本でOOに関して一番良かったのは Booch法:オブジェクト指向分析と設計 なんだけど、 いくら Booch法自体が古いとは言え、こうした本が絶版になってしまっているというのは、なんとも悲しい。 勉強したい人が集まってるんだから、必要・不必要で論争しなくても……。 read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる