PHPでOOP

1 ◆SWtzLesEmM · 2007/02/23(金) 13:35:52

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^)／

に ◆lKs5QMUHoA · 2008/02/05(火) 01:28:01

>>247
レスありがとうございます。
> 構造化プログラミングはルーチンを呼ぶ方向で実装すると思うけど
> OOPではルーチンに呼ばれる方向で実装して行く感じだよ。
私は、継承を活かした設計をした事が無かったので、ちょっと方向性を
誤ってしまったようですね。

Viewは、表示をつかさどるのだから、html表示を請け負うのでは、と
思っていたのですが、それよりも抽象的な枠組みを定義するという
ことですね。

となると、html表示は（PEARを使わないのであれば、）htmlタグの
記述を行うCF_HTMLクラスを作り、Viewの具象クラス内で
インスタンスを生成ということですよね？

**nobodyさん** · 2008/02/05(火) 08:55:19

>>248
HTML処理のヘルパクラス作成はあまりOOPの勉強にならないとも思うんだ。
もう既に頭の中で実装出来ているだろうし、引数を関数で処理するだけでしょ？

それよりも例えばPEARのHTML_QuickFormやテンプレートレンダラのSmartyを
Viewと連携させる仕組みとかを考えたりした方がよっぽど面白いよ。

すべてをフルスクラッチするプログラミングの方向性は必ずしも得策じゃないよ
既存のライブラリやコンポーネントを上手く利用するのもOOPの要素なんだよ。

**nobodyさん** · 2008/02/05(火) 11:06:34

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

**nobodyさん** · 2008/02/05(火) 11:52:25

>>250
PHPのプログラマにも非常に参考になると思いますよ。

.NETの世界はクラスベースなので初めからOOPの思考で実装します。
関数が作れないので構造化思考のVB6プログラマとか、クラスをnewせずに
引数を大量に渡すスタティックメソッドを呼んだりしてしまいます・・・

PHPはC言語での関数モジュールを呼び出す実装スタイルに近いので
やはりクラスを使って構造化プログラミングをしちゃいがちですね。

普及しているPHP4がOOP対応不十分なのと、開発環境が貧弱であることも
PHPでOOPがなかなか利用されない原因になってたりしますよね。

プロテクテッドメソッドの概念とかIDEがないと、なんでそうするのか
なかなか理解出来ないとも思いますしね。

**nobodyさん** · 2008/02/05(火) 11:56:50

いくらかのデータを登録し、その内容を検索するWebシステムで使用する
クラス構成で、Viewに絞った構成を考えてみた。

[View]
├[認証]
├[個人情報入力]
├[メニュー]
├[検索指定]
├[検索結果]

別の案として、[View]から[Input View]と[Output View]の
二つを継承し、さらに以下のような継承も浮かんだけれど、
継承して分ける必要性は無さそうなので、上記の方が良いように思う。

[Input View]
├[認証]
├[個人情報入力]

[Output View]
├[メニュー]
├[検索指定]
├[検索結果]

**nobodyさん** · 2008/02/05(火) 12:16:06

>>252
[View]
├[LoginView]
├[InsertView]
├[MenuView]
├[SelectView]
├[ResultView]

こんな感じ？

**nobodyさん** · 2008/02/05(火) 13:28:44

Debug用出力のメソッドをView（基底クラス）に追加するといいだろうね。
各画面（[LoginView] [InsertView] [MenuView] ・・・）で
エラー確認用のメソッドをオーバーロードする形で。
開発中はPOSTで受け取ったデータとかを画面上部に表示しながら動作確認する
っていうのは、よくやるからね。

Objectクラスを継承する形にするのは、このスレでは共通したメソッドの
実装という理由だ。という話だったけど、リファレンス関係の処理で
便利だという話がサイトに載っているようだね。
このあたりの考え方も活かすと良いかもしれない。
ただ、PHPのOOPだとうまく実装出来ないかもしれないが。
>>207-209 >>250

**nobodyさん** · 2008/02/05(火) 13:44:31

Modelクラスも以下のメソッドを追加するという感じで設計すると良いのかな。

Select // データ取り出し
Delete // 削除
Insert // 新規追加
Update // 既存データの更新

>>228に載ってる既存のクラスには Execute があるけれど、
これも残しておくべきかな？

に ◆lKs5QMUHoA · 2008/02/05(火) 19:03:57

案がいくつか出てきたので、前回の駄目なソースを破棄して
またソースコードをリニューアルしようかと思ったが、
いざやり始めてみると、データベースを管理する基底クラスの
設計を具体的にどうするかをきめないといけなくなり、それを
どうするかで迷っている。。。

概ね以下のような感じにしたいと思ってるんだけどね。
DB格納の基底クラス：CFDB
テキストファイルに保存するクラス：Text_DB extend CFDB
PostgreSQLに保存するクラス：PostgreSQL_DB extend CFDB
MySQLに保存するクラス：MySQL_DB extend CFDB

で、この３つのいずれかのインスタンスを Model のメンバに持たせる。
現在のコード（CFModelのメンバ）
var $file_name; // 読み込むファイル名
更新案のコード
var $m_db; // データベースを格納。

**nobodyさん** · 2008/02/05(火) 20:33:23

>>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のアプリ作成に必要な要求仕様作ってよ。

に ◆lKs5QMUHoA · 2008/02/05(火) 23:02:08

>>257
要求仕様案

私は眼鏡屋（○○支店の店長）をやっている。
顧客の情報（名前、住所、性別、生年月日、・・・）を管理したい。

・眼鏡を購入した顧客の情報を登録しておき、ある一定期間経つと
新しい眼鏡を購入する案内のＤＭを発送したい。
→条件検索をしたい。
・登録した情報を検索し、どんなお客様かをすぐに確認出来るようにする。
→例えば、苗字を聞いて、詳細が分かるようにする。
・眼鏡の定期的なメンテナンスで、訪問してきたら、その対応履歴を
登録しておきたい。
→眼鏡のクリーニング、シリコンパッド（鼻にあてるやつ）の交換など
・定期的なメンテナンスは無料であるので、全く店に来ない客には、
その無料案内のＤＭを発送したい。
→今回は、複数の店舗にまたがった処理はいらない。
・他の社員に勝手に情報を触られないように、認証を通すようにする。

眼鏡の在庫管理は、このシステムとは別。

これは、プログラムの規模が大きくなりすぎるようであれば、
もちろん内容を変えてもいいです。「顧客の情報を登録し、
それを検索する」という流れだと、勉強用サンプルとして非常に
良いのでは、と思いました。

に ◆lKs5QMUHoA · 2008/02/05(火) 23:21:24

[データの入力例]
氏名：茂名
フリガナ：モナー
性別：男性
生年月日：H1/3/3
住所：東京都・・・
コメント：ふちなしタイプを希望している。

眼鏡購入日：2007/1/5
眼鏡の型番：2ch

[2007/1/5に購入した2ch]のメンテナンス履歴
2007/2/5：クリーニング
2007/3/15：ネジの交換
2007/5/1：クリーニング、曲がったフレームの修正

顧客のデータ１件に、眼鏡の購入日がつながり、さらに、メンテナンス履歴が
つながる構成になるけれど、今回は勉強用なので、「顧客のデータ１件＝眼鏡の購入日１件」
としてもいいかもね。
再度購入したら、顧客の個人情報を０から入力しなおすみたいな。

に ◆lKs5QMUHoA · 2008/02/06(水) 01:36:05

View の Debug メソッドの仕様もどうするかで迷っている。
Execute($param)したあと、Debugとか、もしくは、
Debugの中でExecute($param)を呼び出す処理だと、
<html>タグのそとに確認データが出力されてしまう。

Debug モードを on にすれば、<body>タグの上部に
テーブルで区切ってデータが表示されるとかかな。
だったら、メンバにDebugモードを追加かな。
という感じに考えてる。

みんなどう思う？

**nobodyさん** · 2008/02/06(水) 09:30:01

>>258
ちょっとしたシステムじゃん・・ (´･ω･)
それこそ既存のフレームワーク使用する案件だよ。

>>260
ディレクティブ付けたechoやvar_dump埋め込みで十分だと思うよ。
むしろその機能を実装するより、デバッガ環境構築した方がいい・・・

OOPに対する基本的概念への理解があまりにも無さ過ぎると思うんだ。
>>255にしても、Executeメソッドに呼ばれる仕組み作ってんのに、
なんで新しいメソッド実装して直接呼びたがるんだろう？

あれほどインタフェイスだけで実装するんだと（ｒｙ
それよりコントローラの実装仕様どうするの？

1 ◆SWtzLesEmM · 2008/02/06(水) 10:44:17

>>243
>ttp://www.geocities.jp/narutobakijp2/

↓動作サンプルを設置しました。
http://ssurl.net/so2o

↓コードに関するコメントのまとめ（>>184-226辺り）
http://ssurl.net/h8bu

**nobodyさん** · 2008/02/06(水) 11:45:05

>>262
非常に乙です。m(_ _)m

>>226だけど　>>1さんにここまでやって貰っちゃって申し訳ないし
これぞOOPってサンプルを必死に実装してアップするんでしばしお待ちを・・

**nobodyさん** · 2008/02/06(水) 13:18:03

>>263
はやくアップしろよなｗ

俺がそれ見て勉強して、いつかエロイ人になったら
お前を雇ってやるよ！　感謝しろ

に ◆lKs5QMUHoA · 2008/02/06(水) 16:04:09

>>262
動作サンプルまでつけていただいて、ありがとうございます。
過去ログも、そのままコピペするんじゃなくて、色をつけたり
分類したりすると非常に分かり易いですね。

ShiftJISだったりとか、スペース2個というのは標準じゃないとかは
気づいてたのですが、そこまで治していただいて申し訳ないです。

**nobodyさん** · 2008/02/06(水) 16:34:44

MVCって難しいね。

**nobodyさん** · 2008/02/06(水) 17:31:55

>>266
別にわかんなくったって、やってけるから大丈夫。
無理に背伸びする必要は無い。

に ◆lKs5QMUHoA · 2008/02/06(水) 20:19:07

フレームワークの解説に関するサイトを見つけました。
ここで概要をつかんだ後、実際に触れてみるといいかもしれない。

ASP.NET vs. Struts
フレームワーク徹底比較［前編］
http://www.atmarkit.co.jp/fdotnet/special/aspstruts01/aspstruts01_04.html

この文章書いてる人、ネットワーク関連の書籍でよく見かけるよね。

**nobodyさん** · 2008/02/07(木) 10:03:39

>>261
> OOPに対する基本的概念への理解があまりにも無さ過ぎると思うんだ。
> >>255にしても、Executeメソッドに呼ばれる仕組み作ってんのに、
> なんで新しいメソッド実装して直接呼びたがるんだろう？

> あれほどインタフェイスだけで実装するんだと（ｒｙ

ちいたんのフレームワークは、Modelにinsertやdelを持ってるからそれを
参考に設計してみたんだけど。
ttp://php.cheetan.net/manual/model.php

俺はこれから勉強していくところなので理解がないのは認めるが、
このあたりはどういう見解なのかを教えて欲しい。
今回作るMVCフレームワークは、学習用なのでもっと簡潔な
レベルなのを想定しているとか、ちいたん作っている人がOOPに
関する理解が無いだけだとか。

**nobodyさん** · 2008/02/07(木) 10:24:36

>>269
フレームワーク実装に正解も不正解も無いと思うけどね・・

例えば
・クラスを使った構造化的メソッド呼び出し
$model->insert();
$model->del();
よりも
・ポリモーフィズム
$insert->execute();
$del->execute();
のほうがインターフェイスが規定されていて
簡潔で安全だと説明したかったんだよ。

insertメソッドやdelメソッドを呼ぶ文脈が規定されていたらどう？
insertオブジェクトのexecuteメソッドならオブジェクトが
文脈をコントロール出来るでしょ？どうかな？

学習用だからこそ『呼ばれる仕組み』で実装しようとしているんだよ。

**nobodyさん** · 2008/02/07(木) 10:55:50

>>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);
}
}

**nobodyさん** · 2008/02/07(木) 11:32:07

じゃ、用件仕様はこんな感じで良いのか？

[認証]
→・ID、パスワードにて認証
　・認証成功で[メニュー]へ移動

[メニュー]
→・（新規）[個人情報入力]、[検索指定]画面へ移動するボタンがある

[個人情報入力]
→・名前、性別　を登録

[検索指定]
→・氏名のキーワードを含む検索、性別指定が出来る。

[検索結果]
→・条件に一致するデータを一覧で出す。
　・個人情報を修正したい場合は、ここから[個人情報入力]へ移動する。
　・個人情報を削除したい場合は、ここで削除ボタンを押す。

**nobodyさん** · 2008/02/07(木) 12:35:22

>>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];
}
}
?>

**nobodyさん** · 2008/02/07(木) 12:36:19

[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);
}
}

**nobodyさん** · 2008/02/07(木) 12:37:26

[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;
}
}
?>

**nobodyさん** · 2008/02/07(木) 13:59:04

細かい指摘になるけれど、継承関係の勉強中なので質問で書き込みします。

[InsertModel.php]
class InsertModel extends DataModel
function & _onExecute(&$param) 　のところは、
return $this->_OnInsert(&$param); 　となっているけれど、
return $this->_onInsert(&$param); 　が正しいという解釈で良いのですよね？

**nobodyさん** · 2008/02/07(木) 14:16:55

>>273-275
ソースのサンプルサンクス。
イメージしてたよりも継承が多いですね。

全体ソースコードの可読性よりも、クラス単位での
再利用性を考えた場合は、このような構成になる
のでしょうね。早く慣れないといけません。

**nobodyさん** · 2008/02/07(木) 15:36:22

まだ中身が出来ていない状況なので、修正の必要はあるだろうけど、
こんな感じでドキュメントもまとめていくと、分かりやすくなるだろうね。

■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に書き込む。

**nobodyさん** · 2008/02/07(木) 23:22:51

>>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

に ◆lKs5QMUHoA · 2008/02/07(木) 23:27:16

>>279
乙です。じっくりソースを読んでみます。

に ◆lKs5QMUHoA · 2008/02/08(金) 08:04:01

せっかくプログラムを作っていただいたのだから、みんなでその説明文章をまとめるといいかもね。
例えば、こんな感じで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

**nobodyさん** · 2008/02/08(金) 08:10:57

>>281
>>279ですがphpDocumentorで今作っているのでちょっと待っててね。

**nobodyさん** · 2008/02/08(金) 08:52:15

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を実装したつもりです・・・
有名なハリウッドの法則です。

[カプセル化]は良いとして、やはり[継承]と[ポリモーフィズム]を
うまく使うのは最初難しいかもしれない・・
これらの実装もデザパタとしてライブラリ化されたものに過ぎないけどね。

**nobodyさん** · 2008/02/08(金) 09:26:17

ファイルが見れん・・・

**nobodyさん** · 2008/02/08(金) 11:03:39

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が反映されてませんでした。

**nobodyさん** · 2008/02/08(金) 11:20:06

サンクス

**nobodyさん** · 2008/02/08(金) 11:51:38

全体構成の把握はまだ出来てないけれど、只今、ソース解析中・・・
いちゃもんつけるつもりじゃないけれど、気になった点を２つ。

Control.phpのPOSTされたSubmitボタン名取得のところは
クラス化されてないのはどうしてなのでしょうか？
さらに非常にクラスが多くなって面倒になるから？

class Control extends Base
var \$_view_calss;
このメンバはあえてclassにしてない理由はあるのでしょうか。

**nobodyさん** · 2008/02/08(金) 12:39:56

>>287
POSTされたサブミットボタン名取得部分は説明の通りです・・
今その部分をC#でのデリゲートで実装しようと思ってます。

Viewクラスexecuteのところもこのままでは$eパラメータが
コントローラから任意に渡せないので検討中です。

オブジェクトにexecute以外のパブリックメソッドを
実装しないのが目標です・・(※アクセサ以外)

**nobodyさん** · 2008/02/08(金) 13:12:48

クラスの継承関係が結構複雑になってますね。
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; // 書き込むファイル名

**nobodyさん** · 2008/02/08(金) 13:15:33

■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()　→現在未実装。

**nobodyさん** · 2008/02/08(金) 13:32:42

こうやってみてみると、クラスを継承する際の設計思想が見えてくるな。
どの段階で実装を替えるかを考えた場合、どのクラスを置き換えれば良いかも分かる。

しかし、俺はこれまでフレームワークの構成などをじっくり読んだりしたことが無いので、
つい、ここまでクラスを継承させるメリットがあるのかなとか思ってしまう。
なんか、１つのメソッドを実装するのに、１回継承してるって感じだよね。

例えば、Model（抽象）クラスの $src_file_name を別のものにする場合、
それ以降のクラスが全部影響するかの確認が必要なわけだから、
Model（抽象）クラス以降のものをすべて一つのクラスにまとめて書いても
同じなんじゃないかと思えてしまう。
こういうのとは別な場面で、継承しているメリットがあるってことかな？

**nobodyさん** · 2008/02/08(金) 13:51:09

ちょっと紹介しておきますね。

フレームワークを使った開発のメリット、デメリットを教えてください
http://q.hatena.ne.jp/1188498291

特集：第1回　フレームワーク「Struts」の基礎を知る (3/8)
フレームワークのメリットとデメリット
http://www.itmedia.co.jp/enterprise/0310/06/epn03_3.html

**nobodyさん** · 2008/02/08(金) 15:31:59

Control の & _onExecute(&\$param, \$e) で
\$this->_view_calss = \$view_calss;
というコードがあるけれど、右辺の \$view_calss って、
何処でも定義されてないですよね？
このまま動かすと、nullが入るだけのように思えるんだけど。

**nobodyさん** · 2008/02/08(金) 16:04:40

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出力する。テキストボックスと送信ボタン

**nobodyさん** · 2008/02/08(金) 16:20:36

>>293
１行上のフックハンドラ実行の結果を渡している。

**nobodyさん** · 2008/02/08(金) 16:41:04

ロードメソッド[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

**nobodyさん** · 2008/02/08(金) 17:33:12

リンク

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

に ◆lKs5QMUHoA · 2008/02/08(金) 18:46:07

>>285のファイルが落とせない・・・

**nobodyさん** · 2008/02/08(金) 19:33:52

>>298 見れるはずですが・・以下はどうですか？
Eclipceでのデバッグ画面です
ttp://proxy.f3.ymdb.yahoofs.jp/bc/4525b767_dfac/bc/452a/OOPFW_DEBUG.jpg?BC3YDrHBI.a6ljXl

**nobodyさん** · 2008/02/08(金) 22:21:47

>>298どうでしょうか？
ttp://briefcase.yahoo.co.jp/bc/oopfw

**nobodyさん** · 2008/02/08(金) 22:24:55

なんでPHP4文法でやってんの？

に ◆lKs5QMUHoA · 2008/02/08(金) 23:53:42

>>300でいけました。サンクスです。

に ◆lKs5QMUHoA · 2008/02/09(土) 01:49:09

これは、>>1さんのサイトでは、「入力フォームを作ってみる」とは
別で、「フレームワークを作ってみる」の演習という位置づけにした
方がいいかもしれないね。

これからの流れとしては、上のほうにあるように、このソースを
解読・改変していくための補助ドキュメント作成の方向と、
このフレームワークを使ってみる人のためのドキュメント作成
（チュートリアルみたいなもの）になるだろうね。
出来る範囲でみんなで手伝っていってみましょう。

このフレームワークは、MFCみたく、あらかじめ準備された
クラスのメソッド中に書き加えていくスタイルなのかな？
それとも、VBみたいにそういうソースコードを全部隠蔽
してしまう方向でいくのかな？ちょっと気になった。

に ◆lKs5QMUHoA · 2008/02/09(土) 02:12:22

こうやってソースを読んでみると、これまで抽象的に聞いていた
フレームワークを使ったプログラミングのメリットとデメリットが実感できるね。

今まで、システムを組む際はOOPやフレームワークを使う方向にするべきだと
思ってたけれど、そうでもなく、状況や目的に合わせて選択する
というのが良い事が分かってきたような気がする。

小規模で全体概要を把握したいとか、移植性を考える場合は、フレームワークよりも、
クラスライブラリを使うスタイルの方が良い場合もありそうだ。

に ◆lKs5QMUHoA · 2008/02/09(土) 08:12:13

MVCでフレームワークを自作する方向と、クラスライブラリを自作する方向の
２つの方向をやってみて、それぞれのメリットとデメリットを確認していけば、
システムを作る場合の検討材料に出来ると思う。

何でもフルスクラッチしていき、なるべく依存性は無いようにし、（言語の
バージョンくらいに収めるとか）その組み合わせでアプリを作る、みたいな。

**nobodyさん** · 2008/02/09(土) 09:45:19

再度リファクタしてみました。
ttp://briefcase.yahoo.co.jp/bc/oopfw

[Controlクラス]
・リクエストオブジェクトの参照の重複の削除
・サブクラスでのフックハンドラ処理修正
・Viewオブジェクトの実行方法修正
※これはViewオブジェクトハンドリングの自由度をました反面、
ユーザからの取り回しが煩雑になったかもしれませんね・・

[Modelクラス]
・継承関係の見直し、ItemBaseクラスの導入などです・・
MVCの継承関係が美しくないですが・・

>>291
リファクタしながら構成を練っていってますが
継承クラスでの責任が小さい単位で分割されていると
大きく修正が入った時も楽だと思います。

>>303
MFCもVB6もフックハンドラに処理を記述していく方式なので
それを参考にしています、サンプルFWも自由にいじってもらって
参考にしてもらえたら良いと思います。
>>305クラスライブラリ方式もいいかもしれないですね。

**nobodyさん** · 2008/02/09(土) 10:20:45

フレームワークのメリットとデメリットにおいて、なるべく具体例を書いた形でまとめてみた。

【メリット】
１．ビューとロジックの切り分けが出来る。（共同作業時に便利）
　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 のバグは、開発元の不具合修正を待つしかない。
　オープンソースのフレームワークであっても、ソースコードが大量な為、把握が出来ない。

**nobodyさん** · 2008/02/09(土) 11:01:52

ＱＡ方式で書いてみた。

Ｑ：どんな時にフレームワークを使った方がいいの？
・短期間で仕上げなければならない時（この場合はフレームワークの使い方を把握しているのが前提）
・チームで分担してシステムを組む時
・バージョンアップを行うなど、長期的な運用が想定される時

Ｑ：フレームワークがあまり向かない場合は？
・個人で小規模アプリを組む時。（一度組んで終わりの場合など）
・そのアプリの全体構成をすみずみまで把握しておきたい場合
・サーバの移植を想定しなければならないなど、環境があまり固定出来ない場合
このような状況の場合は、クラスライブラリの使用を検討すると良い。

**nobodyさん** · 2008/02/09(土) 11:18:48

何かフレームワークを使ったとして、そのフレームワークがいつまでメンテされるか
判らないことを考えると、バージョンアップをするようなアプリの開発に向いていると
いえるかどうかは、かなり怪しいと思う。

**nobodyさん** · 2008/02/09(土) 11:25:52

>>309
そういうケースもあるから入れるか迷ったんだよね・・・
だけど、現在の比較的規模の大きなアプリは何らかのフレームワークで
組まれている事実があるということで、書いてみた。
フレームワークのメンテが突然打ち切られるケースは無いと見ても
良いと思うけどね。事前に何らかのアナウンスがあるはず。

で、フレームワークそのものを入替える必要が生じた時は、もちろん
全部作り直しになるが、この労力は、フレームワークを使わない場合に
比べて楽だよね。という意見です。

**nobodyさん** · 2008/02/09(土) 12:20:07

書いてみた、とかって適当かつ無責任な

**nobodyさん** · 2008/02/09(土) 12:23:25

完璧な文章がいきなりかけるわけないんだから修正しながらでいいと思う。
適当だの無責任だのいうのなら、このスレに来なくて良いと思う。

**nobodyさん** · 2008/02/09(土) 12:32:04

ひょっとして、つられた？

**nobodyさん** · 2008/02/09(土) 15:20:46

つんでれた

**nobodyさん** · 2008/02/09(土) 15:25:19

>>308
> Ｑ：フレームワークがあまり向かない場合は？
> ・そのアプリの全体構成をすみずみまで把握しておきたい場合
全体構成を隅々まで把握してなんの意味があるのだろうか？
どうせ数日たったら忘れるんだし。

> ・サーバの移植を想定しなければならないなど、環境があまり固定出来ない場合
> このような状況の場合は、クラスライブラリの使用を検討すると良い。

PHP4、PHP5両対応のフレームワークもあるし、
いろんなデータベースに対応している場合もある。

フレームワークの開発というのは、そもそもが環境が固定されていないので
そういう場合にはなおさらフレームワークを使ったほうが良い。

**nobodyさん** · 2008/02/09(土) 15:29:20

理解と記憶は別物だと思うけどな。

**nobodyさん** · 2008/02/09(土) 16:52:42

>>315
> 全体構成を隅々まで把握してなんの意味があるのだろうか？
> どうせ数日たったら忘れるんだし。
じゃ、この項目は消しておきます。

> PHP4、PHP5両対応のフレームワークもあるし、
> いろんなデータベースに対応している場合もある。
> フレームワークの開発というのは、そもそもが環境が固定されていないので
> そういう場合にはなおさらフレームワークを使ったほうが良い。
PHPスレで言うのもなんだけど、ASP.NETなども含めた総論という考えだったんだけどね。
Windowsサーバなのかなどを気にするとか、PHP5のみ対応のフレームワークで
開発していて、PHP4しか対応していないサーバで動かすことになる場合を
という意味で、環境が固定されない書きました。

**nobodyさん** · 2008/02/09(土) 17:04:40

修正案

Ｑ：どんな時にフレームワークを使った方がいいの？
・短期間で仕上げなければならない時（この場合はフレームワークの使い方を把握しているのが前提）
・チームで分担してシステムを組む時
・バージョンアップや不具合修正など、納品後もメンテナンスが想定される時

Ｑ：フレームワークがあまり向かない場合は？
・個人で小規模アプリを組む時。（一度組んで終わりの場合など）
・サーバの移植を想定しなければならないなど、環境があまり固定出来ない場合
　このような状況の場合は、クラスライブラリの使用を検討すると良い。

**nobodyさん** · 2008/02/09(土) 22:32:17

あえてPHP4の構文でやってるのは、PHP4との互換性を保つため？
PHP5でやっちゃうと、PHP4の環境で動かなくなるから。

に ◆lKs5QMUHoA · 2008/02/10(日) 03:19:14

ChStrクラスの件を再開しようかな。

1 ◆SWtzLesEmM · 2008/02/10(日) 18:45:04

>>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
ちょっとずつ読んでますが、全部はまだ理解できないです。(´；ω；｀)
レスも参考にしてみます。
（＝分からないことでも、検索で調べるときのヒント・手掛かりになるので）

**nobodyさん** · 2008/02/10(日) 22:19:07

>>321
乙です。m(_ _)m
>>306ですが今後は
・認証の仕組み
・ロギングの仕組み
・エラーハンドリングの仕組み
・バリデイトの仕組み
・トークンの仕組み
・リダイレクトの仕組み
・入力→確認→完了の仕組み
・コアオブジェクトの実行権限の仕組み
など実装していく予定です・・

でも、こればっかりやってるわけにいかないので
気長に見守ってやって下さい。

に ◆lKs5QMUHoA · 2008/02/11(月) 02:31:35

>>321
乙です。分かりやすくまとまっていますね。
私も少しずつ読んでいって理解しようと思っています。
他のものに比べ、コメントが多いのが助かりますよね。

>>322
読むほうも時間がかかると思いますので、
一気にやらなくていいと思います。（＾＾；

に ◆lKs5QMUHoA · 2008/02/11(月) 02:35:18

MVCフレームワークを作っていただいてる流れとはおもいっきり違う事をいうけれど。

>>1さんのOOPで掲示板を作るところは、もう少しクラスを分けたほうが
いいと思ったので、自分なりに作ってみました。

index.phpに、いろいろと処理を詰め込んでいるような感があったので、
それを分ける考え方です。
しかし、DBはテキストベースにしているとか、書き込み欄と表示欄を
同じページにしているなど、基本構成から大幅に変えています。（＾＾；

http://www.geocities.jp/narutobakijp2/
OOPの勉強として、簡易なBBSを作ってみました。
BBS Version1(2008.2.11)

に ◆lKs5QMUHoA · 2008/02/11(月) 08:27:05

クラス間のデータのやり取りにおいて、Listクラスを使う設計にしたけれど、
PHPの場合はハッシュでよかったような気がする件。
まだまだ未熟だな・・・

今後は、これを構造化指向へ変換したプログラムを作り、うｐする予定です。
この両方のプログラムを見比べてみることで、OOPのメリットとデメリットが
見えてくるかもしれません。

**nobodyさん** · 2008/02/11(月) 10:26:11

OOPの継承やポリモーフィズムについての概念やそのコードの書き方に
ついては分かったけれど、その設計方法のノウハウの文章はぐぐっても
なかなか見当たらない。
「設計というのはそれぞれで目的次第」といってしまえばそうだけど、
hiroxpepeさんのソースや、.NET Framework や java の各クラスの
継承関係の設計を見ていると、何か共通したものを感じる。
その具体的な方針と、それを取る理由がはっきりとは分からない・・・

何か良い文章を見かけた、もしくは知っている方は、お願いします。

**nobodyさん** · 2008/02/11(月) 10:50:14

◎「メンテナンスを行う場合」の比較

【構造化指向の場合】
ソースコードに書かれている関数とグローバル変数が、どういう階層で組まれているか
（どの関数でどの関数が使われているか。また、どのグローバル変数を使っているのか）
は、その関数の処理内容と、その関係などを把握してからでないと、手をつけられない。
新しくグローバル変数や、関数を追加する場合。また、ローカル変数を宣言する場合は、
その名前がソースコード内で使われているかを都度チェックしなければならないので、
面倒である。

【オブジェクト指向の場合】
ソースコードそのものがクラス単位で分けられているため、手をつける場所がすぐに
分かる。他のクラスに影響するのは、そのクラスとのインターフェースを変更した場合のみ。
新しくメンバやメソッドを追加する場合は、そのクラスの中で使われているメンバや
メソッドを確認するだけなので、対象となる範囲が狭く、チェックが楽。
また、プログラムそのものがクラスで部品化されるため、チームを組んで、分担作業で
プログラミングがやり易い。

【注意】
構造化プログラミングであっても、関数やグローバル変数の名前の付け方を工夫すれば、
もちろん対応は可能である。そのため、メンテナンスを想定する場合は、
オブジェクト指向でなければならないわけでもない。
オブジェクト指向は、構造化指向に比べて特別に「これが出来る」というものではなく、
構造化指向で不便に感じる部分の便利機能である。

**nobodyさん** · 2008/02/11(月) 10:57:47

>>324,325
なかなか参考になりました、ありがとう。
326さんのおっしゃる通り、"設計"は経験なんかも必要になってくるので、
考えるよりも手を動かして、簡単なスクリプトを組んでみるのが最良でしょうか。

**nobodyさん** · 2008/02/11(月) 12:43:38

>>326
・リファクタリング―プログラムの体質改善テクニック
マーチンファウラー著

高いけどOOPに興味のある方には絶対お勧めですよ。
ポリモーフィズム適用の具体例がコードで解説されていますよ。

構造化プログラミングではGOTO構文を使うのはNGだけど
同様にOOPではswitch構文を使用しません。
ここの部分をポリモーフィズムで実装するのです。

あなたのプログラムにswitch構文がありますか？
その部分はポリモーフィズムで置き換えられますよ。

**nobodyさん** · 2008/02/11(月) 12:53:28

>同様にOOPではswitch構文を使用しません。
>ここの部分をポリモーフィズムで実装するのです。

これは言いすぎ。
OOの基本はモデリングであって、コーディングのスタイルじゃない。

**nobodyさん** · 2008/02/11(月) 13:07:00

>>329
情報ありがとうございます。
> 構造化プログラミングではGOTO構文を使うのはNGだけど
> 同様にOOPではswitch構文を使用しません。
> ここの部分をポリモーフィズムで実装するのです。

> あなたのプログラムにswitch構文がありますか？
> その部分はポリモーフィズムで置き換えられますよ。

この表現はすごく分かりやすかったです。
こういう感じの具体的なノウハウがあると分かりやすいですね。

>>330
「言いすぎ」というご指摘もごもっともだと思います。
しかし、OOPは、構造化指向に比べてダントツで良い所があるわけでも
ないので、（このため、すべてがOOPに移項してはいない。）
良いところを説明する際は、多少は強調した感じで言わざるを
得ないところがあると思っています。

**nobodyさん** · 2008/02/11(月) 13:39:48

>>330
そうですね、確かに言い過ぎました・・

GOTO構文は習いませんでしたが、switch構文は習得しちゃいました。
あえてそれを使用しないで組んでみるのも勉強になるのではないでしょうか？

構造化的スタイルとOOP的スタイルを手っ取り早く理解しようとするなら
それぐらいのパラダイムシフトが必要だと思うんです。

もちろんGOTO構文もswitch構文もコーディングには必要です。

**nobodyさん** · 2008/02/11(月) 15:01:11

switchがいらないということは、
if文もいらないな。

それともswitchを使わずに、
if文で書けばいいのかｗ

に ◆lKs5QMUHoA · 2008/02/11(月) 18:07:43

>>328
（なんか、自分語りみたいなレスになっているけれど、
OOPの勉強方法についての意見交換にもなるかと思ったので書いておきます。）

私は、プログラミングをこれから勉強しようという時、「無駄・ムラ・無理なく
勉強する」という予備校の受験勉強の風潮を受けていましたので、先生に
「プログラミングを勉強する場合は、どんな風なやり方をしたら良いですか？」
とか「どんな順番で勉強をしていったら良いですか？」と聞いたことがあるのですが、
その先生は、「そんなことを考えている時間があるなら、その分コーディングを
した方が良い」とアドバイスをしました。

実際に手を動かしてやってみると、文章や口頭の説明では言えない、何か体感的な
ものが習得でき、その後の勉強方針もどうやったら良いのかが見えてきました。
「ああ、あの言葉は、こういう意味なんだな」と思いました。
プログラミングは、実技の世界なのだから、実際に手を動かしてみて見えてくるものだと
思っています。

過去に表計算をするプログラムを構造化指向で組むと、処理を関数に分けていく方法が
身についたなと思いました。なので、今度は、構造化指向で苦労をするプログラミングを
してみると、OOPの良さが見えてくるのでは、と思っています。

に ◆lKs5QMUHoA · 2008/02/11(月) 18:16:42

BBSの構造化バージョンをうｐしました。

ttp://www.geocities.jp/narutobakijp2/index.html
OOPの勉強として、簡易なBBSを作ってみました。
BBS Version2(2008.2.11)入力したデータで改行に対応してなかったので、その部分を修正。
BBS Version2の構造化Ver(2008.2.11)上記プログラムの構造化バージョンです。

**nobodyさん** · 2008/02/12(火) 04:15:37

そもそも起動したら即終了するようなPHPプログラミングにOOを使う必要性が感じられない。

**nobodyさん** · 2008/02/12(火) 09:16:19

ここは必要性を語るスレじゃないですよ

**nobodyさん** · 2008/02/12(火) 10:36:27

>>336
なんで実行時間とOOの必要性に関連があるの？

>>337
それは了見が狭すぎでしょ。

**nobodyさん** · 2008/02/12(火) 11:35:52

>>336じゃないけど、オブジェクトは状態を保存しておくものだから。
複雑なデータを持つオブジェクトを作っても、mod_phpはリクエストの度にプロセス生成・終了するわけで、そのオブジェクトも消える。
そもそもウェブアプリはユーザからのリクエストを受けて処理が発生しする構造だから、オブジェクトを永続化しておくことにあまり意味はない。
オブジェクト指向に興味があるなら、GUIのあるアプリケーションとか、ゲームとかを作ってみるとよいよ。

**nobodyさん** · 2008/02/12(火) 12:57:39

永続化されていないオブジェクトには意味がほとんどないという主張ならば、どうだろうね。

Booch先生も、「永続性」に対して、「有用ではあるがオブジェクトモデルにとって
なくてはならない要素というわけではない」　って言ってるし。
(もう絶版だけど、Booch法第2版　2.2節より)

**nobodyさん** · 2008/02/12(火) 13:17:09

>>336だけどphpはプロセスを生成してから破棄するまでに処理を1度しか行わない関数？が多いし、
イベントが非同期で発生したりするわけでもないからOOを使うのはどうかなー？って気がする。
だいたいフローチャートで処理書けちゃうしね。

あとデータベースなりファイルなりからデータを読み込んでそれをオブジェクトの形に整形して・・・・
って処理が無駄な気がする。
実際に行う処理よりもその整形処理が長かったりするとなんか本末転倒なような。

**nobodyさん** · 2008/02/12(火) 13:23:42

>>341
>あとデータベースなりファイルなりからデータを読み込んでそれをオブジェクトの形に整形して・・・・
>って処理が無駄な気がする。

なるほど、それはそうだね。
いわゆるロジック的なものがほとんどない Webアプリってのは存在するし。（っていうか大半かも)

フレームワークでもなんでも、整理してるつもりで回りくどいだけってのは多い気がする。
話に付き合ってくれて、どうもありがと。

**nobodyさん** · 2008/02/12(火) 14:28:33

> いわゆるロジック的なものがほとんどない Webアプリってのは存在するし。（っていうか大半かも)
どう考えても少数だろｗ

ロジック無しで何が作れるというんだ？ｗ

**nobodyさん** · 2008/02/12(火) 14:34:01

> そもそもウェブアプリはユーザからのリクエストを受けて処理が発生しする構造だから、オブジェクトを永続化しておくことにあまり意味はない。
その理屈だと、PHPに限らず、JavaでもRubyでもオブジェクト指向は要らないということになるな。
それにアプリでも終了すると消えるわけで、結局はウェブアプリと同じ。

そもそもデータベースやファイルにデータを保存するのも
オブジェクトの保存・永続化なわけだが？

> あとデータベースなりファイルなりからデータを読み込んでそれをオブジェクトの形に整形して・・・・
> って処理が無駄な気がする。
> 実際に行う処理よりもその整形処理が長かったりするとなんか本末転倒なような。
だからフレームワーク使うんじゃん。

**nobodyさん** · 2008/02/12(火) 14:42:23

>>343
単純に、SQLにパラメータ設定して、実行して、検索結果をエスケープしてHTML/XMLのタグつけて
返してるだけで出来てるWebアプリって多そうだけどな。ロジックというほどのもんでもないでしょ。

>>344
ムダなのは実装時間じゃなくて、CPU時間でしょ。
フレームワークで解決する問題じゃないと思うが。

**nobodyさん** · 2008/02/12(火) 14:50:23

>>345　訂正
「本末転倒」って言葉からすると、実装量なのかな。
取り消します。

に ◆lKs5QMUHoA · 2008/02/12(火) 18:36:45

>>341
> あとデータベースなりファイルなりからデータを読み込んでそれをオブジェクトの形に整形して・・・・
> って処理が無駄な気がする。
> 実際に行う処理よりもその整形処理が長かったりするとなんか本末転倒なような。
これはもともとOOPの特性じゃない？
再利用性や保守性を高めるために、他の処理とを完全に切り分ける代わりに、
構造化指向よりも、コード量が多く、動作が重くなるというのは。
これは、個人で組む小規模プログラムでは無駄でしかないが、チームで組んだり、
改変がある場合には威力を発揮する、という類のことでしょ。