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^)／
PHPでOOP
11 ◆SWtzLesEmM
2007/02/23(金) 13:35:52ID:???249nobodyさん
2008/02/05(火) 08:55:19ID:??? >>248
HTML処理のヘルパクラス作成はあまりOOPの勉強にならないとも思うんだ。
もう既に頭の中で実装出来ているだろうし、引数を関数で処理するだけでしょ？
それよりも例えばPEARのHTML_QuickFormやテンプレートレンダラのSmartyを
Viewと連携させる仕組みとかを考えたりした方がよっぽど面白いよ。
すべてをフルスクラッチするプログラミングの方向性は必ずしも得策じゃないよ
既存のライブラリやコンポーネントを上手く利用するのもOOPの要素なんだよ。
HTML処理のヘルパクラス作成はあまりOOPの勉強にならないとも思うんだ。
もう既に頭の中で実装出来ているだろうし、引数を関数で処理するだけでしょ？
それよりも例えばPEARのHTML_QuickFormやテンプレートレンダラのSmartyを
Viewと連携させる仕組みとかを考えたりした方がよっぽど面白いよ。
すべてをフルスクラッチするプログラミングの方向性は必ずしも得策じゃないよ
既存のライブラリやコンポーネントを上手く利用するのもOOPの要素なんだよ。
250nobodyさん
2008/02/05(火) 11:06:34ID:??? OOPで継承を用いた設計について調べてみた。（OOP理論の入門ではなく、
継承を用いた設計などが入った解説）
この連載は良いかもしれない。
オブジェクト指向プログラミング超入門
.NETでオブジェクト指向プログラミングを始めよう
http://www.atmarkit.co.jp/fdotnet/basics/oop_index/index.html
特に第6回は、今まで出てきていた話題だと思う。
Objectクラスで仮想メソッドToStringをもち、それから派生したクラスは、
オーバーロードをする仕組みを図説していて分かりやすい。
第6回 階層の頂点に立つクラス
http://www.atmarkit.co.jp/fdotnet/basics/oop06/oop06_01.html
継承を用いた設計などが入った解説）
この連載は良いかもしれない。
オブジェクト指向プログラミング超入門
.NETでオブジェクト指向プログラミングを始めよう
http://www.atmarkit.co.jp/fdotnet/basics/oop_index/index.html
特に第6回は、今まで出てきていた話題だと思う。
Objectクラスで仮想メソッドToStringをもち、それから派生したクラスは、
オーバーロードをする仕組みを図説していて分かりやすい。
第6回 階層の頂点に立つクラス
http://www.atmarkit.co.jp/fdotnet/basics/oop06/oop06_01.html
251nobodyさん
2008/02/05(火) 11:52:25ID:??? >>250
PHPのプログラマにも非常に参考になると思いますよ。
.NETの世界はクラスベースなので初めからOOPの思考で実装します。
関数が作れないので構造化思考のVB6プログラマとか、クラスをnewせずに
引数を大量に渡すスタティックメソッドを呼んだりしてしまいます・・・
PHPはC言語での関数モジュールを呼び出す実装スタイルに近いので
やはりクラスを使って構造化プログラミングをしちゃいがちですね。
普及しているPHP4がOOP対応不十分なのと、開発環境が貧弱であることも
PHPでOOPがなかなか利用されない原因になってたりしますよね。
プロテクテッドメソッドの概念とかIDEがないと、なんでそうするのか
なかなか理解出来ないとも思いますしね。
PHPのプログラマにも非常に参考になると思いますよ。
.NETの世界はクラスベースなので初めからOOPの思考で実装します。
関数が作れないので構造化思考のVB6プログラマとか、クラスをnewせずに
引数を大量に渡すスタティックメソッドを呼んだりしてしまいます・・・
PHPはC言語での関数モジュールを呼び出す実装スタイルに近いので
やはりクラスを使って構造化プログラミングをしちゃいがちですね。
普及しているPHP4がOOP対応不十分なのと、開発環境が貧弱であることも
PHPでOOPがなかなか利用されない原因になってたりしますよね。
プロテクテッドメソッドの概念とかIDEがないと、なんでそうするのか
なかなか理解出来ないとも思いますしね。
252nobodyさん
2008/02/05(火) 11:56:50ID:??? いくらかのデータを登録し、その内容を検索するWebシステムで使用する
クラス構成で、Viewに絞った構成を考えてみた。
[View]
├[認証]
├[個人情報入力]
├[メニュー]
├[検索指定]
├[検索結果]
別の案として、[View]から[Input View]と[Output View]の
二つを継承し、さらに以下のような継承も浮かんだけれど、
継承して分ける必要性は無さそうなので、上記の方が良いように思う。
[Input View]
├[認証]
├[個人情報入力]
[Output View]
├[メニュー]
├[検索指定]
├[検索結果]
クラス構成で、Viewに絞った構成を考えてみた。
[View]
├[認証]
├[個人情報入力]
├[メニュー]
├[検索指定]
├[検索結果]
別の案として、[View]から[Input View]と[Output View]の
二つを継承し、さらに以下のような継承も浮かんだけれど、
継承して分ける必要性は無さそうなので、上記の方が良いように思う。
[Input View]
├[認証]
├[個人情報入力]
[Output View]
├[メニュー]
├[検索指定]
├[検索結果]
253nobodyさん
2008/02/05(火) 12:16:06ID:???254nobodyさん
2008/02/05(火) 13:28:44ID:??? Debug用出力のメソッドをView（基底クラス）に追加するといいだろうね。
各画面（[LoginView] [InsertView] [MenuView] ・・・）で
エラー確認用のメソッドをオーバーロードする形で。
開発中はPOSTで受け取ったデータとかを画面上部に表示しながら動作確認する
っていうのは、よくやるからね。
Objectクラスを継承する形にするのは、このスレでは共通したメソッドの
実装という理由だ。という話だったけど、リファレンス関係の処理で
便利だという話がサイトに載っているようだね。
このあたりの考え方も活かすと良いかもしれない。
ただ、PHPのOOPだとうまく実装出来ないかもしれないが。
>>207-209 >>250
各画面（[LoginView] [InsertView] [MenuView] ・・・）で
エラー確認用のメソッドをオーバーロードする形で。
開発中はPOSTで受け取ったデータとかを画面上部に表示しながら動作確認する
っていうのは、よくやるからね。
Objectクラスを継承する形にするのは、このスレでは共通したメソッドの
実装という理由だ。という話だったけど、リファレンス関係の処理で
便利だという話がサイトに載っているようだね。
このあたりの考え方も活かすと良いかもしれない。
ただ、PHPのOOPだとうまく実装出来ないかもしれないが。
>>207-209 >>250
255nobodyさん
2008/02/05(火) 13:44:31ID:??? Modelクラスも以下のメソッドを追加するという感じで設計すると良いのかな。
Select // データ取り出し
Delete // 削除
Insert // 新規追加
Update // 既存データの更新
>>228に載ってる既存のクラスには Execute があるけれど、
これも残しておくべきかな？
Select // データ取り出し
Delete // 削除
Insert // 新規追加
Update // 既存データの更新
>>228に載ってる既存のクラスには Execute があるけれど、
これも残しておくべきかな？
256に ◆lKs5QMUHoA
2008/02/05(火) 19:03:57ID:??? 案がいくつか出てきたので、前回の駄目なソースを破棄して
またソースコードをリニューアルしようかと思ったが、
いざやり始めてみると、データベースを管理する基底クラスの
設計を具体的にどうするかをきめないといけなくなり、それを
どうするかで迷っている。。。
概ね以下のような感じにしたいと思ってるんだけどね。
DB格納の基底クラス：CFDB
テキストファイルに保存するクラス：Text_DB extend CFDB
PostgreSQLに保存するクラス：PostgreSQL_DB extend CFDB
MySQLに保存するクラス：MySQL_DB extend CFDB
で、この３つのいずれかのインスタンスを Model のメンバに持たせる。
現在のコード（CFModelのメンバ）
var $file_name; // 読み込むファイル名
更新案のコード
var $m_db; // データベースを格納。
またソースコードをリニューアルしようかと思ったが、
いざやり始めてみると、データベースを管理する基底クラスの
設計を具体的にどうするかをきめないといけなくなり、それを
どうするかで迷っている。。。
概ね以下のような感じにしたいと思ってるんだけどね。
DB格納の基底クラス：CFDB
テキストファイルに保存するクラス：Text_DB extend CFDB
PostgreSQLに保存するクラス：PostgreSQL_DB extend CFDB
MySQLに保存するクラス：MySQL_DB extend CFDB
で、この３つのいずれかのインスタンスを Model のメンバに持たせる。
現在のコード（CFModelのメンバ）
var $file_name; // 読み込むファイル名
更新案のコード
var $m_db; // データベースを格納。
257nobodyさん
2008/02/05(火) 20:33:23ID:??? >>255
普通は機能をメソッドに振り分けると思うけど
コントローラのメソッド内で以下の様に
操作出来たら面白くない？
// モデルにフォーム値を渡してデータ書き込み
$insert = $this->models['InsertModel'];
$insert->setItem('name', $_POST['name']);
$insert->setItem('title', $_POST['title']);
$insert->setItem('body', $_POST['body']);
$insert->execute();
// ビュー表示用にデータをロードする
$select = $this->models['SelectModel'];
$data = $select->execute();
>>256
自分なりに試行錯誤で機能を実装してみるのも楽しいかもね。
誰か>>252のアプリ作成に必要な要求仕様作ってよ。
普通は機能をメソッドに振り分けると思うけど
コントローラのメソッド内で以下の様に
操作出来たら面白くない？
// モデルにフォーム値を渡してデータ書き込み
$insert = $this->models['InsertModel'];
$insert->setItem('name', $_POST['name']);
$insert->setItem('title', $_POST['title']);
$insert->setItem('body', $_POST['body']);
$insert->execute();
// ビュー表示用にデータをロードする
$select = $this->models['SelectModel'];
$data = $select->execute();
>>256
自分なりに試行錯誤で機能を実装してみるのも楽しいかもね。
誰か>>252のアプリ作成に必要な要求仕様作ってよ。
258に ◆lKs5QMUHoA
2008/02/05(火) 23:02:08ID:??? >>257
要求仕様案
私は眼鏡屋（○○支店の店長）をやっている。
顧客の情報（名前、住所、性別、生年月日、・・・）を管理したい。
・眼鏡を購入した顧客の情報を登録しておき、ある一定期間経つと
新しい眼鏡を購入する案内のＤＭを発送したい。
→条件検索をしたい。
・登録した情報を検索し、どんなお客様かをすぐに確認出来るようにする。
→例えば、苗字を聞いて、詳細が分かるようにする。
・眼鏡の定期的なメンテナンスで、訪問してきたら、その対応履歴を
登録しておきたい。
→眼鏡のクリーニング、シリコンパッド（鼻にあてるやつ）の交換など
・定期的なメンテナンスは無料であるので、全く店に来ない客には、
その無料案内のＤＭを発送したい。
→今回は、複数の店舗にまたがった処理はいらない。
・他の社員に勝手に情報を触られないように、認証を通すようにする。
眼鏡の在庫管理は、このシステムとは別。
これは、プログラムの規模が大きくなりすぎるようであれば、
もちろん内容を変えてもいいです。「顧客の情報を登録し、
それを検索する」という流れだと、勉強用サンプルとして非常に
良いのでは、と思いました。
要求仕様案
私は眼鏡屋（○○支店の店長）をやっている。
顧客の情報（名前、住所、性別、生年月日、・・・）を管理したい。
・眼鏡を購入した顧客の情報を登録しておき、ある一定期間経つと
新しい眼鏡を購入する案内のＤＭを発送したい。
→条件検索をしたい。
・登録した情報を検索し、どんなお客様かをすぐに確認出来るようにする。
→例えば、苗字を聞いて、詳細が分かるようにする。
・眼鏡の定期的なメンテナンスで、訪問してきたら、その対応履歴を
登録しておきたい。
→眼鏡のクリーニング、シリコンパッド（鼻にあてるやつ）の交換など
・定期的なメンテナンスは無料であるので、全く店に来ない客には、
その無料案内のＤＭを発送したい。
→今回は、複数の店舗にまたがった処理はいらない。
・他の社員に勝手に情報を触られないように、認証を通すようにする。
眼鏡の在庫管理は、このシステムとは別。
これは、プログラムの規模が大きくなりすぎるようであれば、
もちろん内容を変えてもいいです。「顧客の情報を登録し、
それを検索する」という流れだと、勉強用サンプルとして非常に
良いのでは、と思いました。
259に ◆lKs5QMUHoA
2008/02/05(火) 23:21:24ID:??? [データの入力例]
氏名：茂名
フリガナ：モナー
性別：男性
生年月日：H1/3/3
住所：東京都・・・
コメント：ふちなしタイプを希望している。
眼鏡購入日：2007/1/5
眼鏡の型番：2ch
[2007/1/5に購入した2ch]のメンテナンス履歴
2007/2/5：クリーニング
2007/3/15：ネジの交換
2007/5/1：クリーニング、曲がったフレームの修正
顧客のデータ１件に、眼鏡の購入日がつながり、さらに、メンテナンス履歴が
つながる構成になるけれど、今回は勉強用なので、「顧客のデータ１件＝眼鏡の購入日１件」
としてもいいかもね。
再度購入したら、顧客の個人情報を０から入力しなおすみたいな。
氏名：茂名
フリガナ：モナー
性別：男性
生年月日：H1/3/3
住所：東京都・・・
コメント：ふちなしタイプを希望している。
眼鏡購入日：2007/1/5
眼鏡の型番：2ch
[2007/1/5に購入した2ch]のメンテナンス履歴
2007/2/5：クリーニング
2007/3/15：ネジの交換
2007/5/1：クリーニング、曲がったフレームの修正
顧客のデータ１件に、眼鏡の購入日がつながり、さらに、メンテナンス履歴が
つながる構成になるけれど、今回は勉強用なので、「顧客のデータ１件＝眼鏡の購入日１件」
としてもいいかもね。
再度購入したら、顧客の個人情報を０から入力しなおすみたいな。
260に ◆lKs5QMUHoA
2008/02/06(水) 01:36:05ID:??? View の Debug メソッドの仕様もどうするかで迷っている。
Execute($param)したあと、Debugとか、もしくは、
Debugの中でExecute($param)を呼び出す処理だと、
<html>タグのそとに確認データが出力されてしまう。
Debug モードを on にすれば、<body>タグの上部に
テーブルで区切ってデータが表示されるとかかな。
だったら、メンバにDebugモードを追加かな。
という感じに考えてる。
みんなどう思う？
Execute($param)したあと、Debugとか、もしくは、
Debugの中でExecute($param)を呼び出す処理だと、
<html>タグのそとに確認データが出力されてしまう。
Debug モードを on にすれば、<body>タグの上部に
テーブルで区切ってデータが表示されるとかかな。
だったら、メンバにDebugモードを追加かな。
という感じに考えてる。
みんなどう思う？
261nobodyさん
2008/02/06(水) 09:30:01ID:???2621 ◆SWtzLesEmM
2008/02/06(水) 10:44:17ID:??? >>243
>ttp://www.geocities.jp/narutobakijp2/
↓動作サンプルを設置しました。
http://ssurl.net/so2o
↓コードに関するコメントのまとめ（>>184-226辺り）
http://ssurl.net/h8bu
>ttp://www.geocities.jp/narutobakijp2/
↓動作サンプルを設置しました。
http://ssurl.net/so2o
↓コードに関するコメントのまとめ（>>184-226辺り）
http://ssurl.net/h8bu
263nobodyさん
2008/02/06(水) 11:45:05ID:???265に ◆lKs5QMUHoA
2008/02/06(水) 16:04:09ID:??? >>262
動作サンプルまでつけていただいて、ありがとうございます。
過去ログも、そのままコピペするんじゃなくて、色をつけたり
分類したりすると非常に分かり易いですね。
ShiftJISだったりとか、スペース2個というのは標準じゃないとかは
気づいてたのですが、そこまで治していただいて申し訳ないです。
動作サンプルまでつけていただいて、ありがとうございます。
過去ログも、そのままコピペするんじゃなくて、色をつけたり
分類したりすると非常に分かり易いですね。
ShiftJISだったりとか、スペース2個というのは標準じゃないとかは
気づいてたのですが、そこまで治していただいて申し訳ないです。
266nobodyさん
2008/02/06(水) 16:34:44ID:??? MVCって難しいね。
268に ◆lKs5QMUHoA
2008/02/06(水) 20:19:07ID:??? フレームワークの解説に関するサイトを見つけました。
ここで概要をつかんだ後、実際に触れてみるといいかもしれない。
ASP.NET vs. Struts
フレームワーク徹底比較［前編］
http://www.atmarkit.co.jp/fdotnet/special/aspstruts01/aspstruts01_04.html
この文章書いてる人、ネットワーク関連の書籍でよく見かけるよね。
ここで概要をつかんだ後、実際に触れてみるといいかもしれない。
ASP.NET vs. Struts
フレームワーク徹底比較［前編］
http://www.atmarkit.co.jp/fdotnet/special/aspstruts01/aspstruts01_04.html
この文章書いてる人、ネットワーク関連の書籍でよく見かけるよね。
269nobodyさん
2008/02/07(木) 10:03:39ID:??? >>261
> OOPに対する基本的概念への理解があまりにも無さ過ぎると思うんだ。
> >>255にしても、Executeメソッドに呼ばれる仕組み作ってんのに、
> なんで新しいメソッド実装して直接呼びたがるんだろう？
> あれほどインタフェイスだけで実装するんだと（ｒｙ
ちいたんのフレームワークは、Modelにinsertやdelを持ってるからそれを
参考に設計してみたんだけど。
ttp://php.cheetan.net/manual/model.php
俺はこれから勉強していくところなので理解がないのは認めるが、
このあたりはどういう見解なのかを教えて欲しい。
今回作るMVCフレームワークは、学習用なのでもっと簡潔な
レベルなのを想定しているとか、ちいたん作っている人がOOPに
関する理解が無いだけだとか。
> OOPに対する基本的概念への理解があまりにも無さ過ぎると思うんだ。
> >>255にしても、Executeメソッドに呼ばれる仕組み作ってんのに、
> なんで新しいメソッド実装して直接呼びたがるんだろう？
> あれほどインタフェイスだけで実装するんだと（ｒｙ
ちいたんのフレームワークは、Modelにinsertやdelを持ってるからそれを
参考に設計してみたんだけど。
ttp://php.cheetan.net/manual/model.php
俺はこれから勉強していくところなので理解がないのは認めるが、
このあたりはどういう見解なのかを教えて欲しい。
今回作るMVCフレームワークは、学習用なのでもっと簡潔な
レベルなのを想定しているとか、ちいたん作っている人がOOPに
関する理解が無いだけだとか。
270nobodyさん
2008/02/07(木) 10:24:36ID:??? >>269
フレームワーク実装に正解も不正解も無いと思うけどね・・
例えば
・クラスを使った構造化的メソッド呼び出し
$model->insert();
$model->del();
よりも
・ポリモーフィズム
$insert->execute();
$del->execute();
のほうがインターフェイスが規定されていて
簡潔で安全だと説明したかったんだよ。
insertメソッドやdelメソッドを呼ぶ文脈が規定されていたらどう？
insertオブジェクトのexecuteメソッドならオブジェクトが
文脈をコントロール出来るでしょ？ どうかな？
学習用だからこそ『呼ばれる仕組み』で実装しようとしているんだよ。
フレームワーク実装に正解も不正解も無いと思うけどね・・
例えば
・クラスを使った構造化的メソッド呼び出し
$model->insert();
$model->del();
よりも
・ポリモーフィズム
$insert->execute();
$del->execute();
のほうがインターフェイスが規定されていて
簡潔で安全だと説明したかったんだよ。
insertメソッドやdelメソッドを呼ぶ文脈が規定されていたらどう？
insertオブジェクトのexecuteメソッドならオブジェクトが
文脈をコントロール出来るでしょ？ どうかな？
学習用だからこそ『呼ばれる仕組み』で実装しようとしているんだよ。
271nobodyさん
2008/02/07(木) 10:55:50ID:??? >>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);
}
}
レスサンクス。となると、
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);
}
}
272nobodyさん
2008/02/07(木) 11:32:07ID:??? じゃ、用件仕様はこんな感じで良いのか？
[認証]
→・ID、パスワードにて認証
・認証成功で[メニュー]へ移動
[メニュー]
→・（新規）[個人情報入力]、[検索指定]画面へ移動するボタンがある
[個人情報入力]
→・名前、性別 を登録
[検索指定]
→・氏名のキーワードを含む検索、性別指定が出来る。
[検索結果]
→・条件に一致するデータを一覧で出す。
・個人情報を修正したい場合は、ここから[個人情報入力]へ移動する。
・個人情報を削除したい場合は、ここで削除ボタンを押す。
[認証]
→・ID、パスワードにて認証
・認証成功で[メニュー]へ移動
[メニュー]
→・（新規）[個人情報入力]、[検索指定]画面へ移動するボタンがある
[個人情報入力]
→・名前、性別 を登録
[検索指定]
→・氏名のキーワードを含む検索、性別指定が出来る。
[検索結果]
→・条件に一致するデータを一覧で出す。
・個人情報を修正したい場合は、ここから[個人情報入力]へ移動する。
・個人情報を削除したい場合は、ここで削除ボタンを押す。
273nobodyさん
2008/02/07(木) 12:35:22ID:??? >>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];
}
}
?>
[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];
}
}
?>
274nobodyさん
2008/02/07(木) 12:36:19ID:??? [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);
}
}
<?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);
}
}
275nobodyさん
2008/02/07(木) 12:37:26ID:??? [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;
}
}
?>
<?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;
}
}
?>
276nobodyさん
2008/02/07(木) 13:59:04ID:??? 細かい指摘になるけれど、継承関係の勉強中なので質問で書き込みします。
[InsertModel.php]
class InsertModel extends DataModel
function & _onExecute(&$param) のところは、
return $this->_OnInsert(&$param); となっているけれど、
return $this->_onInsert(&$param); が正しいという解釈で良いのですよね？
[InsertModel.php]
class InsertModel extends DataModel
function & _onExecute(&$param) のところは、
return $this->_OnInsert(&$param); となっているけれど、
return $this->_onInsert(&$param); が正しいという解釈で良いのですよね？
277nobodyさん
2008/02/07(木) 14:16:55ID:??? >>273-275
ソースのサンプルサンクス。
イメージしてたよりも継承が多いですね。
全体ソースコードの可読性よりも、クラス単位での
再利用性を考えた場合は、このような構成になる
のでしょうね。早く慣れないといけません。
ソースのサンプルサンクス。
イメージしてたよりも継承が多いですね。
全体ソースコードの可読性よりも、クラス単位での
再利用性を考えた場合は、このような構成になる
のでしょうね。早く慣れないといけません。
278nobodyさん
2008/02/07(木) 15:36:22ID:??? まだ中身が出来ていない状況なので、修正の必要はあるだろうけど、
こんな感じでドキュメントもまとめていくと、分かりやすくなるだろうね。
■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に書き込む。
こんな感じでドキュメントもまとめていくと、分かりやすくなるだろうね。
■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に書き込む。
279nobodyさん
2008/02/07(木) 23:22:51ID:??? >>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
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
281に ◆lKs5QMUHoA
2008/02/08(金) 08:04:01ID:??? せっかくプログラムを作っていただいたのだから、みんなでその説明文章をまとめるといいかもね。
例えば、こんな感じで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
例えば、こんな感じで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
283nobodyさん
2008/02/08(金) 08:52:15ID:??? 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を実装したつもりです・・・
有名なハリウッドの法則です。
[カプセル化]は良いとして、やはり[継承]と[ポリモーフィズム]を
うまく使うのは最初難しいかもしれない・・
これらの実装もデザパタとしてライブラリ化されたものに過ぎないけどね。
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を実装したつもりです・・・
有名なハリウッドの法則です。
[カプセル化]は良いとして、やはり[継承]と[ポリモーフィズム]を
うまく使うのは最初難しいかもしれない・・
これらの実装もデザパタとしてライブラリ化されたものに過ぎないけどね。
284nobodyさん
2008/02/08(金) 09:26:17ID:??? ファイルが見れん・・・
285nobodyさん
2008/02/08(金) 11:03:39ID:??? 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が反映されてませんでした。
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が反映されてませんでした。
286nobodyさん
2008/02/08(金) 11:20:06ID:??? サンクス
287nobodyさん
2008/02/08(金) 11:51:38ID:??? 全体構成の把握はまだ出来てないけれど、只今、ソース解析中・・・
いちゃもんつけるつもりじゃないけれど、気になった点を２つ。
Control.phpのPOSTされたSubmitボタン名取得のところは
クラス化されてないのはどうしてなのでしょうか？
さらに非常にクラスが多くなって面倒になるから？
class Control extends Base
var \$_view_calss;
このメンバはあえてclassにしてない理由はあるのでしょうか。
いちゃもんつけるつもりじゃないけれど、気になった点を２つ。
Control.phpのPOSTされたSubmitボタン名取得のところは
クラス化されてないのはどうしてなのでしょうか？
さらに非常にクラスが多くなって面倒になるから？
class Control extends Base
var \$_view_calss;
このメンバはあえてclassにしてない理由はあるのでしょうか。
288nobodyさん
2008/02/08(金) 12:39:56ID:??? >>287
POSTされたサブミットボタン名取得部分は説明の通りです・・
今その部分をC#でのデリゲートで実装しようと思ってます。
Viewクラスexecuteのところもこのままでは$eパラメータが
コントローラから任意に渡せないので検討中です。
オブジェクトにexecute以外のパブリックメソッドを
実装しないのが目標です・・(※アクセサ以外)
POSTされたサブミットボタン名取得部分は説明の通りです・・
今その部分をC#でのデリゲートで実装しようと思ってます。
Viewクラスexecuteのところもこのままでは$eパラメータが
コントローラから任意に渡せないので検討中です。
オブジェクトにexecute以外のパブリックメソッドを
実装しないのが目標です・・(※アクセサ以外)
289nobodyさん
2008/02/08(金) 13:12:48ID:??? クラスの継承関係が結構複雑になってますね。
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; // 書き込むファイル名
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; // 書き込むファイル名
290nobodyさん
2008/02/08(金) 13:15:33ID:??? ■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() →現在未実装。
●フィールド
$_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() →現在未実装。
291nobodyさん
2008/02/08(金) 13:32:42ID:??? こうやってみてみると、クラスを継承する際の設計思想が見えてくるな。
どの段階で実装を替えるかを考えた場合、どのクラスを置き換えれば良いかも分かる。
しかし、俺はこれまでフレームワークの構成などをじっくり読んだりしたことが無いので、
つい、ここまでクラスを継承させるメリットがあるのかなとか思ってしまう。
なんか、１つのメソッドを実装するのに、１回継承してるって感じだよね。
例えば、Model（抽象）クラスの $src_file_name を別のものにする場合、
それ以降のクラスが全部影響するかの確認が必要なわけだから、
Model（抽象）クラス以降のものをすべて一つのクラスにまとめて書いても
同じなんじゃないかと思えてしまう。
こういうのとは別な場面で、継承しているメリットがあるってことかな？
どの段階で実装を替えるかを考えた場合、どのクラスを置き換えれば良いかも分かる。
しかし、俺はこれまでフレームワークの構成などをじっくり読んだりしたことが無いので、
つい、ここまでクラスを継承させるメリットがあるのかなとか思ってしまう。
なんか、１つのメソッドを実装するのに、１回継承してるって感じだよね。
例えば、Model（抽象）クラスの $src_file_name を別のものにする場合、
それ以降のクラスが全部影響するかの確認が必要なわけだから、
Model（抽象）クラス以降のものをすべて一つのクラスにまとめて書いても
同じなんじゃないかと思えてしまう。
こういうのとは別な場面で、継承しているメリットがあるってことかな？
292nobodyさん
2008/02/08(金) 13:51:09ID:??? ちょっと紹介しておきますね。
フレームワークを使った開発のメリット、デメリットを教えてください
http://q.hatena.ne.jp/1188498291
特集：第1回 フレームワーク「Struts」の基礎を知る (3/8)
フレームワークのメリットとデメリット
http://www.itmedia.co.jp/enterprise/0310/06/epn03_3.html
フレームワークを使った開発のメリット、デメリットを教えてください
http://q.hatena.ne.jp/1188498291
特集：第1回 フレームワーク「Struts」の基礎を知る (3/8)
フレームワークのメリットとデメリット
http://www.itmedia.co.jp/enterprise/0310/06/epn03_3.html
293nobodyさん
2008/02/08(金) 15:31:59ID:??? Control の & _onExecute(&\$param, \$e) で
\$this->_view_calss = \$view_calss;
というコードがあるけれど、右辺の \$view_calss って、
何処でも定義されてないですよね？
このまま動かすと、nullが入るだけのように思えるんだけど。
\$this->_view_calss = \$view_calss;
というコードがあるけれど、右辺の \$view_calss って、
何処でも定義されてないですよね？
このまま動かすと、nullが入るだけのように思えるんだけど。
294nobodyさん
2008/02/08(金) 16:04:40ID:??? 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出力する。テキストボックスと送信ボタン
個別には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出力する。テキストボックスと送信ボタン
296nobodyさん
2008/02/08(金) 16:41:04ID:??? ロードメソッド[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
無い場合に呼ばれるメソッド）呼ばれるまでの経緯をたどってみたが、非常に複雑だ。。。
[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
297nobodyさん
2008/02/08(金) 17:33:12ID:??? リンク
symfony入門（1）：symfonyで始めるPHPフレームワーク
http://codezine.jp/a/article/aid/704.aspx?p=1
Zend Framework入門（1）：フレームワークの全体像とインストール
http://codezine.jp/a/article/aid/1824.aspx?p=1
symfony入門（1）：symfonyで始めるPHPフレームワーク
http://codezine.jp/a/article/aid/704.aspx?p=1
Zend Framework入門（1）：フレームワークの全体像とインストール
http://codezine.jp/a/article/aid/1824.aspx?p=1
299nobodyさん
2008/02/08(金) 19:33:52ID:??? >>298 見れるはずですが・・以下はどうですか？
Eclipceでのデバッグ画面です
ttp://proxy.f3.ymdb.yahoofs.jp/bc/4525b767_dfac/bc/452a/OOPFW_DEBUG.jpg?BC3YDrHBI.a6ljXl
Eclipceでのデバッグ画面です
ttp://proxy.f3.ymdb.yahoofs.jp/bc/4525b767_dfac/bc/452a/OOPFW_DEBUG.jpg?BC3YDrHBI.a6ljXl
301nobodyさん
2008/02/08(金) 22:24:55ID:??? なんでPHP4文法でやってんの？
303に ◆lKs5QMUHoA
2008/02/09(土) 01:49:09ID:??? これは、>>1さんのサイトでは、「入力フォームを作ってみる」とは
別で、「フレームワークを作ってみる」の演習という位置づけにした
方がいいかもしれないね。
これからの流れとしては、上のほうにあるように、このソースを
解読・改変していくための補助ドキュメント作成の方向と、
このフレームワークを使ってみる人のためのドキュメント作成
（チュートリアルみたいなもの）になるだろうね。
出来る範囲でみんなで手伝っていってみましょう。
このフレームワークは、MFCみたく、あらかじめ準備された
クラスのメソッド中に書き加えていくスタイルなのかな？
それとも、VBみたいにそういうソースコードを全部隠蔽
してしまう方向でいくのかな？ちょっと気になった。
別で、「フレームワークを作ってみる」の演習という位置づけにした
方がいいかもしれないね。
これからの流れとしては、上のほうにあるように、このソースを
解読・改変していくための補助ドキュメント作成の方向と、
このフレームワークを使ってみる人のためのドキュメント作成
（チュートリアルみたいなもの）になるだろうね。
出来る範囲でみんなで手伝っていってみましょう。
このフレームワークは、MFCみたく、あらかじめ準備された
クラスのメソッド中に書き加えていくスタイルなのかな？
それとも、VBみたいにそういうソースコードを全部隠蔽
してしまう方向でいくのかな？ちょっと気になった。
304に ◆lKs5QMUHoA
2008/02/09(土) 02:12:22ID:??? こうやってソースを読んでみると、これまで抽象的に聞いていた
フレームワークを使ったプログラミングのメリットとデメリットが実感できるね。
今まで、システムを組む際はOOPやフレームワークを使う方向にするべきだと
思ってたけれど、そうでもなく、状況や目的に合わせて選択する
というのが良い事が分かってきたような気がする。
小規模で全体概要を把握したいとか、移植性を考える場合は、フレームワークよりも、
クラスライブラリを使うスタイルの方が良い場合もありそうだ。
フレームワークを使ったプログラミングのメリットとデメリットが実感できるね。
今まで、システムを組む際はOOPやフレームワークを使う方向にするべきだと
思ってたけれど、そうでもなく、状況や目的に合わせて選択する
というのが良い事が分かってきたような気がする。
小規模で全体概要を把握したいとか、移植性を考える場合は、フレームワークよりも、
クラスライブラリを使うスタイルの方が良い場合もありそうだ。
305に ◆lKs5QMUHoA
2008/02/09(土) 08:12:13ID:??? MVCでフレームワークを自作する方向と、クラスライブラリを自作する方向の
２つの方向をやってみて、それぞれのメリットとデメリットを確認していけば、
システムを作る場合の検討材料に出来ると思う。
何でもフルスクラッチしていき、なるべく依存性は無いようにし、（言語の
バージョンくらいに収めるとか）その組み合わせでアプリを作る、みたいな。
２つの方向をやってみて、それぞれのメリットとデメリットを確認していけば、
システムを作る場合の検討材料に出来ると思う。
何でもフルスクラッチしていき、なるべく依存性は無いようにし、（言語の
バージョンくらいに収めるとか）その組み合わせでアプリを作る、みたいな。
306nobodyさん
2008/02/09(土) 09:45:19ID:??? 再度リファクタしてみました。
ttp://briefcase.yahoo.co.jp/bc/oopfw
[Controlクラス]
・リクエストオブジェクトの参照の重複の削除
・サブクラスでのフックハンドラ処理修正
・Viewオブジェクトの実行方法修正
※これはViewオブジェクトハンドリングの自由度をました反面、
ユーザからの取り回しが煩雑になったかもしれませんね・・
[Modelクラス]
・継承関係の見直し、ItemBaseクラスの導入などです・・
MVCの継承関係が美しくないですが・・
>>291
リファクタしながら構成を練っていってますが
継承クラスでの責任が小さい単位で分割されていると
大きく修正が入った時も楽だと思います。
>>303
MFCもVB6もフックハンドラに処理を記述していく方式なので
それを参考にしています、サンプルFWも自由にいじってもらって
参考にしてもらえたら良いと思います。
>>305クラスライブラリ方式もいいかもしれないですね。
ttp://briefcase.yahoo.co.jp/bc/oopfw
[Controlクラス]
・リクエストオブジェクトの参照の重複の削除
・サブクラスでのフックハンドラ処理修正
・Viewオブジェクトの実行方法修正
※これはViewオブジェクトハンドリングの自由度をました反面、
ユーザからの取り回しが煩雑になったかもしれませんね・・
[Modelクラス]
・継承関係の見直し、ItemBaseクラスの導入などです・・
MVCの継承関係が美しくないですが・・
>>291
リファクタしながら構成を練っていってますが
継承クラスでの責任が小さい単位で分割されていると
大きく修正が入った時も楽だと思います。
>>303
MFCもVB6もフックハンドラに処理を記述していく方式なので
それを参考にしています、サンプルFWも自由にいじってもらって
参考にしてもらえたら良いと思います。
>>305クラスライブラリ方式もいいかもしれないですね。
307nobodyさん
2008/02/09(土) 10:20:45ID:??? フレームワークのメリットとデメリットにおいて、なるべく具体例を書いた形でまとめてみた。
【メリット】
１．ビューとロジックの切り分けが出来る。（共同作業時に便利）
http://www.atmarkit.co.jp/fdotnet/aspandvs/aspandvs01/aspandvs01_01.html
２．定型的なコードを何度も書かなくてよくなる。
例えば、ASP.NETでは、POSTの値を取得して・・・などの事を考えなくて良い。
テキストボックスやボタンも、画面にドラッグするだけ。
３．ソースコードが自動的にフレームワークの規約に従った記述方法となり、
全体的な処理構成が把握しやすく、メンテナンスが楽になる。
例えば、構造化プログラミングならば、まず全体構成（どの関数がどんな役割を
持っているかなど）を把握し、そこから問題部分を探すことになる。
フレームワークの場合は、まずはこのイベントハンドラの部分を見れば良いなという事が分かる。
【デメリット】
１．フレームワーク自体の使い方を学ばなければならない。
・言語の基本ルールとは異なった、フレームワーク特有の記述方法があるため、すぐに組めない。
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
２．フレームワーク自体に問題があると対処が困難。
例えば.NET Framework のバグは、開発元の不具合修正を待つしかない。
オープンソースのフレームワークであっても、ソースコードが大量な為、把握が出来ない。
【メリット】
１．ビューとロジックの切り分けが出来る。（共同作業時に便利）
http://www.atmarkit.co.jp/fdotnet/aspandvs/aspandvs01/aspandvs01_01.html
２．定型的なコードを何度も書かなくてよくなる。
例えば、ASP.NETでは、POSTの値を取得して・・・などの事を考えなくて良い。
テキストボックスやボタンも、画面にドラッグするだけ。
３．ソースコードが自動的にフレームワークの規約に従った記述方法となり、
全体的な処理構成が把握しやすく、メンテナンスが楽になる。
例えば、構造化プログラミングならば、まず全体構成（どの関数がどんな役割を
持っているかなど）を把握し、そこから問題部分を探すことになる。
フレームワークの場合は、まずはこのイベントハンドラの部分を見れば良いなという事が分かる。
【デメリット】
１．フレームワーク自体の使い方を学ばなければならない。
・言語の基本ルールとは異なった、フレームワーク特有の記述方法があるため、すぐに組めない。
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
２．フレームワーク自体に問題があると対処が困難。
例えば.NET Framework のバグは、開発元の不具合修正を待つしかない。
オープンソースのフレームワークであっても、ソースコードが大量な為、把握が出来ない。
308nobodyさん
2008/02/09(土) 11:01:52ID:??? ＱＡ方式で書いてみた。
Ｑ：どんな時にフレームワークを使った方がいいの？
・短期間で仕上げなければならない時（この場合はフレームワークの使い方を把握しているのが前提）
・チームで分担してシステムを組む時
・バージョンアップを行うなど、長期的な運用が想定される時
Ｑ：フレームワークがあまり向かない場合は？
・個人で小規模アプリを組む時。（一度組んで終わりの場合など）
・そのアプリの全体構成をすみずみまで把握しておきたい場合
・サーバの移植を想定しなければならないなど、環境があまり固定出来ない場合
このような状況の場合は、クラスライブラリの使用を検討すると良い。
Ｑ：どんな時にフレームワークを使った方がいいの？
・短期間で仕上げなければならない時（この場合はフレームワークの使い方を把握しているのが前提）
・チームで分担してシステムを組む時
・バージョンアップを行うなど、長期的な運用が想定される時
Ｑ：フレームワークがあまり向かない場合は？
・個人で小規模アプリを組む時。（一度組んで終わりの場合など）
・そのアプリの全体構成をすみずみまで把握しておきたい場合
・サーバの移植を想定しなければならないなど、環境があまり固定出来ない場合
このような状況の場合は、クラスライブラリの使用を検討すると良い。
309nobodyさん
2008/02/09(土) 11:18:48ID:??? 何かフレームワークを使ったとして、そのフレームワークがいつまでメンテされるか
判らないことを考えると、バージョンアップをするようなアプリの開発に向いていると
いえるかどうかは、かなり怪しいと思う。
判らないことを考えると、バージョンアップをするようなアプリの開発に向いていると
いえるかどうかは、かなり怪しいと思う。
310nobodyさん
2008/02/09(土) 11:25:52ID:??? >>309
そういうケースもあるから入れるか迷ったんだよね・・・
だけど、現在の比較的規模の大きなアプリは何らかのフレームワークで
組まれている事実があるということで、書いてみた。
フレームワークのメンテが突然打ち切られるケースは無いと見ても
良いと思うけどね。事前に何らかのアナウンスがあるはず。
で、フレームワークそのものを入替える必要が生じた時は、もちろん
全部作り直しになるが、この労力は、フレームワークを使わない場合に
比べて楽だよね。という意見です。
そういうケースもあるから入れるか迷ったんだよね・・・
だけど、現在の比較的規模の大きなアプリは何らかのフレームワークで
組まれている事実があるということで、書いてみた。
フレームワークのメンテが突然打ち切られるケースは無いと見ても
良いと思うけどね。事前に何らかのアナウンスがあるはず。
で、フレームワークそのものを入替える必要が生じた時は、もちろん
全部作り直しになるが、この労力は、フレームワークを使わない場合に
比べて楽だよね。という意見です。
311nobodyさん
2008/02/09(土) 12:20:07ID:??? 書いてみた、とかって適当かつ無責任な
312nobodyさん
2008/02/09(土) 12:23:25ID:??? 完璧な文章がいきなりかけるわけないんだから修正しながらでいいと思う。
適当だの無責任だのいうのなら、このスレに来なくて良いと思う。
適当だの無責任だのいうのなら、このスレに来なくて良いと思う。
313nobodyさん
2008/02/09(土) 12:32:04ID:??? ひょっとして、つられた？
314nobodyさん
2008/02/09(土) 15:20:46ID:??? つんでれた
315nobodyさん
2008/02/09(土) 15:25:19ID:??? >>308
> Ｑ：フレームワークがあまり向かない場合は？
> ・そのアプリの全体構成をすみずみまで把握しておきたい場合
全体構成を隅々まで把握してなんの意味があるのだろうか？
どうせ数日たったら忘れるんだし。
> ・サーバの移植を想定しなければならないなど、環境があまり固定出来ない場合
> このような状況の場合は、クラスライブラリの使用を検討すると良い。
PHP4、PHP5両対応のフレームワークもあるし、
いろんなデータベースに対応している場合もある。
フレームワークの開発というのは、そもそもが環境が固定されていないので
そういう場合にはなおさらフレームワークを使ったほうが良い。
> Ｑ：フレームワークがあまり向かない場合は？
> ・そのアプリの全体構成をすみずみまで把握しておきたい場合
全体構成を隅々まで把握してなんの意味があるのだろうか？
どうせ数日たったら忘れるんだし。
> ・サーバの移植を想定しなければならないなど、環境があまり固定出来ない場合
> このような状況の場合は、クラスライブラリの使用を検討すると良い。
PHP4、PHP5両対応のフレームワークもあるし、
いろんなデータベースに対応している場合もある。
フレームワークの開発というのは、そもそもが環境が固定されていないので
そういう場合にはなおさらフレームワークを使ったほうが良い。
316nobodyさん
2008/02/09(土) 15:29:20ID:??? 理解と記憶は別物だと思うけどな。
317nobodyさん
2008/02/09(土) 16:52:42ID:??? >>315
> 全体構成を隅々まで把握してなんの意味があるのだろうか？
> どうせ数日たったら忘れるんだし。
じゃ、この項目は消しておきます。
> PHP4、PHP5両対応のフレームワークもあるし、
> いろんなデータベースに対応している場合もある。
> フレームワークの開発というのは、そもそもが環境が固定されていないので
> そういう場合にはなおさらフレームワークを使ったほうが良い。
PHPスレで言うのもなんだけど、ASP.NETなども含めた総論という考えだったんだけどね。
Windowsサーバなのかなどを気にするとか、PHP5のみ対応のフレームワークで
開発していて、PHP4しか対応していないサーバで動かすことになる場合を
という意味で、環境が固定されない書きました。
> 全体構成を隅々まで把握してなんの意味があるのだろうか？
> どうせ数日たったら忘れるんだし。
じゃ、この項目は消しておきます。
> PHP4、PHP5両対応のフレームワークもあるし、
> いろんなデータベースに対応している場合もある。
> フレームワークの開発というのは、そもそもが環境が固定されていないので
> そういう場合にはなおさらフレームワークを使ったほうが良い。
PHPスレで言うのもなんだけど、ASP.NETなども含めた総論という考えだったんだけどね。
Windowsサーバなのかなどを気にするとか、PHP5のみ対応のフレームワークで
開発していて、PHP4しか対応していないサーバで動かすことになる場合を
という意味で、環境が固定されない書きました。
318nobodyさん
2008/02/09(土) 17:04:40ID:??? 修正案
Ｑ：どんな時にフレームワークを使った方がいいの？
・短期間で仕上げなければならない時（この場合はフレームワークの使い方を把握しているのが前提）
・チームで分担してシステムを組む時
・バージョンアップや不具合修正など、納品後もメンテナンスが想定される時
Ｑ：フレームワークがあまり向かない場合は？
・個人で小規模アプリを組む時。（一度組んで終わりの場合など）
・サーバの移植を想定しなければならないなど、環境があまり固定出来ない場合
このような状況の場合は、クラスライブラリの使用を検討すると良い。
Ｑ：どんな時にフレームワークを使った方がいいの？
・短期間で仕上げなければならない時（この場合はフレームワークの使い方を把握しているのが前提）
・チームで分担してシステムを組む時
・バージョンアップや不具合修正など、納品後もメンテナンスが想定される時
Ｑ：フレームワークがあまり向かない場合は？
・個人で小規模アプリを組む時。（一度組んで終わりの場合など）
・サーバの移植を想定しなければならないなど、環境があまり固定出来ない場合
このような状況の場合は、クラスライブラリの使用を検討すると良い。
319nobodyさん
2008/02/09(土) 22:32:17ID:??? あえてPHP4の構文でやってるのは、PHP4との互換性を保つため？
PHP5でやっちゃうと、PHP4の環境で動かなくなるから。
PHP5でやっちゃうと、PHP4の環境で動かなくなるから。
320に ◆lKs5QMUHoA
2008/02/10(日) 03:19:14ID:??? ChStrクラスの件を再開しようかな。
3211 ◆SWtzLesEmM
2008/02/10(日) 18:45:04ID:??? >>300
>ttp://briefcase.yahoo.co.jp/bc/oopfw
ソースコードを見てビックリ！(・∀・)
コメントが丁寧に書いてあり、OOPを学習する上でとても助かります！
貴重なサンプルを提供していただき、どうもありがとうございました。m(_~_)m
現時点で、バージョンがOOP_FW_02とOOP_FW_03の２つあるみたいですが、とりあえずOOP_FW_02の方をまとめページに掲載させていただきました。
http://ssurl.net/8vyv
>>281
http://ssurl.net/cp7a
ちょっとずつ読んでますが、全部はまだ理解できないです。(´；ω；｀)
レスも参考にしてみます。
（＝分からないことでも、検索で調べるときのヒント・手掛かりになるので）
>ttp://briefcase.yahoo.co.jp/bc/oopfw
ソースコードを見てビックリ！(・∀・)
コメントが丁寧に書いてあり、OOPを学習する上でとても助かります！
貴重なサンプルを提供していただき、どうもありがとうございました。m(_~_)m
現時点で、バージョンがOOP_FW_02とOOP_FW_03の２つあるみたいですが、とりあえずOOP_FW_02の方をまとめページに掲載させていただきました。
http://ssurl.net/8vyv
>>281
http://ssurl.net/cp7a
ちょっとずつ読んでますが、全部はまだ理解できないです。(´；ω；｀)
レスも参考にしてみます。
（＝分からないことでも、検索で調べるときのヒント・手掛かりになるので）
322nobodyさん
2008/02/10(日) 22:19:07ID:???323に ◆lKs5QMUHoA
2008/02/11(月) 02:31:35ID:???324に ◆lKs5QMUHoA
2008/02/11(月) 02:35:18ID:??? MVCフレームワークを作っていただいてる流れとはおもいっきり違う事をいうけれど。
>>1さんのOOPで掲示板を作るところは、もう少しクラスを分けたほうが
いいと思ったので、自分なりに作ってみました。
index.phpに、いろいろと処理を詰め込んでいるような感があったので、
それを分ける考え方です。
しかし、DBはテキストベースにしているとか、書き込み欄と表示欄を
同じページにしているなど、基本構成から大幅に変えています。（＾＾；
http://www.geocities.jp/narutobakijp2/
OOPの勉強として、簡易なBBSを作ってみました。
BBS Version1(2008.2.11)
>>1さんのOOPで掲示板を作るところは、もう少しクラスを分けたほうが
いいと思ったので、自分なりに作ってみました。
index.phpに、いろいろと処理を詰め込んでいるような感があったので、
それを分ける考え方です。
しかし、DBはテキストベースにしているとか、書き込み欄と表示欄を
同じページにしているなど、基本構成から大幅に変えています。（＾＾；
http://www.geocities.jp/narutobakijp2/
OOPの勉強として、簡易なBBSを作ってみました。
BBS Version1(2008.2.11)
325に ◆lKs5QMUHoA
2008/02/11(月) 08:27:05ID:??? クラス間のデータのやり取りにおいて、Listクラスを使う設計にしたけれど、
PHPの場合はハッシュでよかったような気がする件。
まだまだ未熟だな・・・
今後は、これを構造化指向へ変換したプログラムを作り、うｐする予定です。
この両方のプログラムを見比べてみることで、OOPのメリットとデメリットが
見えてくるかもしれません。
PHPの場合はハッシュでよかったような気がする件。
まだまだ未熟だな・・・
今後は、これを構造化指向へ変換したプログラムを作り、うｐする予定です。
この両方のプログラムを見比べてみることで、OOPのメリットとデメリットが
見えてくるかもしれません。
326nobodyさん
2008/02/11(月) 10:26:11ID:??? OOPの継承やポリモーフィズムについての概念やそのコードの書き方に
ついては分かったけれど、その設計方法のノウハウの文章はぐぐっても
なかなか見当たらない。
「設計というのはそれぞれで目的次第」といってしまえばそうだけど、
hiroxpepeさんのソースや、.NET Framework や java の各クラスの
継承関係の設計を見ていると、何か共通したものを感じる。
その具体的な方針と、それを取る理由がはっきりとは分からない・・・
何か良い文章を見かけた、もしくは知っている方は、お願いします。
ついては分かったけれど、その設計方法のノウハウの文章はぐぐっても
なかなか見当たらない。
「設計というのはそれぞれで目的次第」といってしまえばそうだけど、
hiroxpepeさんのソースや、.NET Framework や java の各クラスの
継承関係の設計を見ていると、何か共通したものを感じる。
その具体的な方針と、それを取る理由がはっきりとは分からない・・・
何か良い文章を見かけた、もしくは知っている方は、お願いします。
327nobodyさん
2008/02/11(月) 10:50:14ID:??? ◎「メンテナンスを行う場合」の比較
【構造化指向の場合】
ソースコードに書かれている関数とグローバル変数が、どういう階層で組まれているか
（どの関数でどの関数が使われているか。また、どのグローバル変数を使っているのか）
は、その関数の処理内容と、その関係などを把握してからでないと、手をつけられない。
新しくグローバル変数や、関数を追加する場合。また、ローカル変数を宣言する場合は、
その名前がソースコード内で使われているかを都度チェックしなければならないので、
面倒である。
【オブジェクト指向の場合】
ソースコードそのものがクラス単位で分けられているため、手をつける場所がすぐに
分かる。他のクラスに影響するのは、そのクラスとのインターフェースを変更した場合のみ。
新しくメンバやメソッドを追加する場合は、そのクラスの中で使われているメンバや
メソッドを確認するだけなので、対象となる範囲が狭く、チェックが楽。
また、プログラムそのものがクラスで部品化されるため、チームを組んで、分担作業で
プログラミングがやり易い。
【注意】
構造化プログラミングであっても、関数やグローバル変数の名前の付け方を工夫すれば、
もちろん対応は可能である。そのため、メンテナンスを想定する場合は、
オブジェクト指向でなければならないわけでもない。
オブジェクト指向は、構造化指向に比べて特別に「これが出来る」というものではなく、
構造化指向で不便に感じる部分の便利機能である。
【構造化指向の場合】
ソースコードに書かれている関数とグローバル変数が、どういう階層で組まれているか
（どの関数でどの関数が使われているか。また、どのグローバル変数を使っているのか）
は、その関数の処理内容と、その関係などを把握してからでないと、手をつけられない。
新しくグローバル変数や、関数を追加する場合。また、ローカル変数を宣言する場合は、
その名前がソースコード内で使われているかを都度チェックしなければならないので、
面倒である。
【オブジェクト指向の場合】
ソースコードそのものがクラス単位で分けられているため、手をつける場所がすぐに
分かる。他のクラスに影響するのは、そのクラスとのインターフェースを変更した場合のみ。
新しくメンバやメソッドを追加する場合は、そのクラスの中で使われているメンバや
メソッドを確認するだけなので、対象となる範囲が狭く、チェックが楽。
また、プログラムそのものがクラスで部品化されるため、チームを組んで、分担作業で
プログラミングがやり易い。
【注意】
構造化プログラミングであっても、関数やグローバル変数の名前の付け方を工夫すれば、
もちろん対応は可能である。そのため、メンテナンスを想定する場合は、
オブジェクト指向でなければならないわけでもない。
オブジェクト指向は、構造化指向に比べて特別に「これが出来る」というものではなく、
構造化指向で不便に感じる部分の便利機能である。
328nobodyさん
2008/02/11(月) 10:57:47ID:??? >>324,325
なかなか参考になりました、ありがとう。
326さんのおっしゃる通り、"設計"は経験なんかも必要になってくるので、
考えるよりも手を動かして、簡単なスクリプトを組んでみるのが最良でしょうか。
なかなか参考になりました、ありがとう。
326さんのおっしゃる通り、"設計"は経験なんかも必要になってくるので、
考えるよりも手を動かして、簡単なスクリプトを組んでみるのが最良でしょうか。
329nobodyさん
2008/02/11(月) 12:43:38ID:??? >>326
・リファクタリング―プログラムの体質改善テクニック
マーチン ファウラー著
高いけどOOPに興味のある方には絶対お勧めですよ。
ポリモーフィズム適用の具体例がコードで解説されていますよ。
構造化プログラミングではGOTO構文を使うのはNGだけど
同様にOOPではswitch構文を使用しません。
ここの部分をポリモーフィズムで実装するのです。
あなたのプログラムにswitch構文がありますか？
その部分はポリモーフィズムで置き換えられますよ。
・リファクタリング―プログラムの体質改善テクニック
マーチン ファウラー著
高いけどOOPに興味のある方には絶対お勧めですよ。
ポリモーフィズム適用の具体例がコードで解説されていますよ。
構造化プログラミングではGOTO構文を使うのはNGだけど
同様にOOPではswitch構文を使用しません。
ここの部分をポリモーフィズムで実装するのです。
あなたのプログラムにswitch構文がありますか？
その部分はポリモーフィズムで置き換えられますよ。
330nobodyさん
2008/02/11(月) 12:53:28ID:??? >同様にOOPではswitch構文を使用しません。
>ここの部分をポリモーフィズムで実装するのです。
これは言いすぎ。
OOの基本はモデリングであって、コーディングのスタイルじゃない。
>ここの部分をポリモーフィズムで実装するのです。
これは言いすぎ。
OOの基本はモデリングであって、コーディングのスタイルじゃない。
331nobodyさん
2008/02/11(月) 13:07:00ID:??? >>329
情報ありがとうございます。
> 構造化プログラミングではGOTO構文を使うのはNGだけど
> 同様にOOPではswitch構文を使用しません。
> ここの部分をポリモーフィズムで実装するのです。
> あなたのプログラムにswitch構文がありますか？
> その部分はポリモーフィズムで置き換えられますよ。
この表現はすごく分かりやすかったです。
こういう感じの具体的なノウハウがあると分かりやすいですね。
>>330
「言いすぎ」というご指摘もごもっともだと思います。
しかし、OOPは、構造化指向に比べてダントツで良い所があるわけでも
ないので、（このため、すべてがOOPに移項してはいない。）
良いところを説明する際は、多少は強調した感じで言わざるを
得ないところがあると思っています。
情報ありがとうございます。
> 構造化プログラミングではGOTO構文を使うのはNGだけど
> 同様にOOPではswitch構文を使用しません。
> ここの部分をポリモーフィズムで実装するのです。
> あなたのプログラムにswitch構文がありますか？
> その部分はポリモーフィズムで置き換えられますよ。
この表現はすごく分かりやすかったです。
こういう感じの具体的なノウハウがあると分かりやすいですね。
>>330
「言いすぎ」というご指摘もごもっともだと思います。
しかし、OOPは、構造化指向に比べてダントツで良い所があるわけでも
ないので、（このため、すべてがOOPに移項してはいない。）
良いところを説明する際は、多少は強調した感じで言わざるを
得ないところがあると思っています。
332nobodyさん
2008/02/11(月) 13:39:48ID:??? >>330
そうですね、確かに言い過ぎました・・
GOTO構文は習いませんでしたが、switch構文は習得しちゃいました。
あえてそれを使用しないで組んでみるのも勉強になるのではないでしょうか？
構造化的スタイルとOOP的スタイルを手っ取り早く理解しようとするなら
それぐらいのパラダイムシフトが必要だと思うんです。
もちろんGOTO構文もswitch構文もコーディングには必要です。
そうですね、確かに言い過ぎました・・
GOTO構文は習いませんでしたが、switch構文は習得しちゃいました。
あえてそれを使用しないで組んでみるのも勉強になるのではないでしょうか？
構造化的スタイルとOOP的スタイルを手っ取り早く理解しようとするなら
それぐらいのパラダイムシフトが必要だと思うんです。
もちろんGOTO構文もswitch構文もコーディングには必要です。
333nobodyさん
2008/02/11(月) 15:01:11ID:??? switchがいらないということは、
if文もいらないな。
それともswitchを使わずに、
if文で書けばいいのかｗ
if文もいらないな。
それともswitchを使わずに、
if文で書けばいいのかｗ
334に ◆lKs5QMUHoA
2008/02/11(月) 18:07:43ID:??? >>328
（なんか、自分語りみたいなレスになっているけれど、
OOPの勉強方法についての意見交換にもなるかと思ったので書いておきます。）
私は、プログラミングをこれから勉強しようという時、「無駄・ムラ・無理なく
勉強する」という予備校の受験勉強の風潮を受けていましたので、先生に
「プログラミングを勉強する場合は、どんな風なやり方をしたら良いですか？」
とか「どんな順番で勉強をしていったら良いですか？」と聞いたことがあるのですが、
その先生は、「そんなことを考えている時間があるなら、その分コーディングを
した方が良い」とアドバイスをしました。
実際に手を動かしてやってみると、文章や口頭の説明では言えない、何か体感的な
ものが習得でき、その後の勉強方針もどうやったら良いのかが見えてきました。
「ああ、あの言葉は、こういう意味なんだな」と思いました。
プログラミングは、実技の世界なのだから、実際に手を動かしてみて見えてくるものだと
思っています。
過去に表計算をするプログラムを構造化指向で組むと、処理を関数に分けていく方法が
身についたなと思いました。なので、今度は、構造化指向で苦労をするプログラミングを
してみると、OOPの良さが見えてくるのでは、と思っています。
（なんか、自分語りみたいなレスになっているけれど、
OOPの勉強方法についての意見交換にもなるかと思ったので書いておきます。）
私は、プログラミングをこれから勉強しようという時、「無駄・ムラ・無理なく
勉強する」という予備校の受験勉強の風潮を受けていましたので、先生に
「プログラミングを勉強する場合は、どんな風なやり方をしたら良いですか？」
とか「どんな順番で勉強をしていったら良いですか？」と聞いたことがあるのですが、
その先生は、「そんなことを考えている時間があるなら、その分コーディングを
した方が良い」とアドバイスをしました。
実際に手を動かしてやってみると、文章や口頭の説明では言えない、何か体感的な
ものが習得でき、その後の勉強方針もどうやったら良いのかが見えてきました。
「ああ、あの言葉は、こういう意味なんだな」と思いました。
プログラミングは、実技の世界なのだから、実際に手を動かしてみて見えてくるものだと
思っています。
過去に表計算をするプログラムを構造化指向で組むと、処理を関数に分けていく方法が
身についたなと思いました。なので、今度は、構造化指向で苦労をするプログラミングを
してみると、OOPの良さが見えてくるのでは、と思っています。
335に ◆lKs5QMUHoA
2008/02/11(月) 18:16:42ID:??? BBSの構造化バージョンをうｐしました。
ttp://www.geocities.jp/narutobakijp2/index.html
OOPの勉強として、簡易なBBSを作ってみました。
BBS Version2(2008.2.11)入力したデータで改行に対応してなかったので、その部分を修正。
BBS Version2の構造化Ver(2008.2.11)上記プログラムの構造化バージョンです。
ttp://www.geocities.jp/narutobakijp2/index.html
OOPの勉強として、簡易なBBSを作ってみました。
BBS Version2(2008.2.11)入力したデータで改行に対応してなかったので、その部分を修正。
BBS Version2の構造化Ver(2008.2.11)上記プログラムの構造化バージョンです。
336nobodyさん
2008/02/12(火) 04:15:37ID:E8FcAvF5 そもそも起動したら即終了するようなPHPプログラミングにOOを使う必要性が感じられない。
337nobodyさん
2008/02/12(火) 09:16:19ID:??? ここは必要性を語るスレじゃないですよ
339nobodyさん
2008/02/12(火) 11:35:52ID:??? >>336じゃないけど、オブジェクトは状態を保存しておくものだから。
複雑なデータを持つオブジェクトを作っても、mod_phpはリクエストの度にプロセス生成・終了するわけで、そのオブジェクトも消える。
そもそもウェブアプリはユーザからのリクエストを受けて処理が発生しする構造だから、オブジェクトを永続化しておくことにあまり意味はない。
オブジェクト指向に興味があるなら、GUIのあるアプリケーションとか、ゲームとかを作ってみるとよいよ。
複雑なデータを持つオブジェクトを作っても、mod_phpはリクエストの度にプロセス生成・終了するわけで、そのオブジェクトも消える。
そもそもウェブアプリはユーザからのリクエストを受けて処理が発生しする構造だから、オブジェクトを永続化しておくことにあまり意味はない。
オブジェクト指向に興味があるなら、GUIのあるアプリケーションとか、ゲームとかを作ってみるとよいよ。
340nobodyさん
2008/02/12(火) 12:57:39ID:??? 永続化されていないオブジェクトには意味がほとんどないという主張ならば、どうだろうね。
Booch先生も、「永続性」に対して、「有用ではあるがオブジェクトモデルにとって
なくてはならない要素というわけではない」 って言ってるし。
(もう絶版だけど、Booch法第2版 2.2節より)
Booch先生も、「永続性」に対して、「有用ではあるがオブジェクトモデルにとって
なくてはならない要素というわけではない」 って言ってるし。
(もう絶版だけど、Booch法第2版 2.2節より)
341nobodyさん
2008/02/12(火) 13:17:09ID:??? >>336だけどphpはプロセスを生成してから破棄するまでに処理を1度しか行わない関数？が多いし、
イベントが非同期で発生したりするわけでもないからOOを使うのはどうかなー？って気がする。
だいたいフローチャートで処理書けちゃうしね。
あとデータベースなりファイルなりからデータを読み込んでそれをオブジェクトの形に整形して・・・・
って処理が無駄な気がする。
実際に行う処理よりもその整形処理が長かったりするとなんか本末転倒なような。
イベントが非同期で発生したりするわけでもないからOOを使うのはどうかなー？って気がする。
だいたいフローチャートで処理書けちゃうしね。
あとデータベースなりファイルなりからデータを読み込んでそれをオブジェクトの形に整形して・・・・
って処理が無駄な気がする。
実際に行う処理よりもその整形処理が長かったりするとなんか本末転倒なような。
342nobodyさん
2008/02/12(火) 13:23:42ID:??? >>341
>あとデータベースなりファイルなりからデータを読み込んでそれをオブジェクトの形に整形して・・・・
>って処理が無駄な気がする。
なるほど、それはそうだね。
いわゆるロジック的なものがほとんどない Webアプリってのは存在するし。（っていうか大半かも)
フレームワークでもなんでも、整理してるつもりで回りくどいだけってのは多い気がする。
話に付き合ってくれて、どうもありがと。
>あとデータベースなりファイルなりからデータを読み込んでそれをオブジェクトの形に整形して・・・・
>って処理が無駄な気がする。
なるほど、それはそうだね。
いわゆるロジック的なものがほとんどない Webアプリってのは存在するし。（っていうか大半かも)
フレームワークでもなんでも、整理してるつもりで回りくどいだけってのは多い気がする。
話に付き合ってくれて、どうもありがと。
343nobodyさん
2008/02/12(火) 14:28:33ID:??? > いわゆるロジック的なものがほとんどない Webアプリってのは存在するし。（っていうか大半かも)
どう考えても少数だろｗ
ロジック無しで何が作れるというんだ？ｗ
どう考えても少数だろｗ
ロジック無しで何が作れるというんだ？ｗ
344nobodyさん
2008/02/12(火) 14:34:01ID:??? > そもそもウェブアプリはユーザからのリクエストを受けて処理が発生しする構造だから、オブジェクトを永続化しておくことにあまり意味はない。
その理屈だと、PHPに限らず、JavaでもRubyでもオブジェクト指向は要らないということになるな。
それにアプリでも終了すると消えるわけで、結局はウェブアプリと同じ。
そもそもデータベースやファイルにデータを保存するのも
オブジェクトの保存・永続化なわけだが？
> あとデータベースなりファイルなりからデータを読み込んでそれをオブジェクトの形に整形して・・・・
> って処理が無駄な気がする。
> 実際に行う処理よりもその整形処理が長かったりするとなんか本末転倒なような。
だからフレームワーク使うんじゃん。
その理屈だと、PHPに限らず、JavaでもRubyでもオブジェクト指向は要らないということになるな。
それにアプリでも終了すると消えるわけで、結局はウェブアプリと同じ。
そもそもデータベースやファイルにデータを保存するのも
オブジェクトの保存・永続化なわけだが？
> あとデータベースなりファイルなりからデータを読み込んでそれをオブジェクトの形に整形して・・・・
> って処理が無駄な気がする。
> 実際に行う処理よりもその整形処理が長かったりするとなんか本末転倒なような。
だからフレームワーク使うんじゃん。
345nobodyさん
2008/02/12(火) 14:42:23ID:???347に ◆lKs5QMUHoA
2008/02/12(火) 18:36:45ID:??? >>341
> あとデータベースなりファイルなりからデータを読み込んでそれをオブジェクトの形に整形して・・・・
> って処理が無駄な気がする。
> 実際に行う処理よりもその整形処理が長かったりするとなんか本末転倒なような。
これはもともとOOPの特性じゃない？
再利用性や保守性を高めるために、他の処理とを完全に切り分ける代わりに、
構造化指向よりも、コード量が多く、動作が重くなるというのは。
これは、個人で組む小規模プログラムでは無駄でしかないが、チームで組んだり、
改変がある場合には威力を発揮する、という類のことでしょ。
> あとデータベースなりファイルなりからデータを読み込んでそれをオブジェクトの形に整形して・・・・
> って処理が無駄な気がする。
> 実際に行う処理よりもその整形処理が長かったりするとなんか本末転倒なような。
これはもともとOOPの特性じゃない？
再利用性や保守性を高めるために、他の処理とを完全に切り分ける代わりに、
構造化指向よりも、コード量が多く、動作が重くなるというのは。
これは、個人で組む小規模プログラムでは無駄でしかないが、チームで組んだり、
改変がある場合には威力を発揮する、という類のことでしょ。
348に ◆lKs5QMUHoA
2008/02/12(火) 18:50:13ID:??? 確かに私もWebアプリの世界ではOOPの意味は少ないと思う。
指摘にあるように、フローチャートがかけるような処理しかしていないので、
主にPerlやPHPで構造化指向でコーディングするスタイルが流行っているのだと思う。
（PerlやPHPのOOP対応は未だに不十分なところがある）
また、ネットにあるサンプルアプリは構造化指向のものが非常に多い事からも、
構造化指向で十分に組めることを意味しているのだと感じる。
通常だと、「だったら、WebアプリをOOPで組む必要ないよね。」となるわけだが、
私がそれでもあえてOOPをやっているのは、その有用性などを自分で体感する形で
確認したいからだ。
大規模なアプリとなると、WebアプリでもOOPを活用して組むことが多いと聞くが、
それは具体的にどのような場面で、どのような有用性があるからなのか。それらを確認したい。
最近は、どうも（Webアプリの世界では）OOPの有用性を見るよりも、
各種フレームワークの有用性を確認した方が良いのでは、と感じている。
指摘にあるように、フローチャートがかけるような処理しかしていないので、
主にPerlやPHPで構造化指向でコーディングするスタイルが流行っているのだと思う。
（PerlやPHPのOOP対応は未だに不十分なところがある）
また、ネットにあるサンプルアプリは構造化指向のものが非常に多い事からも、
構造化指向で十分に組めることを意味しているのだと感じる。
通常だと、「だったら、WebアプリをOOPで組む必要ないよね。」となるわけだが、
私がそれでもあえてOOPをやっているのは、その有用性などを自分で体感する形で
確認したいからだ。
大規模なアプリとなると、WebアプリでもOOPを活用して組むことが多いと聞くが、
それは具体的にどのような場面で、どのような有用性があるからなのか。それらを確認したい。
最近は、どうも（Webアプリの世界では）OOPの有用性を見るよりも、
各種フレームワークの有用性を確認した方が良いのでは、と感じている。
レスを投稿する
ニュース
- 【W杯】韓国が大窮地 悪夢のシナリオ止まらず 決勝Ｔ進出順位ボーダーの８位に転落 セネガル、イランに抜かれる ★4 [尺アジ★]
- 【本】ヘルシーに見えて､｢薄毛｣リスクが上昇…専門医が｢血流の大敵｣と名指しする日本人が大好きな”白い食べ物” [少考さん★]
- 【芸能】田中みな実、実名告白「めっちゃ格好いい」「インスタもフォローした」 Ｗ杯日本代表にメロメロも「狙ってないからね？」 [冬月記者★]
- 【自維】鮭おにぎり198円に絶望、コンビニすら遠い存在に…「生き延びられない」物価高で広がる生活苦★5 [ひぃぃ★]
- 【サッカー】「昔のネイマールでしょ」サッカー日本代表・塩貝健人がブラジル戦へ痛快発言…「王国」の印象を問われ [ゴアマガラ★]
- 【サッカー】「世紀の談合マッチになる予感」Ｊ組の一戦が話題…ドローで両チーム決勝T進出の“異例事態” [ゴアマガラ★]
- 【高市朗報】専守防衛の日本、無人潜水艦導入へ！魚雷や機雷を搭載し長距離､長時間運用｡ＡＩ搭載し自律型も。乗っ取られないようにしてね [219241683]
- 【高市悲報】「みんなで大家さん」持ってる中で一番価値がある宗右衛門町の駐車場、500人以上の人に仮差し押さえられた模様🥹 [616817505]
- 経団連「年内には訪中して習主席と面会したい😢レアアースもタングステンももう限界😢」 [931948549]
- 土曜プレミアム・世にも奇妙んな物語’26夏の特別編🏡
- 【高市悲報】アンソロピック、ミュトスを提供再開。ただし日本は対象外 [663382246]
- 俺が反日になった理由が深すぎるｗｗ