PHPでOOP

TOP カテ一覧スレ一覧 100～終まで 2ch元削除依頼
ショッピングカート総合スレ
自作CGIを評価するスレ
【Perl】掲示板を使ろう！
WebProg板の名無しさんを決めよう
CodeIgniter Part3
SSLの使い方
GoogleWebToolkit[GWT]について語ろう
ショッピングカート総合スレ
PHPBB
【Java PHP CGI mod_perl】の使い分け for プロ

1 ：2007/02/23 ～最終レス：2019/05/09: 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^)／
2 ：: 初心者にもわかるようにメリットぐらいかいてよ・・。
3 ：: インスタンスとインヘリタンスがまぎわらしい（なぜか変換・・・
4 ：: オブジェクトと関数の本質的な違いと使い分け
ttp://d.hatena.ne.jp/toku-hiro/20060826
var とか this って何だ？
ttp://d.hatena.ne.jp/toku-hiro/20060902
アクセサメソッド
ttp://d.hatena.ne.jp/toku-hiro/20061022
継承、オブジェクトコンポジション
ttp://d.hatena.ne.jp/toku-hiro/20061129
ttp://d.hatena.ne.jp/toku-hiro/20061203
5 ：: >>2
ttp://d.hatena.ne.jp/toku-hiro/20060826
この説明見てなるほどな～～～！と思いました＾＾
>(1) オブジェクトと関数の本質的な違いと使い分け
>コーディング上の本質的な違いは「変数を保持できるか否か」に尽きます！
>関数を定義するときには、（グローバル変数を除き）引数として関数の外部から渡し、return で返すことしかできませんが、クラスは内部で変数を定義でき、クラスの実体のオブジェクトはどこからでも内部変数を引き出すことができます。
>定義関数の return であれもこれも返したいのにうまく返せず、煩雑な配列に格納して返す…といったことが減ると思います。
>あれもこれも引数として渡したいとき、または、あれもこれもreturnしたいときは、関数よりクラスの方が遥かに簡単です。
「クラス」という仕組は便利そうですね。クラスを考えた奴、偉い！
6 ：: >>3
なんかプログラミングって、カタカナ用語がたくさん登場しますよね＞＜
クラスって聞いたら学校の「教室」を連想しちゃう＞＜
7 ：: Webでオブジェクト指向
http://pc10.2ch.sc/test/read.cgi/php/1133489897/
こっちじゃ何故駄目なんだ？
8 ：: >>1
>>5
自作自演乙ｗ
9 ：: トリップ出してるのに自作自演もくそもあるのかｗ

10 ：: >>7
>Webでオブジェクト指向
>http://pc10.2ch.sc/test/read.cgi/php/1133489897/
>こっちじゃ何故駄目なんだ？
そっちも参考に眺めています。
あと、プログラマー板にもあるオブジェクト指向関係のスレもちょっと眺めています。
PHPに的を絞った情報が欲しいので、専用のスレを立ててみました。
もちろん、JavaやRuby、Pythonとかも使えればいいけど、そこまで手を広げる時間がないので、とりあえず今の段階ではPHPで勉強。
PHPを使っていて、オブジェクト指向プログラミングのやり方を勉強したい人がいたら一緒に勉強していきましょう。
よろしく(・∀・)
11 ：: >>9
ちげーよ
自分のサイトの宣伝して
「この説明見てなるほどな～～～！と思いました＾＾」
と書いてるところがだよ
12 ：: >>11
OOPのメリット聞かれたから自分で見つけた参考サイト出して自分の所感言っただけだろ。
聞くだけで何もしない厨より、アクティブな>>1に好感が持てたが。
って擁護すると自演って言うのかな？
13 ：: まあ、PHPでOOPなんてのは、今までて来たtoku-hiroさん以外にも
書いている人は多そうだから（俺は知らないけど）
他のも出せば、>>1の疑いは晴れるんじゃないかな。
14 ：: Googleで「PHP オブジェクト指向」を検索
http://www.google.co.jp/search?q=PHP+%83I%83u%83W%83F%83N%83g%8Ew%8C%FC
よさげなサイトをピックアップしてみよう！
15 ：: PHPのオンラインマニュアルがよくまとまってますねｗ（当たり前？）
http://jp2.php.net/zend-engine-2.php
第19章クラスとオブジェクト (PHP 5)
16 ：: http://www.mogurin.net/index/php.obj.inc.html
PHP4のOOPについて、簡単な説明がありました。
PHP5のOOPは、PHP4のOOPに変更が加えられているので、ちょっと違う部分があります。
17 ：: PHP4のオブジェクト指向、デザインパターンについての説明がありました。
http://www.aglabo.com/agl/proevo/PHP/objectbrain/4-composite2.html
PHP5のオブジェクト指向について説明がありました。
http://www.doyouphp.jp/php5/
オブ脳 in PHP
http://www.aglabo.com/agl/proevo/PHP/objectbrain/
「委譲」などの説明がありました。
今の段階では、ちょっとよく理解できませんでしたがこんな話もあるんですね。
18 ：: 初心者のおれも学習するから講義すすめてくれ
19 ：: >>18
わかった。
オブジェクトの
オブとはすなわち飯富。飯富厩舎所属だということ。
オブジェクトの
ジェクトトはすなわちジェクト。FF10のジェクトだということ。
20 ：: オブジェクトを利用すると何がいいのか一言でまとめて
21 ：: プロとしての自信が持てるようになります
22 ：: とりあえず簡単なWEBアプリケーションを作りながらOOPの勉強をしてみたいです。
OOPで掲示板を作ってみたいです。
(1)最初はOOPを使わないで掲示板を作ってみる
(2)次にOOPで同じ掲示板を作ってみる
という流れにすると、対比によってOOPが理解しやすくなるでしょうか？
＝始めに完成形ありきと。
23 ：: 掲示板の機能としては、
(1)名前とタイトルと本文を入力＆投稿できる。
(2)投稿の一覧（タイトル＋投稿日時）が表示できる。
(3)投稿の詳細内容（１つ１つの投稿を個別に閲覧）が表示できる。
という最低限の機能で作ってみて、
後から徐々に機能を追加して拡張してみましょう。
24 ：: データベースは普段MySQLを使ってます。
文字化け対策が面倒くさいので、文字コードはUTF-8（UTF-8N）にしときます。
テーブル名は、message
カラムは、
message_id (int not null auto_increment) ←主キーにする
name (text)
title (text)
message (text)
create_date (datetime または年月日時分秒の14桁でvarchar(14))
の5個にしてみましょう。
テーブル名やカラム名の付け方は、
複数形(messages)と単数形(message)のセットで命名したりとか、
主キーは単に「id」としておく方が分かりやすいでしょうか？
ラーメンの具でメンマが9切れのっているか10切れのっているかという違い…些細なことはどうでもいいか。
25 ：: MySQL5.0で、phpMyAdminを使って、oop_testというデータベースを1個新設しました。
その中にテーブルを1個作りました。
CREATE TABLE `message` (
`message_id` int(11) NOT NULL,
`name` text,
`title` text,
`message` text,
`create_date` datetime default NULL,
PRIMARY KEY (`message_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
日付はとりあえずdatetime型にしておきました。
MySQL4.0を使っている人は、上記のSQL文から「DEFAULT CHARSET=utf8」という句を削らないとエラーになると思います。
26 ：: 画面は、>>23の(1)～(3)の3画面を用意すればOKかな？
画面（ハリボテ）を先に作ってみて、それにプログラムを付けて動くようにしてみます。
(1)入力ページ　input.php
(2)一覧ページ　list.php
(3)詳細ページ　message.php
http://itpro.nikkeibp.co.jp/article/COLUMN/20070214/261859/
「HTML画面をそのまま仕様書に」，5カ月で1000画面を構築した就職サイトPuffの高速開発手法
27 ：: wktk
28 ：: >>25
主キーをオートインクリメント（連番の）の設定にしておくのを忘れてました。orz
CREATE TABLE `message` (
`message_id` int(11) NOT NULL auto_increment,
`name` text,
`title` text,
`message` text,
`create_date` datetime default NULL,
PRIMARY KEY (`message_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;
29 ：: サンプルページ公開して

30 ：: 定番のhelloを表示ｗ
class hello {
var $aisatu = "こんにちは";
}
$re = new hello();
$aisatu = $re->aisatu;
echo $aisatu;
読み図ら買ったら適当に改行して
31 ：: #オブジェクト学校のhelloクラスを作る
class hello {

#このクラスに生徒である$aisatu君がいる
#彼に「こんにちは」という言葉を覚えさせる
var $aisatu = "こんにちは";

#放課後なので括弧で閉じる
}

#クラスの風景を覗くための魔法
$re = new hello();

#生徒$aisatu君に「こんにちは」を言わせるための魔法を矢で飛ばす。
#魔法で生徒$aisatu君の$は壊れてしまい、以下のような記述になる。。
$aisatu = $re->aisatu;

#魔法にかかった生徒挨拶君をおまえらのディスプレイに召還する。
echo $aisatu;
32 ：: コードの解説なんてしなくても見ればわかる。
「なぜOOP」か、だとか、
こういう場合にOOPが役立つ、というのを具体的なコードで示してくれ
33 ：: namespace は結局 PHP5 では実装されなかったんだね････
悲しい。悲しすぎる。
34 ：: MVCのMをOOPでCは手続きVはテンプレート
35 ：: >>22 (1)最初はOOPを使わないで掲示板を作ってみる
OOPを使わないで作った簡単な掲示板をアップしてみます。
>>26
ファイルは、他に掲示板のトップページと、DB接続関係のデータを入れたファイルを用意しました。
WEBサーバのルート直下にデプロイした場合を想定しています。
/index.html　掲示板のトップページ
/db.php　データベースの接続関係のデータのファイル
/input.php　メッセージ入力ページ
/list.php　メッセージ一覧ページ
/message.php　メッセージ詳細ページ
36 ：: index.htmlの内容は以下の通りです。
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>掲示板メニュー</title>
</head>
<body>
<h1>掲示板メニュー</h1>
<div id="menu">
<ul>
<li><a href="input.php">メッセージ入力</a></li>
<li><a href="list.php">メッセージ一覧</a></li>
</ul>
</div>
</body>
</html>
37 ：: db.phpの内容は以下の通りです。
<?php
/**
* データベース
*/
//本番環境ドメイン名
define("DOMAIN", "xrea.com");//ドメイン名に含まれる文字列を指定
//MySQL設定（本番環境とテスト環境で切替え）
if (ereg(DOMAIN, $_SERVER['SERVER_NAME'])) {
//本番環境
define("DBSERVER", "localhost");
define("DBUSER" , "username");
define("DBPASSWORD", "password");
define("DBNAME", "oop_test");
} else {
//テスト環境
define("DBSERVER", "localhost");
define("DBUSER" , "test_username");
define("DBPASSWORD", "test_password");
define("DBNAME", "oop_test");
}
（以下、続く）
38 ：: db.phpの続きです。
//MySQL接続関数
function db_connect() {
// MySQL 接続
$link = mysql_connect(DBSERVER, DBUSER, DBPASSWORD);
if (!$link) {
die('mysql_connect ERROR: ' . mysql_error());
}

// MySQL DB 選択
$db_selected = mysql_select_db(DBNAME, $link);
if (!$db_selected) {
die ('mysql_select_db ERROR: ' . mysql_error());
}

// MySQL 4.1以上文字コードセット
mysql_query('SET CHARACTER SET utf8');

return $db_selected;
}
39 ：: db.phpの続き（その２）です。
//MySQLプリペアードステートメント関数（SQLインジェクション対策）
//（参考）http://www.php.net/manual/ja/function.mysql-query.php#70686
function mysql_prepare($query, $phs = array()) {
$phs = array_map(create_function('$ph', 'return "\'".mysql_real_escape_string($ph)."\'";'), $phs);

$curpos = 0;
$curph = count($phs)-1;

for ($i = strlen($query) - 1; $i > 0; $i--) {
if ($query[$i] !== '?') {
continue;
}
if ($curph < 0 || !isset($phs[$curph])) {
$query = substr_replace($query, 'NULL', $i, 1);
} else {
$query = substr_replace($query, $phs[$curph], $i, 1);
}
$curph--;
}
unset($curpos, $curph, $phs);
return $query;
}
?>
40 ：: input.phpの内容は以下の通りです。
<?php
/**
* メッセージ入力画面
*/
require_once("db.php");
db_connect();
//
$name = $_POST['name'];
$title = $_POST['title'];
$message = $_POST['message'];
$error_msg = "";
（以下、続く）
41 ：: db.phpの続きです。
//入力値バリデート
if (0 < strlen($name) && 0 < strlen($title) && 0 < strlen($message)) {
//DB保存処理
$create_date = date("Y/m/d H:i:s");
$sql = "INSERT message SET
name = ? ,
title = ? ,
message = ? ,
create_date = ? ";
$phs = array($name, $title, $message, $create_date);//プレースホルダーにバインドする変数
$sql_prepare = mysql_prepare($sql, $phs);
$result = mysql_query($sql_prepare) or die('SQL Error: ' . mysql_error());
//ページ移動
if ($result == TRUE) {
$url = "http://".$_SERVER['HTTP_HOST']."/test2/list.php";//メッセージ一覧
header("Location: ".$url);
exit;
}
} else {
$error_msg = "名前、タイトル、メッセージをすべて入力してください。";
}
?>
42 ：: >>41
間違えました。
>db.phpの続きです。
ではなくて、
「input.phpの続きです。」
でした。(・∀・)
あと、
>$url = "http://".$_SERVER['HTTP_HOST']."/test2/list.php";//メッセージ一覧
ではなくて、
$url = "http://".$_SERVER['HTTP_HOST']."/list.php";//メッセージ一覧
になります。
＝ローカルでは、/test2というフォルダを作ってその中にいれていたので。
＝本番環境では、ドキュメントルート直下を想定しているので、/test2/は不要
もう一回訂正してアップします。
43 ：: >>41の訂正です。
input.phpの続きです。
//入力値バリデート
if (0 < strlen($name) && 0 < strlen($title) && 0 < strlen($message)) {
//DB保存処理
$create_date = date("Y/m/d H:i:s");
$sql = "INSERT message SET
name = ? ,
title = ? ,
message = ? ,
create_date = ? ";
$phs = array($name, $title, $message, $create_date);//プレースホルダーにバインドする変数
$sql_prepare = mysql_prepare($sql, $phs);
$result = mysql_query($sql_prepare) or die('SQL Error: ' . mysql_error());
//ページ移動
if ($result == TRUE) {
$url = "http://".$_SERVER['HTTP_HOST']."/list.php";//メッセージ一覧
header("Location: ".$url);
exit;
}
} else {
$error_msg = "名前、タイトル、メッセージをすべて入力してください。";
}
?>
（以下、続く）
44 ：: input.phpの続き（その２）です。
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>メッセージ入力</title>
</head>
<body>
<h1>メッセージ入力</h1>
<div id="menu">
<ul>
<li><a href="input.php">メッセージ入力</a></li>
<li><a href="list.php">メッセージ一覧</a></li>
</ul>
</div>
<?php echo $error_msg; ?>
<div id="input">
<form name="form_input" method="post" action="input.php">
<div id="name">名前<br>
<input type="text" name="name" value="<?php echo htmlspecialchars($name); ?>">
</div>
<div id="title">タイトル<br>
<input type="text" name="title" value="<?php echo htmlspecialchars($title); ?>">
</div>
<div id="message">メッセージ<br>
<textarea name="message"><?php echo htmlspecialchars($message); ?></textarea>
</div>
<input type="submit" name="submit" value="送信">
</form>
</div>
</body>
</html>
45 ：: list.phpの内容は以下の通りです。
<?php
/**
* メッセージ一覧画面
*/
require_once("db.php");
db_connect();
//
$page = intval($_GET['page']);
$max = 10;//１ページ当たりの最大表示件数
//ページング（ページ数は１から数える）
$sql = "SELECT count(*) AS total FROM message";
$result = mysql_query($sql) or die('SQL Error: ' . mysql_error());
if ($result) $row = mysql_fetch_array($result);
$total = $row['total'];//全メッセージ数
$page_total = ceil($total / $max);//全ページ数
if ($page < 1) $page = 1;
if ($page_total < $page) $page = $page_total;
//メッセージ取得
$sql = "SELECT * FROM message ORDER BY create_date DESC LIMIT ".(($page - 1) * $max) .",".$max;
$result = mysql_query($sql) or die('SQL Error: ' . mysql_error());
?>
46 ：: list.phpの続きです。
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>メッセージ一覧</title>
</head>
<body>
<h1>メッセージ一覧</h1>
<div id="menu">
<ul>
<li><a href="input.php">メッセージ入力</a></li>
<li><a href="list.php">メッセージ一覧</a></li>
</ul>
</div>
<div id="paging">
<?php
//ページング処理
echo "全".$total."件";
echo "（ページ".$page."目）";
for ($i = 1; $i <= $page_total; $i++) {
echo "<a href='list.php?page=".$i."'>".$i."</a> ";
}
?>
</div>
47 ：: list.phpの続き（その２）です。
<table border="1" cellpadding="5">
<tr bgcolor="#FFFF99">
<td>タイトル</td>
<td>投稿者名</td>
<td>投稿日</td>
</tr>
<?php
//メッセージ一覧
while ($rows = mysql_fetch_array($result)) {
echo "<tr>";
echo "<td><a href='message.php?message_id=".htmlspecialchars($rows['message_id'])."'>".htmlspecialchars($rows['title'])."</a></td>";
echo "<td>".htmlspecialchars($rows['name'])."</td>";
echo "<td>".htmlspecialchars($rows['create_date'])."</td>";
echo "</tr>";
}
?>
</table>
</body>
</html>
48 ：: message.phpの内容は以下の通りです。
<?php
/**
* メッセージ詳細画面
*/
require_once("db.php");
db_connect();
//
$message_id = intval($_GET['message_id']);
//メッセージ取得
$sql = "SELECT * FROM message WHERE message_id = ?";
$phs = array($message_id);//プレースホルダーにバインドする変数
$sql_prepare = mysql_prepare($sql, $phs);
$result = mysql_query($sql_prepare) or die('SQL Error: ' . mysql_error());
if ($result) {
$row = mysql_fetch_array($result);
}
?>
49 ：: message.phpの続きです。
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>メッセージ詳細</title>
</head>
<body>
<h1>メッセージ詳細</h1>
<div id="menu">
<ul>
<li><a href="input.php">メッセージ入力</a></li>
<li><a href="list.php">メッセージ一覧</a></li>
</ul>
</div>
<table border="1" cellpadding="5">
<tr>
<td bgcolor="#FFFF99">投稿者名</td>
<td><?php echo htmlspecialchars($row['name']); ?></td>
</tr>
50 ：: message.phpの続き（その２）です。
<tr>
<td bgcolor="#FFFF99">投稿日</td>
<td><?php echo htmlspecialchars($row['create_date']); ?></td>
</tr>
<tr>
<td bgcolor="#FFFF99">タイトル</td>
<td><?php echo htmlspecialchars($row['title']); ?></td>
</tr>
<tr>
<td bgcolor="#FFFF99">メッセージ</td>
<td><?php echo nl2br(htmlspecialchars($row['message'])); ?></td>
</tr>
</table>
</body>
</html>
51 ：: それでは、次行ってみよう！
>>22 (2)次にOOPで同じ掲示板を作ってみる
>>34
PHPコードとHTML表示を一緒にしてありますが、OOPではテンプレートシステムを使って、PHPコードとHTML表示部分を分離して、MVCにしてみたいです。
どういうクラスを作ればいいのか良く分かりません＞＜
(1)コントローラー（＋アクション）→input、list、message
(2)モデル→データベース接続処理も１つのクラスにするのでしょうか？
(4)ビュー→テンプレートシステムへの出力
というかんじで３個のクラスが必要でしょうか？
それぞれのクラスに必要なプロパティとメソッドを何にするか？
クラスを考えて、ＵＭＬでクラス図を作ってみたいです。
52 ：: がんばってるなあ。
おれもがんばろう。
53 ：: わかりにくいからWebサイトにまとめてくれ。PHP使いなんだし
54 ：: >>53
まとめサイトを設置しました。
ttp://kameleon.s241.xrea.com/dokuwiki/doku.php
55 ：: 最終的にMVCな構成を目標に
少しずつリファクタリングしていけばよいと思う
とりあえずDBアクセスを一箇所にまとめるモデルを作ってみるといいんじゃない
・全件取得
・1件取得
・1件追加
できるMessageクラスとかを作ってそこにDBアクセス（SQL)をまとめれ
56 ：: 期待上げ
57 ：: 期待
58 ：: OOP勉強したいなら、実力不足のやつが書いたガラクタ掲示板スクリプトを
読むより、有名なオープンソースのスクリプトを読めばいいじゃん。
そもそも>>1の意味不明な独善なんかに付き合わなくてもOOPに関する情報
はいくらでも手にはいるし。
59 ：: ど素人に肥大したコードを読ませて理解できると思ってる思考回路がｶｺｲｲ！
60 ：: >>59
ど素人はみんな、自分みたいな学習意欲も向上心もない人間だと思ってる
思考回路がｶｺｲｲ！
61 ：: >>60 思考回路がｶｺｲｲ！
62 ：: >>59-61
全員ｶｺﾜﾙｲ！！　俺はｶｺｲｲ！！
63 ：: >>1-62
全員ｶｺｲｲ!!
俺はｶｺﾜﾙｲ!!
64 ：: で、結局荒れ放題になり>>1の独善は無事終了したのだった。
ちゃんちゃん。
65 ：: >>55
DBにアクセスするためのクラスを作ろうと思って、とりあえずdb.phpをクラスの形に変えてみようと試みました。
だけど、コンストラクタでエラーが出てストップ！
Fatal error: Cannot access empty property in /…/test.php on line 18
なんでエラーになるのか？よく分からなくて、PHP5のコンストラクタについて調査していたら、サンプルになりそうなDBクラスの解説記事がありました。
http://www.bnote.net/php/php/09_db_class.shtml
↑これをソックリ真似すれば、DBクラスは何とかなるかな？
ところで、このbnoteというサイトのPHP解説記事には、掲示板を作ってみるサンプルがあり、参考になりそうです。
http://www.bnote.net/php/php_idx.shtml
>PHPでフォーラムを作ろう!
66 ：: 中傷されている>>1だが、
普通に>>1のおかげでだいぶいい情報が手に入った。
曖昧だったクラスがなんとか分かりそうだよ。
ありがとー
PHPでわからない人は情報が足りないのかもな。
似てるJAVAで本格的なものを見てみると分かるのかも。
昔、歴史で年表同士のつながりが薄くて分かりづらかったように、
もっと詳しく高校の歴史くらいのをみれば分かりやすい。
67 ：: なんていうか「こういうときにはこういう設計をします」っていう
具体的な情報がほしいよな
俺は車なんかプログラミングしないっての
68 ：: 最近ちょっとだけ解ってきた。
なぜOOPなのかと言えば
再利用とメンテナンス、拡張がやりやすい（やりやすく作ることが出来る）ということがすごくて、
そのためにカプセル化とポリモーフィズムがあって
ポリモーフィズムを実現（保証）するために継承や、インターフェイスや抽象クラスがあるって感じなのかな？
PHPによるデザインパターンは読んでみても良いと思う。
あと、ゼンドフレームワーク勉強用にZFで動くブログソフトみたいのあるから、それの仕組みと、ZFのソース（全部はきついけど関係あるところだけ）
を見てみると、結構勉強になると思う。
ttp://www.itmedia.co.jp/enterprise/articles/0702/28/news028.html
ttp://www.itmedia.co.jp/enterprise/articles/0703/05/news013.html
ttp://www.itmedia.co.jp/enterprise/articles/0703/08/news018.html
記事がちょっと古いから最新バージョンと微妙に違うけど。
まあ、このフレームワークが良いか悪いかは別にして（まだベータだし）
OOPバリバリなので、勉強になること間違いなし！
69 ：: しかし　PHP関連の本でOOPをわかりやすく書いてあるのが

「ない！」　お勧め教えて
70 ：: 本なんか読むよりPEARやフレームワークのソース読んで
勉強しながら自分なりに書いていけ、金かからないしだしそれが一番の近道
気が付いたらOOPなんて空気のように有って当たり前になるもんだから
71 ：: わかりにくいの例として
スコープ演算子（static　：：）は2冊読んでもチンプンカンプン
そこでぐぐる先生に聞くと
http://homepage3.nifty.com/gomi_doji/scopen.htm
PHPではないが、ナルホドナルホドと理解できる
オブジェクト指向の概要も
http://phpspot.net/php/pg%83I%83u%83W%83F%83N%83g%8Ew%8C%FCPHP.html
を読むとナルホドナルホドだが、本は意味不明になる
糞った本しか読んでいないかもしれないが一応書いておく
「PHP5プログラミング　エキスパート編」　//最強の意味不明
「MySQL4/PHP5によるWebデータベース構築」　//わかりやすいがODPの章になると意味不明
72 ：: 書きながら次第にむかつき度が増加して誤字だらけになった（怒
>>70
それ疲れる
73 ：: >>69
独習PHPのクラスらへんの説明は中々分かりやすいよ。
作者があまりいいとはいえんが、ファーストステップにはいい感じ。
74 ：: 同じ事を色々な言葉で表現するから迷うずら
PHPの本読むよりJAVAの本読んだほうが理解できる罠。
75 ：: 自分が作るだけなら手続き型でいいけど
人の作ったライブラリ使いたいから
最低限、何が書いてあって何をしているのか読めるようになりたい
76 ：: 答えが出てるじゃないか。その使いたいライブラリのコードを読め
77 ：: OOPS
78 ：: XOOPS
79 ：: >>65に誰もつっこまないのかよ！！
DBアクセスの為のクラス書くのかｗ
おそらくPHPインストール時に君のHDDの中にすでに入ってる訳だが…
しかもあらゆるDBに同じ書式でアクセス出来るやつが…
80 ：: >>79
なんてやつ？
81 ：: PEARのソースは読まない方が身のため
82 ：: 79は勘違いしてるが、彼がいいたいのはPearのDBクラスのことだろう
83 ：: 82が勘違いだろ。
単にPDOだろ
84 ：: >>73
情報提供どうもありがとうございます。
独習PHPは、図書館でかりて読んでみました。
オブジェクト構文の説明は分かりやすいと思いました。
>>79
DBにアクセスするクラスも勉強のため練習で作ってみようと思いました。
その次に、O/Rマッパーの使い方を練習してみることになるでしょうか？
>>82
PHP5に標準で用意されているPDOのことですね。
http://jp2.php.net/pdo
PHP Data Objects (PDO) 拡張モジュールは、 PHP の中からデータベースにアクセスするための軽量で高性能なインターフェイスを定義します。
PDO は PHP 5.1 以降にバンドルされており、PHP 5.0 では PECL 拡張モジュールとして使用可能です。
PDO は PHP 5 の新機能であるオブジェクト指向機能を使用しており、それより前のバージョンの PHP では動作しません。
85 ：: mysqliとどっちがいい？
86 ：: ふとおもったんだが、>>1はできるんじゃないのか。
87 ：: 被害者増やさないように書いておく。
「PHPデザインパターン入門」は買うな。
最近買った中で最低レベルの悪書。
どっかの英語ページを機械翻訳したようなトンチンカンな用語説明にまじって
何故かApacheとPHPのインストール方法だけが丁寧な日本語で書かれている。
あとはデザインパターン図が羅列してあるだけ。解説ほぼ無し。
3流大学生のコピペ論文を彷彿とさせる。
こんなの真剣に呼んでも絶対わかるようにはならない。
OOP用語の説明は何故かちゃんとしてないのに
php.iniにページさかれてるけど
網羅して無くて中途半端でページ稼ぎとしか思えない。
中身薄くて有名なヤマダヨウカン本の方がマシに感じるレベル。
88 ：: なんか良く読むと、この本は解説の日本語が
オブジェクト指向で書かれてる気がした。
多分最初にパターン名を記載した時点で、作者の頭の中では
記載されてるページを呼び出してるんだろうと思えてきた。
解説するための日本語はプロシージャ指向で書いてくれと
小一時間問い詰めたい。
この本理解するには色んな本を買って、全部理解した後じゃないと
読めない。意味ねえじゃん。
89 ：: 軽いフレームワークいじって使うのが一番いいオブジェクト指向の勉強だよ
90 ：: ウェブアプリにオブジェクト指向なんていらないよ。どうせ文字列を加工してデータベースのテーブルのカラムに並べるだけなんだから。
91 ：: じゃどういうときに必須なんよ
92 ：: オブジェクト指向と言う言葉にまどわされず、
クラスの勉強をすればいいんだよ。　
単に、呼び出してるだけだから。　
93 ：: PEARをサンプルみながら見よう見まねでインスタンス作って
なんだかんだで実際動いてるんだけど何してるかイマイチ理解出来てないんだよね
functionの中でインスタンス作るとその外側ではやっぱアクセスできないのかな
PEARDBのインスタンスがあっちゃこっちゃに散らばっちゃって困る
94 ：: >>93
プロパティに入れれ
95 ：: >>68
>拡張がやりやすい（やりやすく作ることが出来る）
そうみたいですね。
http://www.amazon.co.jp/dp/4822281957/
「オブジェクト指向でなぜつくるのか」
という本にも、クラスを使うメリットが同じように説明されていました。(・∀・)
>>74
Javaの本だと
http://www.amazon.co.jp/dp/4797331828/
「やさしいJava」をすすめられました。
>>86
(σ・Д・)σプログラミング初心者ですΣ(ﾟДﾟ*)=3
>>89
Zend Frameworkの正式版が出ましたね☆
http://framework.zend.com/manual/ja/
シンプルなフレームワークを検索したら、CodeIgniterというのがありました。
http://userguide.cilab.info/
96 ：: 最近このスレが怖くて見れん俺ガイル
なんでそんな成長早いんだよ・・・おかしいだろ・・・orz
97 ：: class TV {
　var $channel;
　var $state;
　var $singleton;
　
　function TV() {
　　$this->channel = 1;
　　$this->state = false;
　}
　
　function on() {
　　if(!$this->state) {
　　　$this->state = true;
　　　echo "電源オン<br />";
　　　$this->reflect();
　　} else {
　　　echo "既に電源はオンになっています<br />";
　　}
　}
　
　function off() {
　　if($this->state) {
　　　$this->state = false;
　　　echo "電源オフ<br />";
　　} else {
　　　echo "既に電源はオフになっています<br />";
　　}
　}
98 ：: 　function reflect($c = null)　{
　　if($this->state) {
　　　if(!empty($c)) {
　　　　$this->channel = $c;
　　　}
　　　
　　　echo $this->channel . " チャンネルを写します<br />";
　　} else {
　　　echo "電源が入っておりません<br />";
　　}
　}
}
$tv = new TV;
$tv->on();
$tv->reflect(8);
$tv->on();
$tv->on();
$tv->off();
$tv->off();
$tv->reflect(5);
$tv->on();
99 ：: 例外投げるようにすれば？

100 ：: 例外処理
http://www.phppro.jp/word/E4BE8BE5A496E587A6E79086
2. PHPで例外処理
http://www.phppro.jp/phptips/vol45/eb49e8a31e9132d98a5a7db3df4663e4
PHP5の基本 > 例外処理
http://www.shigeweb.jp/php/project_p/?section=php5oop&page=exception
phpspot - 例外処理
http://phpspot.net/php/pg%97%E1%8AO%8F%88%97%9D.html
PHP4ではエラー処理といえば、
if ( ($err = func()) != "" ) {
　　die("エラーです");
}
のように戻り値のチェックをしていましたが、エラーというものは、呼び出し側がエラー制御を行うのではなく、呼ばれた側で、どういうエラーがあったか、というものがあった方が自然で、呼ばれた側がエラー処理を行うため、モジュールの場合より再利用性が高くなるでしょう。
更に上記では、どういうエラーが起こってエラーが出ているのかということが想像しにくいですね。
そこで try～catch です。
■例外処理
http://www.atmarkit.co.jp/flinux/special/php5/php5d.html
プログラミングにエラー処理は避けて通れない事項だ。
とはいえ、関数やメソッドからの戻り値を毎回エラーチェックするのは煩雑で面倒でもある。
その煩雑さを回避するため、文法として例外処理を持っている言語もある。
PHP5もそれに倣って、言語仕様として例外処理をサポートした。
文法的にはC++やJavaと同様に、try{ }で投げられた例外をcatch{ }で処理するという流れになる。
↑とのことですが、汎用性のある関数やメソッドにしたい場合、エラーが発生したときの処理を書く場所は、関数やメソッドを使う方（呼び出す側）にすることもあるでしょうか？
＝戻り値をチェックするというのは、古いやり方なんでしょうか？
101 ：: >>96
PHPプロのメルマガ読んで、知ったかぶりなだけですｗ
お互いがんばりましょう☆(・∀・)
102 ：: いやさ，まず公式マニュアルを読む癖を付けようぜ
103 ：: MVCじゃないとOOPなんて意味ないですかｒ
104 ：: （　д）　　　　　　...。。
105 ：: MVCもデザインパターンの一種じゃなかったっけ？
106 ：: >>100
なんかphpspotのその文はおかしいな。
エラー処理は例外を使おうがそうじゃなかろうが変わらない。
呼ばれた側はどういうエラーがあったか返す責任があるし、
呼んだ側は返ってきたエラーをチェックする責任がある。
エラーが起きた時の挙動を自分で決めれるならその場で処理すれば良いし、
そこではまだ決められないならさらに上位へreturnなりthrowすれば良い。
107 ：: OOPってのはアプリケーションをモノに見立てて、それを構成している部品をクラスとして定義する、ってとこまではなんとなく理解した。
例外処理？なにそれうまいの？
108 ：: ダンボールの味がするお
109 ：: おまいらオブジェクト指向に騙されてるよ。ただのデータ型に過ぎない。
110 ：: 今、習作としてプロフィールスクリプト(っていうのも大袈裟なぐらいショボイやつ)を書いてるんだけど、どうにも悩む。悩む。
とりあえず、
-質問と答え(Entry)
--セッタ(SetQuestion,SetAnswer)
--ゲッタ(GetQuestion,GetAnswer)
-それらのEntryを編集したり、操作したりする(ManageEntry)
--POSTされたデータにEntryの値を変更する(EditEntry)
-プロフィール自体(Profiel)
--質問と答えを出力(ViewProfiel)
こんなクラスたちを作ったんだけどなんかおかしい気がしてならない。
とくにManageEntryのとことか。
ManageEntryでEntryオブジェクトの配列Entriesを作っといてそれをそのクラス内で操作とか？は？え？
OOPﾑｽﾞｲ、ﾅｷﾀｲ

スレ汚しｽﾏｿ
111 ：: どんな物を作ってるのかよく分からないけど
ぱっと見で確実に言える事は、個別のクラスが多すぎ。
半分くらい継承とメソッドの追加で済みそう。
今のままだと拡張もやり難そう。
プロフィールが"profiel"なのはつっこんだ方が良いのかな。
CakeとかSynfonyみたいな、ライブラリじゃないフレームワークを
使い込んでソース読んだら、どう設計したらよいか一気に分かるよ。
112 ：: 継承とメソッドの追加ってどうやるんですか＞＜；
正直どうやったらいいのか全くわからん。
プロフィール？え？あ？あはあは。
113 ：: きめぇ
114 ：: Synfony はつっこんだ方（ry
115 ：: >>106
>呼ばれた側はどういうエラーがあったか返す責任があるし、
>呼んだ側は返ってきたエラーをチェックする責任がある。
なるほど～(・∀・)
呼ぶ側と呼ばれた側のそれぞれでエラーの対処があれば、手堅いですね！
大変参考になりました。
116 ：: 掲示板の続きを作りました。
DBにアクセスする機能をクラスにしてみました。
http://kameleon.s241.xrea.com/dokuwiki/doku.php?id=%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E6%8C%87%E5%90%91%E3%81%A7%E4%BD%9C%E3%81%A3%E3%81%A6%E3%81%BF%E3%82%8B
動作サンプル
http://kameleon.s241.xrea.com/oop/bbs2/index.php
なんか、>>55さんのアドバイスの形になってませんが…orz
とりあえず、DBアクセスをクラスの形にできたので一歩前進！！！＼(^o^)／
117 ：: >>110
おー、ガンバレ～～～☆
>>111
(1) Entryクラス
文章を「書き込む」メソッド、「読む」メソッド、「書き換える（編集）」メソッド、「削除する」メソッドが用意されている。
(2) Entryクラスを継承して、質問用のクラスを用意
＝質問のデータだけを操作できる
(3) Entryクラスを継承して、答え用のクラスを用意
＝答えのデータだけを操作できる
というかんじになるんでしょうか？
どういうまとまりでクラスにすればいいのか、そこら辺がなんかよく分からないんですよねー(ﾉ∀`)
118 ：: どうしてPDOをry
119 ：: おんにゃにょこの
おっぱい
ぷぴにぷにだにょ～
120 ：: 夏だな
121 ：: function &foo ｛
echo "ほげ"
｝
こういうやつ、「リファレンスを返す」っていうんですか？
これはどういう処理をしているんでしょうか？
どこかで定義されているfoo()という関数に何かしているんですか？
122 ：: 高機能な参照関数だな
123 ：: >>87
買ってしまっていたよ。Iteratorまで読んだけど、
分かったような分からないような気分。
説明が少ない＆下手なのは分かった。
124 ：: 分からない人に分かるように書いてないという意味では同意。
書いてあることを全て理解していこうとするとこんがらがってくるしね。
まぁいい頭の体操になったけど。
あんなサンプルのためのサンプルではなく、具体的な使い方と利点が書いてあるとOOP素人にも理解しやすかったかもね。
125 ：: >>117
なんかCakePHP使ってみたんだけど質問と答えを操作するクラス作って云々みたいになって結局>>110と同じような感じになっちゃいましたとさ・・・
「モノ」に書く機能とか読む機能持たせていーの？おしえてえろいひと＞＜
126 ：: お前が「モノ」をどう捉えるか次第だよ
127 ：: 結局どうやってデータを保持したら、人間にとって分かりやすいか、コンピュータにとってやさしいかってことだろ。
128 ：: オブジェクト指向は木構造を再現しようとしているだけ。
インスタンスだのオブジェクトだのは枝、茎、葉、花、果実を作るというだけ。
mainでは結果(果実)だけをとりたいから枝やら茎やらは見えなくしとけってことだろ?
129 ：: >>128
まあそんな感じだ
130 ：: まぁ、ファイルの管理方法も木構造だし、インターネットなんていっても網状でなく、
サーバーを経由した木構造になってることから演算機が理解しやすいデータ構造は木構造である。
こういってしまっても過言ではないと思う。

例えば、手続き型は東京の小さなバイク便が地方への配達を頼まれても東京発で請け負うみたいなもの。
それに対して、OODはヤ○ト運輸が東京で頼まれた配達を一旦、地方の配送センターに送るようなもの。
配達する対象が少なければ、バイク便に頼んだ方が早いかもしれないけど、数が多くなるとヤ○ト運輸。
131 ：: うん、ここ数日でオブジェクト思考勉強してて分かったこと。
ちなみに128==130==漏れです。
・オブジェクト指向は木構造
・目的は種の存続、繁栄
・ここでのフローは一つずつだが、間にどれだけの枝が挟まるかは設計次第
クラス設計
　種(プリプロセッサ)から芽が出る(この時点では手続き型でも、OODでもない)
　根クラス…main関数、もしくはmainクラスの設計、遺伝子(設計の違いで木になるかどうかが決定)
　幹クラス…根から養分を吸い上げる(大まかな工程の分類)
オブジェクト生成
　枝クラス…効率的に日光を取得できるよう枝を伸ばす(コンストラクタ)
　葉クラス…光合成を行い、自己生産を行う(メソッド)
　葉緑素クラス…目立たない頑張り屋さん(ライブラリ)
　花クラス…実となるか枯れ落ちるか(オブジェクト)
実行結果
　果実クラス…土に還り、新たな種となりました(プロジェクト成功)
132 ：: なんかすぐ動いて実用的で簡単なサンプルください
133 ：: package hoge;

my $class=shift;
$ENV{'TZ'} = "JST-9";
my ($sec,$min,$hour,$mday,$mon,$year) = gmtime(time + 9*60*60);
my $obj={'sec'->$sec, 'min'->$min, 'hour'->$hour, 'mday'->$mday, 'mon'->$mon, 'year'->$year};
return bless $obj, $class;
1;

適当に書いてみた。あとは時間をｺﾞﾆｮｺﾞﾆｮするだけ、普通に作ったほうがメリット大きい気もするがｷﾆｼﾅｲ!!
ﾖｳｶｿﾏｿ参上===[・∀・]ﾉｼ
134 ：: 実際に設計して、作ってみるとオブジェクト指向の本質は"同じことは出来るだけ"しない。
この論理で動いてるような気がしてきた。何でもかんでもオブジェクトにするのではなく、
運搬の頻度が激しいデータ、プログラム中で何度も使用するデータをオブジェクトにする。
そんな感じで合ってるのかな？あと、変数の受け渡しは原則、参照で行うみたいな。
135 ：: 何となく掴めてきた。もっかい木構造で表してみる。
根：　プリプロセッサ、送信データ(実行役)
幹：　main(効率よく栄養=処理を振り分ける)
[クラス]・・・大規模にもなるとこれが幾重にもネストされる。
　　枝：　コンストラクタ(葉に栄養=処理を割り振る、葉で生成された養分=オブジェクトを幹に伝える)
　　葉：　メソッド(オブジェクト=養分を生成する)
　　花：　オブジェクト(実行結果=果実の手前)
果実：　実行結果(主の繁栄=実行結果が真)
ちなみに実行結果が偽となるのは幹から花に至るまででエラーが起こった場合。

漏れルール
mainは基本的にクラスに指示を与える以外しない。
コンストラクタでオブジェクトの用意を行う。
メンバメソッドはオブジェクトの加工を行う。
コンストラクタからオブジェクトを返す。
mainは次に必要なオブジェクトを作るクラスへ処理を回す。
136 ：: 日曜日１GET!
始めまして
まだＰＨＰ3ヶ月目ですが早くもオブジェクト指向で挫折＞＜
ちなみに
・「基礎ＰＨＰ」
・「ＰＨＰ５であなたもウェブアプリが作れる！」
・「速効!図解プログラミングPHP + MySQL」
を参考書にしています。
分かりやすかったのは基礎ＰＨＰです。
掲示版からスケジュール管理に移るところで
Smarty関連を追加するため承継とか出てきてなるほどと思いました。
ただソース理解しても自分では何もできないんですけどねｗ
137 ：: 掲示板の改良はどうします？
138 ：: 丸投げします
139 ：: OOPで作ったやつの
ソースとかうｐったら
なんか色々言ってもらえるんかな？
このスレでは
140 ：: >>139
自分も変なソースですけど味見してもらえます？
恥ずかしいです＞＜
141 ：: >>133
これをどうやって使えばいいんですか
142 ：: なかなか面白いブログを発見しました。
ぜひ皆さんに見てもらって意見聞きたいな^^
http://blogs.itmedia.co.jp/tamaki/2006/06/post_57ab.html
143 ：: ＭＶＣのコントローラについてどこまでクラスにするか迷っています・・・
144 ：: ﾊｧ?
145 ：: 意味わかんね
どこまでクラス？
146 ：: まずはモデルでしょ
147 ：: SPLって使ってる人実在するの？
http://jp2.php.net/manual/ja/ref.spl.php
148 ：: 例外はよく使う
149 ：: >>147
読み込んでも八割がた無駄なので使わない
150 ：: かしゆか誕生日おめでとう！
http://www.tkma.co.jp/tjc/j_pop/perfume/profile.html
151 ：: >>149
つりですか？
152 ：: MVCのCってどうやって書けばいいのかわからんぜ。
153 ：: その概念中でコントローラーが理解出来ないってやつ初めてみた
とりあえずView上で必要な操作を徹底的にControllerに切り離すが良い。
そしてModelからデータを引き出して必要があれば書き込み更新してやりなさい。
154 ：: ユーザークラスで新規登録処理をして、そのときにユーザークラスの中で
プロフィールクラスのオブジェクトを作ってプロフィールの登録もする
これってしいて言えば何パターン？
155 ：: ワンパターン
156 ：: パターンというかコンポジションでそ
157 ：: 模範解答は無いけれど、以下の相互変換を行うクラス（ChStr）をみんなで
作ってみるという案はどうかな？
そして、これが出来たら、ログファイルに保存などの機能をつけ、
wikiみたいに編集が出来る機能を追加していくという感じに。
＜編集＞
-------------------------------------------------------------
= 2ch
'''2ch'''とは、総合掲示板のことである。
link:[http://www.2ch.sc]
-------------------------------------------------------------
＜出力＞
-------------------------------------------------------------
<b><font size="+1">2ch</font></b><br>
<b>2ch</b>とは、総合掲示板のことである。<br>
link:<a href="http://www.2ch.sc">http://www.2ch.sc</a><br>
-------------------------------------------------------------
158 ：: >>157
OOPの勉強というよりも、どちらかというと正規表現の勉強になるでしょうか？
wikiのパーサーつくるなら、既存のwikiスクリプトや、PEARのText_Wikiが参考になるかもしれませんね。
http://www.phppro.jp/news/172
PEAR::Text_Wiki 1.2.0RC1 リリース 2006年10月11日
http://labs.cybozu.co.jp/blog/tsuruoka/anubis/blog_show/18
Text_PukiWikiリリース
159 ：: >>158
C++のOOPの勉強として、文字列を簡単に扱うことが出来るクラスを
自作してみるという演習があったので、それをPHPでもやってみようかなと
思ったものです。
Cでは、文字列を結合したり、splitしたりするのが結構大変なので、
この演習が役に立ったなと思っていたのです。
PHPの場合は、関数を使えばそれで終わってしまうので、もう少し
ひねりを入れたものを考えて見ました。
正規表現を練習するというよりも、正規表現とhtmlの相互変換をする
クラスがあると、プログラムをする際、便利だなという事が実感
出来るのでは？という意味合いです。
（例）正規表現を格納し、html出力する過程。
$text に textarea タグの文字列を格納する。
$str = new ChStr($text);
echo "<html><body>";
$str->Write_html();
echo "</body></html>";
ほら、このクラスがあるとレイアウトを変えたりが、やり易い上に
再利用性が高いでしょ？みたいな。
160 ：: OOPの参考になる解説がありました。
PHPのclass、オブジェクト指向プログラミングに関する質問です。
http://q.hatena.ne.jp/1187962431
↑
2番の回答者の解説が分かりやすいと思いました。
6番の回答者のサンプルコードも参考になりましたが、これは「インターフェース」の利用方法ではありませんね。＞＜
インターフェイス
http://www.phppro.jp/phpmanual/php/language.oop5.interfaces.html
あるクラスが実装する必要があるメソッドの種類を、これらのメソッドの実体を定義することなく、指定するコードを作成できるようになります。
インターフェイスはキーワードinterfaceにより定義され、通常のクラスと同様に定義することができますが、メソッドの実装は全く定義されません。
161 ：: >>159
なるほど！(・∀・)
文字列を扱う処理は、いろんなところで出番がありそうですね！
wikiの文法（表記方法）が使える掲示板とか作れそう＾＾
162 ：: ChStr クラス　の設計はこんな感じかな。
メンバ
private $m_str; // 正規表現文字列を格納する。
コンストラクタ
ChStr($str) // 正規表現の文字列を受け取る。
private メソッド
ch_to_html() // 正規表現をhtmlに変換する。
public メソッド
Write_html() // 格納している文字をhtmlで出力する。
Write_text() // 格納している文字を正規表現で出力する。
---------------------------------------------------
本当は、ログファイルへの保存や読み取りなどを機能として
考え、そのあたりまで含めたクラスの設計をした方が
いいんだろうけれど、まずは簡潔にする方向でいきます。
で、後々拡張の方向で。
163 ：: PHPのインターフェースは、Javaとかのインターフェースとはちょっと違っているみたいですねー。＞＜
（…使ったことないので実感がありませんが＾＾）
PHPでは実装済みのinterfaceを多重に実装できない
http://blog.xole.net/article.php?id=589
http://blog.xole.net/article.php?id=597
164 ：: >>162
こんなかんじのプログラムと似ているかもしれませんねー。
60行で作るPHP用テンプレートエンジン
http://anond.hatelabo.jp/20071030034313
>テンプレートの中身を置換する
>function convert_string($s)
↑置き換えるパターンに応じて、別々のメソッドを用意したら便利でしょうか？
= 文字サイズ変更、''' 強調、link: リンクとかの記法の置換を担当するprivateメソッド
165 ：: OOPの参考になる解説がありました。
関数、オブジェクト、クロージャ
http://d.hatena.ne.jp/brazil/20060131/1138692196
>オブジェクトは、データに処理がくっついたものです。
>array.map()のように、後に後に処理を追加していく書き方は、順にコードを追えるため読みやすく、また書きやすいです。
クロージャっていう仕組みは、PHPにはないですね？＞＜
大は小を兼ねる…クロージャの代わりにオブジェクトが使えればとりあえずOKかな？(・∀・)
166 ：: >>161
>wikiの文法（表記方法）が使える掲示板とか作れそう＾＾
PEARのText_Wiki使えばよくね？
167 ：: >>164
> 置き換えるパターンに応じて、別々のメソッドを用意したら便利でしょうか？
本来ならば、そうなるでしょうね。それらはすべてprivateで作っておいて、
外部には、一つのインターフェースのみ（この例の場合はWrite_html()がそれに該当）
公開となるでしょう。
記号ごとに別々にメソッドを定義しておけば、記号とhtmlの関係が変わる時は、
どのメソッドを触ればよいかが分かるし、それを変更したことで、
他のメソッドには影響は無かったりします。
（これが構造化プログラムの場合は、目的のソースと目的ではないソースを
見極めるところから始まります。）
-------------------------------------------------------------------------
この ChStr に汎用性を持たせる場合は、Write_html()というよりも、
Get_html()とし、html文字列を return する事になるでしょう。
そうすると、別なプログラムで、「出力結果をファイルに保存する」という
使い方も出来ます。しかし、今回は初回なので、Write_html()とし、
メソッド内部で echo 使うことにします。
168 ：: >>166
学ぶために具体的に物を作るのと、実用性を考えて物を作るのは
別だと思う。なので、今回はこれでいいと考えている。
現に、初心者向けの書籍に載っているソースの実用性はゼロだ。
169 ：: とりあえず、全体構成の確認のために書いてみた。
ch_to_html()は、追記の必要性がある。
[chstr.php]
<?php
class ChStr {
// メンバ
var $m_str_reg; // 正規表現文字列を格納する。
var $m_str_html; // html文字列を格納する。
// コンストラクタ
// 正規表現の文字列を受け取る。
function ChStr($regstr) {
$this->m_str_reg = $regstr;
$this->ch_to_html();
}
// private メソッド
// 正規表現をhtmlに変換する。
function ch_to_html() {
// 改行を<BR>に変更する。
// nl2br($this->m_str_reg) 使った方がいいかも
$this->m_str_html = ereg_replace("\n","<BR>",$this->m_str_reg);
}
// public メソッド
// 格納している文字をhtmlで出力する。
function Write_html() {
echo $this->m_str_html;
}
// 格納している文字を正規表現で出力する。
function Write_text() {
echo $this->m_str_reg;
}
}
?>
170 ：: [index.html] 最初に開くファイル。
<html><body>
<form method="POST" action="./text.php"><textarea name="reg_text" cols=40 rows=4>
あああああ
いいいいい
ううううう
</textarea><br>
<input type=submit value="　送　信　"></form>
</body></html>

[text.php]
<html><body>
<?php
include("./chstr.php");
$in_text = $_POST["reg_text"];
$chst = new ChStr($in_text);
$chst->Write_html();
?>
</body></html>
171 ：: >>166
確かにそうなんですが、「勉強のため」という目的もあるので、自分で作ってみるというのもありでしょうか？＾＾
でも、答えが分かっている問題を解くのは楽ですね。＞Text_wiki
車輪の再発明 - Wikipedia
http://ja.wikipedia.org/wiki/%E8%BB%8A%E8%BC%AA%E3%81%AE%E5%86%8D%E7%99%BA%E6%98%8E
車輪の再発明とは、「広く受け入れられ確立した技術や解決法を無視して、同様のものを再び一から作ってしまう事」を意味する
ある技術の意味を理解させるために、意図的に車輪の再発明を行わせる場合がある
172 ：: wikiとか文字列を処理する仕組みは、「パーサー」とか「構文解析」っていうみたいですね（´∀｀）
構文解析 - Wikipedia
http://ja.wikipedia.org/wiki/%E6%A7%8B%E6%96%87%E8%A7%A3%E6%9E%90%E5%99%A8
今までにいろんな仕組みが考えられてきたみたい。
…本格的にやると奥が深そうだけど、一度仕組みを勉強しておいたら、いろいろ使えそうな予感！(・∀・)
↓wikiの仕組みを自分で作っている方は結構いるみたいですねー。
PHP用の汎用WikiParser作り中
http://tdiary.ishinao.net/20050323.html
RandomNote/PHPについて
http://tbox.jpn.org/wiki/rnh/index.php?AboutPage.txt
173 ：: 今後の課題と予定
・ch_to_html() の中身を書く。
・[text.php] の機能を充実（テキストファイルに保存するなど）させ、wikiを作る。
・上記とは別に、 ChStr クラスを使い、BBSを作る。
・ChStr クラスに clear()、SetStr() 等のメソッドをつけ加え、汎用性を持たせる。
174 ：: http://tbox.jpn.org/wiki/rnh/index.php?AboutPage.txt
RandomNoteのMain.phpは参考になるでしょうか？
preg_match
preg_replace
array_push
array_pop
などの関数を使って、文字列の切り貼りをしてるんですねー。
175 ：: OOPってより単にクラスの使い方書いてるように見えるのはまあいいとして
メソッドの中でstringをreturnせずにecho使うのは>>167で書いてるように汎用性って面もあるけど
処理と表示の分離って意味合いもあるからちゃんとstringで返したほうがいいよ
176 ：: >>175
> OOPってより単にクラスの使い方書いてるように見えるのはまあいいとして
OOPについて説明するとなると、具体的なソースコードとは離れた方が
良くなったりしますからね。
（クラスの使い方書いているように見えるとしても、）PHPでclassを
組む場合のメリットみたいな位置づけで学んでいこうと思っています。
> 処理と表示の分離って意味合いもあるからちゃんとstringで返したほうがいいよ
確かに汎用性以外にそういう目的もありますね。
次のものでstringで返すように書き換えます。
177 ：: htmlのformのコードもクラス化するのが本当の流れんだろうけれどな。
いきなりそれをやると分かりにくくなるかな・・・
178 ：: ChStrクラスのサンプルソースを投稿してた者ですが、
今までnobodyさんで書いてたけど、分かりにくくなるかと思ったので
酉入れるようにしてみます。
>>5に書いてあるように、オブジェクト指向は「変数を保持できる事」が
メリットだと思うのですが、これがWebアプリだとどうも実感が無かったりします。
リッチクライアントだと、マウスのクリックに合わせて、メソッドが呼び出され、
そのアプリケーションが終了するまでの間、各種オブジェクトの中の変数に
状態が保持されるという構造なので、そのメリットが感じられるのですが、
Webアプリでは、POSTする度にオブジェクトの変数の状態はリセット
されてしまうので、クラスを書いたとしても、結局はグローバル変数から
各種オブジェクトの変数に代入するみたいなコードを書かなくては
ならなくなってしまうので、このメリットがあるのかと思ってしまうのです。
これは、勉強不足だからなのでしょうか。。。
179 ：: >>160
他の人の話のほうがよっぽど核心を突いてるよ
180 ：: >>160のはてなのリンクの４番目の話、２ｃｈの別の板でも
読んだことがあるけれど、この話本当なの？
具体的に何処でどういう商売をしての話なんだろうか。
アプリケーションを売る話？それとも開発環境用のソフトを売る話？
181 ：: ピュアな意味でオブジェクトを操作したいなら
ボタンのクリックに関する全ての画面遷移に関してserializeとunserializeを管理する必要があるだろ
<?php
require_once("hiroyuki.class.php");
$hiroyuki = unserialize($_SESSION["hiroyuki"]
182 ：: >>178
ユーティリティクラスの再実装みたいな事を熱心にやっても
あまり意味が無いと思いますよ。
まさにあなたの言う「いちいち書くのがめんどくさい」のを回避する為に
OOPがあるんだと思います・・・
OOPの勉強なら、簡単なWEBフレームワークを自作するのが一番良いよ。
知識の無い段階でいきなりPHPでOOPって無理だと思いますよ。
背伸びせず、まずjavaやC#を学習する方が近道かもしれないよ。
183 ：: .NET 以降の VisualBasic ってどうなの？
184 ：: MVCモデルにそって、ユーザの入力データと、CSVファイルのデータを
読み込んで表示させるというものを作ってみました。
ファイル：全部で５つ。index.phpを実行する。
cfcontrol.php
cfview.php
index.php
cfmodel.php
csv.txt
[csv]
aaa,bbb,ccc
[index.php]
<?php
include("./cfcontrol.php");
$form_str = $_POST["form"];
$in_str = $_POST["key"];
$form = new CFControl($form_str, $in_str);
?>
185 ：: [cfcontrol.php]
<?php
include("./cfview.php");
include("./cfmodel.php");
class CFControl{
function CFControl($form_str, $in_str){
if( ($form_str == "")or($form_str == "in") ){
$form = new CFView("index.php","in","");
$form->Write_HTML();
}elseif($form_str == "out"){
$da = new CFModel();
$dat = $da->ReadDat($in_str);
$form = new CFView("index.php","out", $dat);
$form->Write_HTML();
}
}
}
?>
186 ：: [cfmodel.php]
<?php
class CFModel{
var $m_csv_file;
// コンストラクタ
function CFModel(){
// 読み込むCSVファイルを指定
$this->m_csv_file = "csv.txt";
}
// データを取り出す。
function ReadDat($str){
$INFILE = fopen($this->m_csv_file,"r");
$line = fgets($INFILE, 1024);
fclose($INFILE);
$line = $line . ", " . $str;
return $line;
}
}
?>
187 ：: [cfview.php]（１／２）
<?php
class CFView{
var $m_file; // POSTするファイル名
var $m_type; // 表示するフォームの種類。in か out
var $m_line; // 表示するデータ
// コンストラクタ
function CFView($file, $type, $line){
$this->m_file = $file;
$this->m_type = $type;
$this->m_line = $line;
}
// private
function in_html(){
echo "<html><body>";
echo '<form method="POST" action="' . $this->m_file . '">';
echo '<input type="hidden" name="form" value="out">';
echo '<input type="text" name="key"><input type="submit" value="送信">';
echo "</form></body></html>";
}
188 ：: [cfview.php]（２／２）
// private
function out_html(){
echo "<html><body>";
echo '<form method="POST" action="' . $this->m_file . '">';
echo '<input type="hidden" name="form" value="in">';
echo "$this->m_line<br>";
echo '<input type="submit" value="戻る"></form></body></html>';
}
// public
function Write_HTML(){
if($this->m_type == "in"){
$this->in_html();
}elseif($this->m_type == "out"){
$this->out_html();
}
}
}
?>
189 ：: フレームワーク使えば？
190 ：: とりあえず、MVCに分けて枠組みを作ってみたけれど、
これをより抽象化させていって、「継承して使ってください」という
方向にするのか、それとも最初はクラスの数を増やさないように
しながら簡単なアプリケーションを作る方向にするべきか。
どっちの方向に持っていったほうがいいのか迷うな。。。
ま、そんなことを考える暇があったら手を動かしてみろという
話なのかもしれないが。。
191 ：: >>190
自分で考えるのも良いが、君が今やっていることを
やってしまっているのが、フレームワークだ。
まず既存のフレームワークがどうなっているのか参考しろ。
192 ：: 俺も初心者だからこれが最善とは言い切れないけど
newするときに全部引数で渡すってのはナシじゃね？
分かりやすいところだけ書き出すと
[index.php]
$form = new CFControll();
[cfcontrol.php]
コンストラクタ()
{
　$form_str = $_POST['form'];
　$in_str = $_POST['key'];
　if(inだったら){
　　$view = new CFView();
　　$view->m_type = 'in';
　　$view->Write_HTML();
　}
}
[cfview.php]
メンバ変数
var $m_file = 'index.php';
var $m_type = false;
var $m_line = null;
193 ：: フレームワーク使ってみろっていうのは賛成
疎結合にとかDRYにっていうのがだんだんわかってきた
理解したところで戻ってきて～の方が結果的に早そう
俺はまだ勉強中だからそこまで行ってないけど
194 ：: >>192
> $view = new CFView();
> $view->m_type = 'in';
これみたいに、直接メンバにアクセスするのは構造的に良くないと聞いたことが
あるよ。「データをやり取りするのは、インターフェースを通じて」という原則を
守るべきだと。
そうしなければ、CFViewクラスを改変する人は、そのクラスを使っている人の
コードを考慮して、メンバの値や変数名を自由に変える事が出来なくなるから。
なので、私は、コンストラクタで値を渡しても良いし、コンストラクタで値を渡して
いなければ、値を渡すためのインターフェースを使って渡すようにする仕様が
適当かなと思っている。
195 ：: 汚染されちゃうけどコンストラクタで全部の値渡すよりはましじゃないかなあ
あとコンパイルするときに全部チェックしてくれる言語とそうじゃない言語ってのもある
phpなんだしゆるーくやればいいじゃん　なんていうと怒られるかｗ
196 ：: 今調べて知ったのだが、オーバーロードは PHP ではできないらしい。
だったら、コンストラクタで値を渡すよりも、インターフェースで値を
設定するような仕組みになるだろうね。
コンストラクタだと、一度値を設定したら、そのオブジェクトが破棄される
まで、再度設定が出来なくなるから。
197 ：: メンバ変数へのアクセスはsetter/getterを使う。これは議論の余地なし。
それを用意した上でコンストラクタに引数を渡すなら渡せば良い。
複雑で多くの設定をしなきゃならない時以外、
newした直後に使える状態になっている方が使いやすい。
> $view = new CFView();
> $view->m_type = 'in';
これをセットで書かなきゃならないなら、
> $view = new CFView('in');
と書きたい。
198 ：: 私は>>197さんの意見に同意だ。
「このモジュールを使う場合、このように書いてくださいね。」
というコードは、なるべく少ない方がいいからね。
なので、とりあえず設定の値はコンストラクタにいれるという
設計で書いてみた。
199 ：: とりあえず、フレームワークを使ってみろという話が出ているが、
具体的にどのフレームワークを使って、どんなプログラムを書いて
みたらいいのか迷うなぁ。
とりあえずはこのあたりに載ってるものの、「和モノ」あたりからかな。
http://pc11.2ch.sc/test/read.cgi/php/1197383840/3
フレームワーク自体の自作の話もいくつかあるみたいだ。
ttp://codezine.jp/a/article.aspx?aid=104

200 ：: viewに渡すデータはセッタで渡したくならない？
あとinなのかoutなのか分岐させるとしたらそれはコントローラ側の仕事なんじゃないかなと思うんだけど違うかな
201 ：: いや、見直したらそう書いてた
ごめん気にしないで
202 ：: >>200
> viewに渡すデータはセッタで渡したくならない？
表示させるデータはセッタがいいだろうね。
> あとinなのかoutなのか分岐させるとしたらそれはコントローラ側の
> 仕事なんじゃないかなと思うんだけど違うかな
>>185のソースがそれにあたるものだと思ってたけど。
if( ($form_str == "")or($form_str == "in") ){
　省略
}elseif($form_str == "out"){
　省略
}
コントローラは、POSTしてきた値を見て、必要なModelやViewを
選択し、実行する役割なので、それを実現したつもり。
203 ：: 厳密にMVCを分けることは出来ない場合もあるということだけど、
CFControlクラスで、CFViewを使って表示する内容までもを
指定していする処理を書いていたのは間違いかな？
検索結果の表示や、データの更新の場合は、
Control→Model→View　だけど、
ボタンを押した時の画面の展開のみの場合は、
Contol→View という流れとなり、Viewオブジェクトを
生成するクラスが異なるという処理でいいのかな？
204 ：: 「とりあえずはフレームワークを使ってみろ」という返事がきそうだけど、
各クラスの役割は以下のような感じでいいかな？
Control
・POSTでデータを受け取り、その値に不正なものが無いかをチェック。
・変なところからのアクセスではないかをチェック。
・$_POST["Form"]の値をみて、それに必要な画面と処理を判断する。
Model
・SQLを発行し、データを受け取る。
・データをViewクラスに渡す。
View
・フォームを表示する。（フォームごとにクラスを分けたほうがいいのかは迷うな）
・データを１件受け取り、tableタグでレイアウトを調整し、表示する。
205 ：: とりあえずはフレームワークを使ってみろ
206 ：: 自分なりに調べて見つけたPHPのサンプルを使った解説ページも
読むとwebアプリについて学べるのではないかと思っている。
やることが多くなったけれど、とりあえずは以下の３本だてで
勉強してみることになるのかな。
MVCに分けて、簡単なアプリを自作する。
（ログイン、メニュー、検索条件指定、検索結果、データ編集などの画面があるもの）
和モノフレームワークを使って学ぶ。
簡単なアプリを自作する。
http://pc11.2ch.sc/test/read.cgi/php/1197383840/3
サンプルで理解！フォームデータの受け渡し
ttp://www.atmarkit.co.jp/flinux/rensai/mysql5_03/mysql5_03a.html
207 ：: ちいたんのソース見てみたけれど、
class CObject　ってあって、必ずそれが継承されて作られてるよね。
これの都合って何なんだろう。（メリットは何？）
javaも.NETもこういう基本クラスがあるよね。
208 ：: 全部のクラスに共通するメソッド等が実装できる
209 ：: >>208
サンクス。
でも、オーバーロードが出来ない場合は逆に足かせになる可能性もあるね。
例えば、継承されているクラスが沢山ある状況でObjectクラスに
メソッドを追加する場合とか。
210 ：: 喋るのはコントローラとモデル
コントローラとビュー
基本的にはね
211 ：: 少ない数のクラスを書いたり読んだりする程度であれば、すぐに分かるのだが、
フレームワークレベルのクラス構造となると、その構成が全く分からなくなって
来るんだよなぁ。何かコツのようなものはあるのかな？
処理の内容を追いかけると、次々に別のクラスに処理を渡す構造になっていて、
最後はあっけない、みたいな感じだ。
フレームワークを作る場合のクラスの設計手法を身につけるなどしないと
いけないのかも。
メンバに定義はしていないけれど、メソッドではその変数をエラーが
出ないように処理が書かれているっていう書き方は多いようだ。
そうしておけば、そのフレームワークを使う人は、クラスを継承して
メンバに値を代入するだけで良い。
212 ：: このサイト、説明は分かるのだが、具体的に作っているコードは
MVCのうちどれにあたるのかがいまいちです。
ttp://www.stackasterisk.jp/tech/php/phpMvc01_01.jsp
Result.php は、Viewにあたるものという解釈でいいんですよね？
213 ：: PHPでMVC関連のサイトを紹介で貼っておきます。
特集：第3回　PHPを思うままに操れるようになる「MVC」と「Smarty」 (1/4)
ttp://www.itmedia.co.jp/enterprise/0402/19/epn01.html
214 ：: 2004年って･･･････
215 ：: OOPに取り付かれている人のブログ
ハタさんのブログ : : php
http://blog.xole.net/category.php?k=php
216 ：: PHPでね、イベントドリブンなWEBフレームワークとか自作してみるといいかも。
例えば、サブミットボタンの処理ハンドラがオーバーライドで記述可能で
そこでフォーム値をモデルに渡して処理させるみたいなやつ・・
「POST」や「GET」とかローレベルの概念は全て隠蔽されてて
フレームワークにイベント発生時のロジックだけ記述して終わりみたいなの・・・
そしてPHPであれこれ試行錯誤したあと、ASP.NETとか参考にするとね
PHPでOOPするバカらしさに気付くかもしれない・・・OTL
217 ：: ASP.NET は、ちょっとだけやってみたことあるけど、概念的に違和感が
あって、やらなくなったな。
ある程度Webアプリを学んだ事のある人には便利なんだろうけれど、
初めて学ぶ人には、ドキュメントが少なすぎだし、いきなりイベントドリブンで
やるのはどうかと思った。
で、まずは、Webアプリの基礎をやるという意味合いでPerlをやってみた。
で、今はPHPをやっている。PHPそのものがOOPに完全な対応をしていない
ので、これで大規模なアプリを組むことも無いかなと思っている。
対応したとしても、それからノウハウが出てくるので、さらに数年先になる。
でも、学ぶ時は、既存のモジュールを使って早くやるのよりも、モジュール
なしの状態で、モジュールを作ってみる方がいいので、とりあえず今は
PHPでOOPです。
218 ：: >>217
多分、その違和感のある概念がOOPの本質だと思うよ。
そしてその概念は、洗礼された実装に触れることでしか
身につかないとも思うんだ。
初心者こそイベントドリブンを真っ先に学習したほうがいいよ。
最終的に、理解し易く安全な実装方法に結びつくと思うからね。
PHPでOOPで実装ってケースはありだとは思うけど、
概念は別で学習した方が効率的だと思うんだ。
219 ：: OOPに取り付かれているとか良くわからんｗ
普通にプログラミングしていると使うだろ？
switchに取り付かれているとかそういうレベルに聞こえるんだが。
220 ：: MVCモデルでプログラミングする場合、Model から View へ処理を渡す経緯は、
どっちが正しいのかな？
・Control クラスのメソッド内で、Model クラスと View クラスのインスタンスを生成する。
　Control クラスが、Model からデータを受け取り、View クラスへデータを渡し、
　描画指示を出す。
・Model クラスのメソッド内で、View クラスのインスタンスを生成する。
　Model クラスが、Viewクラスへデータを渡し、描画指示を出す。
　Control クラスは、View クラスを一切操作しない。
それとも、こういうところまでは理論的には定めていないので、
ケースバイケースであり、どちらがよいというものは無いということかな？
221 ：: お前は何を言ってるんだ
222 ：: PHPでイベントドリブンですか？(・∀・)
…こんなのありました。＾＾
PHP イベントドリブンに一致する日本語のページ約 10,600 件
●PRADO
http://www.pradoframework.com/wiki/index.php/Ja:What_is_PRADO
>PRADO はコンポーネントベースかつイベントドリブンなウェブアプリケーションを開発するためのPHP5フレームワークです。
●S2Prado.PHP5
http://labs.s2php5.jp/s2prado.php5
http://blog.xole.net/article.php?id=553
>S2Baseの方は待望のPRADO対応。
●Piece Framework
http://trac.piece-framework.com/piece-unity/wiki/ja/Start
>Piece_Unityは、Visual BasicやDelphiのようなイベントドリブンなフレームワークです。
●Delphi for PHP
http://www.codegear.com/jp/products/delphi/php
http://orz.qzlab.com/yamagw/index.php?Delphi%20for%20PHP%A4%CE%BB%C8%A4%A4%CA%FD
>イベントドリブンなロジックの実装が容易に実現する。
●Pharon
http://pharon.lolipop.jp/
>最大の特徴は、wizard によりイベントドリブン型のスケルトンを自動作成することです。
223 ：: インターネット越しにイベント処理をさせるのが、WEBプログラミングの特徴ですね。
イベントドリブンは、PHPよりもむしろFlash/Flexとかで使われる仕組みなのでしょうか？
レガシーの中心でのOOP
http://kaede.to/~canada/doc/2005/07/06/
>Webプログラミングにおいて、ブラウザとのやり取りがレガシー（古典的）なデータ交換に過ぎず、これがWebプログラミングを難しくしている
>Webは1ページごとに毎回セッションが起動し、ドキュメントを表示するとすぐ終了する。
>オブジェクト指向プログラミングにおける利点の1つであるイベントドリブンなプログラミングは不可能だ。
>何しろ1セッションに1イベントしか発生しないのだから。
>と同時にセッション状態を保存する必要も出てくる。
http://www.adobe.com/jp/devnet/flex/articles/framework_beta_print.html
>インタラクティブ性に優れたイベントドリブンなインタフェイス
http://www.atmarkit.co.jp/fwcr/rensai/flex203/01.html
>イベント処理によってアプリケーションを構築する手法はイベント駆動型（イベントドリブン）と呼ばれます。
http://www.azul.systems-noel.jp/item_9.html
>Flex2はイベントドリブンなので、ビューに起こったイベントをコントローラのリスナでキャッチするように意識すれば、MVCの分離はきれいにできるようになっています。
>なんかほんとにJavaのSwingを使ってるような気分になりますね。
http://bitmap.dyndns.org/blog/archives/001215.html
>イベントドリブンモデルには、主に以下の 4 つのオブジェクトが登場する。
224 ：: >>220
>・Control クラスのメソッド内で、Model クラスと View クラスのインスタンスを生成する。
こっちの方が、Controlにまとまっている分だけスッキリしており、分かりやすいコードになるんじゃないでしょうか？
225 ：: >>224
レスありがとうございます。
１番目の方にすると、Modelクラスから取得したデータを
Viewクラスに渡すことになるので、その分余計にメモリや
CPUを消費してしまうのでは、と心配になって聞いてみましたが、
考えてみると、コードの見易さなどを優先するのがOOPですので、
そちらの方がいいですね。
でも、フレームワークのソースなどを見ていると、
各クラスが、メンバに、別のクラスへのリファレンスを持ってたり
するので、もっと理論に従った組み方があるのかも、と思っています。
226 ：: >>184
ファイル：全部で８つ。index.phpを実行する。
抽象クラスと具象クラスに実装を分けてみました。
csv.txt(※前回と同じ)
index.php
cfcontrol.php
アブストラクトとして実装
cfview.php
cfmodel.php
コンクリートとして実装
data_model.php
index_view.php
output_view.php
227 ：: [config.php]
<?php
// 実際の処理を行うスクリプトをインクルード
include("./index_view.php");
include("./output_view.php");
include("./data_model.php");
// 最初に呼ばれるビューのプレフィックス設定
define ('INDEX_VIEW_PREFIX', "Index");
// モデルクラスのプレフィックス設定
define ('MODEL_PREFIX', "Data");
?>
[index.php]
<?php
include("./cfcontrol.php");
$view_key = $_POST["view_key"];
$data = $_POST["data"];
$app = new CFControl($view_key, $data);
$app->Execute();
?>
228 ：: [cfmodel.php]
<?php
class CFModel
{
var $file_name; // 読み込むファイル名
function CFModel() {}// コンストラクタ
function Execute($param) // パブリックメソッド
{
return $this->_OnExecute($param);
}
function _OnExecute($param) // 仮想メソッド
{
trigger_error('オーバーライドしてね。', E_USER_ERROR);
}
}
?>
[cfview.php]
<?php
class CFView
{
var $file_name; // POSTするファイル名
function CFView() {} // コンストラクタ
function Execute($param) // パブリックメソッド
{
return $this->_OnExecute($param);
}
function _OnExecute($param) // 仮想メソッド
{
trigger_error('オーバーライドしてね。', E_USER_ERROR);
}
}
?>
229 ：: [cfcontrol.php]
<?php
include("./cfview.php");
include("./cfmodel.php");
include("./config.php");
class CFControl
{
var $_view_key; // 呼び出すビューのプレフィックス
var $_data; // モデルに渡すデータ
function CFControl($view_key, $data) // コンストラクタ
{
$this->_view_key = $view_key;
$this->_data = $data;
}
function Execute() // パブリックメソッド
{
// モデルオブジェクト動的生成
$model_class_name = MODEL_PREFIX . 'Model';
$model = new $model_class_name();
$param = $model->Execute($this->_data);
// ビューオブジェクト動的生成
$view_key = $this->_view_key;
if ($view_key == "") $view_key = INDEX_VIEW_PREFIX;
$view_class_name = $view_key . 'View';
$form = new $view_class_name();
$form->Execute($param);
}
}
?>
230 ：: [data_model.php]
<?php
class DataModel extends CFModel
{
function DataModel() // コンストラクタで取得先のファイル設定
{
$this->file_name = 'csv.txt';
}
function _OnExecute($param) // オーバーライドメソッド
{
$INFILE = fopen($this->file_name,"r");
$data = fgets($INFILE, 1024);
fclose($INFILE);
$data = $data . ", " . $param;
return $data;
}
}
?>
231 ：: [index_view.php]
<?php
class IndexView extends CFView
{
function IndexView() // コンストラクタでPOST先のファイル設定
{
$this->file_name = 'index.php';
}
function _OnExecute($param) // オーバーライドメソッド
{
echo "<html><body>";
echo '<form method="POST" action="' . $this->file_name . '">';
echo '<input type="hidden" name="view_key" value="Output">';
echo '<input type="text" name="data"><input type="submit" value="送信">';
echo "</form></body></html>";
}
}
?>
232 ：: [output_view.php]
<?php
class OutputView extends CFView
{
function OutputView() // コンストラクタでPOST先のファイル設定
{
$this->file_name = 'index.php';
}
function _OnExecute($param) // オーバーライドメソッド
{
echo "<html><body>";
echo '<form method="POST" action="' . $this->file_name . '">';
echo '<input type="hidden" name="form" value="Index">';
echo "$param<br>";
echo '<input type="submit" value="戻る"></form></body></html>';
}
}
?>
233 ：: >>226-232
サンプルソースありがとうございます。
抽象クラスの書き方に慣れてますね。私はこのあたりを
しっかりとやってなかったのでちょっと苦手です。
ま、しっかりと勉強していきたいと思います。(^^;
ソースを読んでいて、１点気になったので質問をしたいのですが、
class CFView と class CFModel において、以下のように
パブリックメソッドと仮想メソッドを作り、パブリックメソッドから
仮想メソッドを実行する形式にソースを書いた理由は何でしょうか？
出来ましたら、この設計にした意図を教えていただきたいと思います。
function Execute($param) // パブリックメソッド
{
return $this->_OnExecute($param);
}
function _OnExecute($param) // 仮想メソッド
{
trigger_error('オーバーライドしてね。', E_USER_ERROR);
}
234 ：: >>218
レスありがとうございます。
イベントドリブンそのものは、VBでWindowsアプリを組んでやったことがあるので
すぐに入れたのですが、Webアプリを作る際、イベントドリブンでしかやった事が
無いというのは致命的だと思ったので、PerlやPHPでやってみています。
（ASP.NETは、便利ではあるが、IISを使えとか、.NET Frameworkを使えとか
非常に限定される。）
構造化プログラミングで、あまり命名規則を考えずにプログラムをしていると、
グローバル変数や関数が多くなった時、その把握が出来なくなったりする
わけなのですが、そういう苦労する体験をした後、OOPを習うと、その便利な部分が
見えてくるわけです。OOPは経験による結論的な理論だな、と理解できるわけです。
その理解のために、とりあえず、苦労をする方法（PHP で 0 から OOP）で
やってみているのです。
今は、このように考えています。
235 ：: 人間て暖かいにゃぁ
ﾎﾟｶ･ﾎﾟｶ　テンキュー
236 ：: >>233
PHP4では全てパブリックだけど例えばC#では以下の実装になるんだ
public object Execute(object parpam)
protected virtual object _OnExecute(object parpam)
CFControlから_OnExecuteメソッドを隠蔽する意図なんだよ。
_OnExecuteはCFViewやCFModelのサブクラスにだけ見えれば十分なんだ。
237 ：: >>235
暖かいですねぇ。

>>236
なるほど。ありがとう。
238 ：: ソースを読んでいて気になった点がありますので、質問させていただきます。
includeの構成についてです。まず、各ファイルに書かれているincludeの部分をまとめます。
[index.php]
include("./cfcontrol.php");
[cfcontrol.php]
include("./cfview.php");
include("./cfmodel.php");
include("./config.php");
[config.php]
// 実際の処理を行うスクリプトをインクルード
include("./index_view.php");
include("./output_view.php");
include("./data_model.php");
これは、MVCフレームワークは、以下の３つのファイルであり、
[cfcontrol.php][cfmodel.php][cfview.php]
それを拡張する形で、残りの６つのファイルを付け加えた形
なので、このようなincludeの構成ということでよろしいのでしょうか。
239 ：: includeをばらばらとさせるよりも、以下のように整理したほうが
となんとなく思ったりもしたのです。
[index.php]
include("./config.php");
[config.php]
include("./cfcontrol.php");
include("./cfview.php");
include("./cfmodel.php");
include("./index_view.php");
include("./output_view.php");
include("./data_model.php");
240 ：: MVC?な俺にはここが一番わかりやすかった
実例コードが載ってるのがいい
PHPでMVC第1回：前編
ttp://www.stackasterisk.jp/tech/php/phpMvc01_01.jsp
241 ：: javaのサイト見ろよ
242 ：: やけに伸びるな
243 ：: ソースコードをちょっとだけ改変したものを作ってみた。
メモとかを残していく都合もあると思ったから、ＨＰ解説してみた。
ttp://www.geocities.jp/narutobakijp2/
本当は、>>1さんがソースの管理とかもしてくれたりしたら、うれしいｗ
244 ：: いちいちzipを解凍する気にならない
245 ：: >>243
CFViewクラスに具体的な実装をしちゃダメなんだよ。
そもそもHTMLのフォーム処理とかは、あとでPEARとか使えばいい。
サブクラスをうまく呼び出す仕組みだけを実装していくんだ。
246 ：: >>244
> サブクラスをうまく呼び出す仕組みだけを実装していくんだ。
ｋｗｓｋ
247 ：: >>246
構造化プログラミングはルーチンを呼ぶ方向で実装すると思うけど
OOPではルーチンに呼ばれる方向で実装して行く感じだよ。
大枠の骨組みだけを抽象クラスで作成して、処理は具象クラスで行うんだ。
インターフェイスさえ同じならあとで個別にパーツを交換出来たりするからね。
だったら基底クラスのメソッドなんて数個で十分じゃないかと思うんだ。
やたら複雑でよくばりな機能のクラスなんて、再利用の価値がないからね。
248 ：: >>247
レスありがとうございます。
> 構造化プログラミングはルーチンを呼ぶ方向で実装すると思うけど
> OOPではルーチンに呼ばれる方向で実装して行く感じだよ。
私は、継承を活かした設計をした事が無かったので、ちょっと方向性を
誤ってしまったようですね。
Viewは、表示をつかさどるのだから、html表示を請け負うのでは、と
思っていたのですが、それよりも抽象的な枠組みを定義するという
ことですね。
となると、html表示は（PEARを使わないのであれば、）htmlタグの
記述を行うCF_HTMLクラスを作り、Viewの具象クラス内で
インスタンスを生成ということですよね？
249 ：: >>248
HTML処理のヘルパクラス作成はあまりOOPの勉強にならないとも思うんだ。
もう既に頭の中で実装出来ているだろうし、引数を関数で処理するだけでしょ？
それよりも例えばPEARのHTML_QuickFormやテンプレートレンダラのSmartyを
Viewと連携させる仕組みとかを考えたりした方がよっぽど面白いよ。
すべてをフルスクラッチするプログラミングの方向性は必ずしも得策じゃないよ
既存のライブラリやコンポーネントを上手く利用するのもOOPの要素なんだよ。
250 ：: 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
251 ：: >>250
PHPのプログラマにも非常に参考になると思いますよ。
.NETの世界はクラスベースなので初めからOOPの思考で実装します。
関数が作れないので構造化思考のVB6プログラマとか、クラスをnewせずに
引数を大量に渡すスタティックメソッドを呼んだりしてしまいます・・・
PHPはC言語での関数モジュールを呼び出す実装スタイルに近いので
やはりクラスを使って構造化プログラミングをしちゃいがちですね。
普及しているPHP4がOOP対応不十分なのと、開発環境が貧弱であることも
PHPでOOPがなかなか利用されない原因になってたりしますよね。
プロテクテッドメソッドの概念とかIDEがないと、なんでそうするのか
なかなか理解出来ないとも思いますしね。
252 ：: いくらかのデータを登録し、その内容を検索するWebシステムで使用する
クラス構成で、Viewに絞った構成を考えてみた。
[View]
├[認証]
├[個人情報入力]
├[メニュー]
├[検索指定]
├[検索結果]
別の案として、[View]から[Input View]と[Output View]の
二つを継承し、さらに以下のような継承も浮かんだけれど、
継承して分ける必要性は無さそうなので、上記の方が良いように思う。
[Input View]
├[認証]
├[個人情報入力]
[Output View]
├[メニュー]
├[検索指定]
├[検索結果]
253 ：: >>252
[View]
├[LoginView]
├[InsertView]
├[MenuView]
├[SelectView]
├[ResultView]
こんな感じ？
254 ：: Debug用出力のメソッドをView（基底クラス）に追加するといいだろうね。
各画面（[LoginView] [InsertView] [MenuView] ・・・）で
エラー確認用のメソッドをオーバーロードする形で。
開発中はPOSTで受け取ったデータとかを画面上部に表示しながら動作確認する
っていうのは、よくやるからね。
Objectクラスを継承する形にするのは、このスレでは共通したメソッドの
実装という理由だ。という話だったけど、リファレンス関係の処理で
便利だという話がサイトに載っているようだね。
このあたりの考え方も活かすと良いかもしれない。
ただ、PHPのOOPだとうまく実装出来ないかもしれないが。
>>207-209 >>250
255 ：: Modelクラスも以下のメソッドを追加するという感じで設計すると良いのかな。
Select // データ取り出し
Delete // 削除
Insert // 新規追加
Update // 既存データの更新
>>228に載ってる既存のクラスには Execute があるけれど、
これも残しておくべきかな？
256 ：: 案がいくつか出てきたので、前回の駄目なソースを破棄して
またソースコードをリニューアルしようかと思ったが、
いざやり始めてみると、データベースを管理する基底クラスの
設計を具体的にどうするかをきめないといけなくなり、それを
どうするかで迷っている。。。
概ね以下のような感じにしたいと思ってるんだけどね。
DB格納の基底クラス：CFDB
テキストファイルに保存するクラス：Text_DB extend CFDB
PostgreSQLに保存するクラス：PostgreSQL_DB extend CFDB
MySQLに保存するクラス：MySQL_DB extend CFDB
で、この３つのいずれかのインスタンスを Model のメンバに持たせる。
現在のコード（CFModelのメンバ）
var $file_name; // 読み込むファイル名
更新案のコード
var $m_db; // データベースを格納。
257 ：: >>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のアプリ作成に必要な要求仕様作ってよ。
258 ：: >>257
要求仕様案
私は眼鏡屋（○○支店の店長）をやっている。
顧客の情報（名前、住所、性別、生年月日、・・・）を管理したい。
・眼鏡を購入した顧客の情報を登録しておき、ある一定期間経つと
新しい眼鏡を購入する案内のＤＭを発送したい。
→条件検索をしたい。
・登録した情報を検索し、どんなお客様かをすぐに確認出来るようにする。
→例えば、苗字を聞いて、詳細が分かるようにする。
・眼鏡の定期的なメンテナンスで、訪問してきたら、その対応履歴を
登録しておきたい。
→眼鏡のクリーニング、シリコンパッド（鼻にあてるやつ）の交換など
・定期的なメンテナンスは無料であるので、全く店に来ない客には、
その無料案内のＤＭを発送したい。
→今回は、複数の店舗にまたがった処理はいらない。
・他の社員に勝手に情報を触られないように、認証を通すようにする。
眼鏡の在庫管理は、このシステムとは別。
これは、プログラムの規模が大きくなりすぎるようであれば、
もちろん内容を変えてもいいです。「顧客の情報を登録し、
それを検索する」という流れだと、勉強用サンプルとして非常に
良いのでは、と思いました。
259 ：: [データの入力例]
氏名：茂名
フリガナ：モナー
性別：男性
生年月日：H1/3/3
住所：東京都・・・
コメント：ふちなしタイプを希望している。
眼鏡購入日：2007/1/5
眼鏡の型番：2ch
[2007/1/5に購入した2ch]のメンテナンス履歴
2007/2/5：クリーニング
2007/3/15：ネジの交換
2007/5/1：クリーニング、曲がったフレームの修正

顧客のデータ１件に、眼鏡の購入日がつながり、さらに、メンテナンス履歴が
つながる構成になるけれど、今回は勉強用なので、「顧客のデータ１件＝眼鏡の購入日１件」
としてもいいかもね。
再度購入したら、顧客の個人情報を０から入力しなおすみたいな。
260 ：: View の Debug メソッドの仕様もどうするかで迷っている。
Execute($param)したあと、Debugとか、もしくは、
Debugの中でExecute($param)を呼び出す処理だと、
<html>タグのそとに確認データが出力されてしまう。
Debug モードを on にすれば、<body>タグの上部に
テーブルで区切ってデータが表示されるとかかな。
だったら、メンバにDebugモードを追加かな。
という感じに考えてる。
みんなどう思う？
261 ：: >>258
ちょっとしたシステムじゃん・・ (´･ω･)
それこそ既存のフレームワーク使用する案件だよ。
>>260
ディレクティブ付けたechoやvar_dump埋め込みで十分だと思うよ。
むしろその機能を実装するより、デバッガ環境構築した方がいい・・・
OOPに対する基本的概念への理解があまりにも無さ過ぎると思うんだ。
>>255にしても、Executeメソッドに呼ばれる仕組み作ってんのに、
なんで新しいメソッド実装して直接呼びたがるんだろう？
あれほどインタフェイスだけで実装するんだと（ｒｙ
それよりコントローラの実装仕様どうするの？
262 ：: >>243
>ttp://www.geocities.jp/narutobakijp2/
↓動作サンプルを設置しました。
http://ssurl.net/so2o
↓コードに関するコメントのまとめ（>>184-226辺り）
http://ssurl.net/h8bu
263 ：: >>262
非常に乙です。m(_ _)m
>>226だけど　>>1さんにここまでやって貰っちゃって申し訳ないし
これぞOOPってサンプルを必死に実装してアップするんでしばしお待ちを・・
264 ：: >>263
はやくアップしろよなｗ
俺がそれ見て勉強して、いつかエロイ人になったら
お前を雇ってやるよ！　感謝しろ
265 ：: >>262
動作サンプルまでつけていただいて、ありがとうございます。
過去ログも、そのままコピペするんじゃなくて、色をつけたり
分類したりすると非常に分かり易いですね。
ShiftJISだったりとか、スペース2個というのは標準じゃないとかは
気づいてたのですが、そこまで治していただいて申し訳ないです。
266 ：: MVCって難しいね。
267 ：: >>266
別にわかんなくったって、やってけるから大丈夫。
無理に背伸びする必要は無い。
268 ：: フレームワークの解説に関するサイトを見つけました。
ここで概要をつかんだ後、実際に触れてみるといいかもしれない。
ASP.NET vs. Struts
フレームワーク徹底比較［前編］
http://www.atmarkit.co.jp/fdotnet/special/aspstruts01/aspstruts01_04.html
この文章書いてる人、ネットワーク関連の書籍でよく見かけるよね。
269 ：: >>261
> OOPに対する基本的概念への理解があまりにも無さ過ぎると思うんだ。
> >>255にしても、Executeメソッドに呼ばれる仕組み作ってんのに、
> なんで新しいメソッド実装して直接呼びたがるんだろう？
> あれほどインタフェイスだけで実装するんだと（ｒｙ
ちいたんのフレームワークは、Modelにinsertやdelを持ってるからそれを
参考に設計してみたんだけど。
ttp://php.cheetan.net/manual/model.php
俺はこれから勉強していくところなので理解がないのは認めるが、
このあたりはどういう見解なのかを教えて欲しい。
今回作るMVCフレームワークは、学習用なのでもっと簡潔な
レベルなのを想定しているとか、ちいたん作っている人がOOPに
関する理解が無いだけだとか。
270 ：: >>269
フレームワーク実装に正解も不正解も無いと思うけどね・・
例えば
・クラスを使った構造化的メソッド呼び出し
$model->insert();
$model->del();
よりも
・ポリモーフィズム
$insert->execute();
$del->execute();
のほうがインターフェイスが規定されていて
簡潔で安全だと説明したかったんだよ。
insertメソッドやdelメソッドを呼ぶ文脈が規定されていたらどう？
insertオブジェクトのexecuteメソッドならオブジェクトが
文脈をコントロール出来るでしょ？どうかな？
学習用だからこそ『呼ばれる仕組み』で実装しようとしているんだよ。
271 ：: >>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);
}
}
272 ：: じゃ、用件仕様はこんな感じで良いのか？
[認証]
→・ID、パスワードにて認証
　・認証成功で[メニュー]へ移動
[メニュー]
→・（新規）[個人情報入力]、[検索指定]画面へ移動するボタンがある
[個人情報入力]
→・名前、性別　を登録
[検索指定]
→・氏名のキーワードを含む検索、性別指定が出来る。
[検索結果]
→・条件に一致するデータを一覧で出す。
　・個人情報を修正したい場合は、ここから[個人情報入力]へ移動する。
　・個人情報を削除したい場合は、ここで削除ボタンを押す。
273 ：: >>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];
}
}
?>
274 ：: [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);
}
}
275 ：: [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;
}
}
?>
276 ：: 細かい指摘になるけれど、継承関係の勉強中なので質問で書き込みします。
[InsertModel.php]
class InsertModel extends DataModel
function & _onExecute(&$param) 　のところは、
return $this->_OnInsert(&$param); 　となっているけれど、
return $this->_onInsert(&$param); 　が正しいという解釈で良いのですよね？
277 ：: >>273-275
ソースのサンプルサンクス。
イメージしてたよりも継承が多いですね。
全体ソースコードの可読性よりも、クラス単位での
再利用性を考えた場合は、このような構成になる
のでしょうね。早く慣れないといけません。
278 ：: まだ中身が出来ていない状況なので、修正の必要はあるだろうけど、
こんな感じでドキュメントもまとめていくと、分かりやすくなるだろうね。
■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に書き込む。
279 ：: >>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
280 ：: >>279
乙です。じっくりソースを読んでみます。
281 ：: せっかくプログラムを作っていただいたのだから、みんなでその説明文章をまとめるといいかもね。
例えば、こんな感じで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
282 ：: >>281
>>279ですがphpDocumentorで今作っているのでちょっと待っててね。
283 ：: 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を実装したつもりです・・・
有名なハリウッドの法則です。
[カプセル化]は良いとして、やはり[継承]と[ポリモーフィズム]を
うまく使うのは最初難しいかもしれない・・
これらの実装もデザパタとしてライブラリ化されたものに過ぎないけどね。
284 ：: ファイルが見れん・・・
285 ：: 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が反映されてませんでした。
286 ：: サンクス
287 ：: 全体構成の把握はまだ出来てないけれど、只今、ソース解析中・・・
いちゃもんつけるつもりじゃないけれど、気になった点を２つ。
Control.phpのPOSTされたSubmitボタン名取得のところは
クラス化されてないのはどうしてなのでしょうか？
さらに非常にクラスが多くなって面倒になるから？
class Control extends Base
var \$_view_calss;
このメンバはあえてclassにしてない理由はあるのでしょうか。
288 ：: >>287
POSTされたサブミットボタン名取得部分は説明の通りです・・
今その部分をC#でのデリゲートで実装しようと思ってます。
Viewクラスexecuteのところもこのままでは$eパラメータが
コントローラから任意に渡せないので検討中です。
オブジェクトにexecute以外のパブリックメソッドを
実装しないのが目標です・・(※アクセサ以外)
289 ：: クラスの継承関係が結構複雑になってますね。
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; // 書き込むファイル名
290 ：: ■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()　→現在未実装。
291 ：: こうやってみてみると、クラスを継承する際の設計思想が見えてくるな。
どの段階で実装を替えるかを考えた場合、どのクラスを置き換えれば良いかも分かる。
しかし、俺はこれまでフレームワークの構成などをじっくり読んだりしたことが無いので、
つい、ここまでクラスを継承させるメリットがあるのかなとか思ってしまう。
なんか、１つのメソッドを実装するのに、１回継承してるって感じだよね。
例えば、Model（抽象）クラスの $src_file_name を別のものにする場合、
それ以降のクラスが全部影響するかの確認が必要なわけだから、
Model（抽象）クラス以降のものをすべて一つのクラスにまとめて書いても
同じなんじゃないかと思えてしまう。
こういうのとは別な場面で、継承しているメリットがあるってことかな？
292 ：: ちょっと紹介しておきますね。
フレームワークを使った開発のメリット、デメリットを教えてください
http://q.hatena.ne.jp/1188498291
特集：第1回　フレームワーク「Struts」の基礎を知る (3/8)
フレームワークのメリットとデメリット
http://www.itmedia.co.jp/enterprise/0310/06/epn03_3.html
293 ：: Control の & _onExecute(&\$param, \$e) で
\$this->_view_calss = \$view_calss;
というコードがあるけれど、右辺の \$view_calss って、
何処でも定義されてないですよね？
このまま動かすと、nullが入るだけのように思えるんだけど。
294 ：: 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出力する。テキストボックスと送信ボタン
295 ：: >>293
１行上のフックハンドラ実行の結果を渡している。
296 ：: ロードメソッド[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
297 ：: リンク
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
298 ：: >>285のファイルが落とせない・・・
299 ：: >>298 見れるはずですが・・以下はどうですか？
Eclipceでのデバッグ画面です
ttp://proxy.f3.ymdb.yahoofs.jp/bc/4525b767_dfac/bc/452a/OOPFW_DEBUG.jpg?BC3YDrHBI.a6ljXl
300 ：: >>298どうでしょうか？
ttp://briefcase.yahoo.co.jp/bc/oopfw
301 ：: なんでPHP4文法でやってんの？
302 ：: >>300でいけました。サンクスです。
303 ：: これは、>>1さんのサイトでは、「入力フォームを作ってみる」とは
別で、「フレームワークを作ってみる」の演習という位置づけにした
方がいいかもしれないね。
これからの流れとしては、上のほうにあるように、このソースを
解読・改変していくための補助ドキュメント作成の方向と、
このフレームワークを使ってみる人のためのドキュメント作成
（チュートリアルみたいなもの）になるだろうね。
出来る範囲でみんなで手伝っていってみましょう。
このフレームワークは、MFCみたく、あらかじめ準備された
クラスのメソッド中に書き加えていくスタイルなのかな？
それとも、VBみたいにそういうソースコードを全部隠蔽
してしまう方向でいくのかな？ちょっと気になった。
304 ：: こうやってソースを読んでみると、これまで抽象的に聞いていた
フレームワークを使ったプログラミングのメリットとデメリットが実感できるね。
今まで、システムを組む際はOOPやフレームワークを使う方向にするべきだと
思ってたけれど、そうでもなく、状況や目的に合わせて選択する
というのが良い事が分かってきたような気がする。
小規模で全体概要を把握したいとか、移植性を考える場合は、フレームワークよりも、
クラスライブラリを使うスタイルの方が良い場合もありそうだ。
305 ：: MVCでフレームワークを自作する方向と、クラスライブラリを自作する方向の
２つの方向をやってみて、それぞれのメリットとデメリットを確認していけば、
システムを作る場合の検討材料に出来ると思う。
何でもフルスクラッチしていき、なるべく依存性は無いようにし、（言語の
バージョンくらいに収めるとか）その組み合わせでアプリを作る、みたいな。
306 ：: 再度リファクタしてみました。
ttp://briefcase.yahoo.co.jp/bc/oopfw
[Controlクラス]
・リクエストオブジェクトの参照の重複の削除
・サブクラスでのフックハンドラ処理修正
・Viewオブジェクトの実行方法修正
※これはViewオブジェクトハンドリングの自由度をました反面、
ユーザからの取り回しが煩雑になったかもしれませんね・・

[Modelクラス]
・継承関係の見直し、ItemBaseクラスの導入などです・・
MVCの継承関係が美しくないですが・・
>>291
リファクタしながら構成を練っていってますが
継承クラスでの責任が小さい単位で分割されていると
大きく修正が入った時も楽だと思います。
>>303
MFCもVB6もフックハンドラに処理を記述していく方式なので
それを参考にしています、サンプルFWも自由にいじってもらって
参考にしてもらえたら良いと思います。
>>305クラスライブラリ方式もいいかもしれないですね。
307 ：: フレームワークのメリットとデメリットにおいて、なるべく具体例を書いた形でまとめてみた。
【メリット】
１．ビューとロジックの切り分けが出来る。（共同作業時に便利）
　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 のバグは、開発元の不具合修正を待つしかない。
　オープンソースのフレームワークであっても、ソースコードが大量な為、把握が出来ない。
308 ：: ＱＡ方式で書いてみた。
Ｑ：どんな時にフレームワークを使った方がいいの？
・短期間で仕上げなければならない時（この場合はフレームワークの使い方を把握しているのが前提）
・チームで分担してシステムを組む時
・バージョンアップを行うなど、長期的な運用が想定される時
Ｑ：フレームワークがあまり向かない場合は？
・個人で小規模アプリを組む時。（一度組んで終わりの場合など）
・そのアプリの全体構成をすみずみまで把握しておきたい場合
・サーバの移植を想定しなければならないなど、環境があまり固定出来ない場合
このような状況の場合は、クラスライブラリの使用を検討すると良い。
309 ：: 何かフレームワークを使ったとして、そのフレームワークがいつまでメンテされるか
判らないことを考えると、バージョンアップをするようなアプリの開発に向いていると
いえるかどうかは、かなり怪しいと思う。
310 ：: >>309
そういうケースもあるから入れるか迷ったんだよね・・・
だけど、現在の比較的規模の大きなアプリは何らかのフレームワークで
組まれている事実があるということで、書いてみた。
フレームワークのメンテが突然打ち切られるケースは無いと見ても
良いと思うけどね。事前に何らかのアナウンスがあるはず。
で、フレームワークそのものを入替える必要が生じた時は、もちろん
全部作り直しになるが、この労力は、フレームワークを使わない場合に
比べて楽だよね。という意見です。
311 ：: 書いてみた、とかって適当かつ無責任な
312 ：: 完璧な文章がいきなりかけるわけないんだから修正しながらでいいと思う。
適当だの無責任だのいうのなら、このスレに来なくて良いと思う。
313 ：: ひょっとして、つられた？
314 ：: つんでれた
315 ：: >>308
> Ｑ：フレームワークがあまり向かない場合は？
> ・そのアプリの全体構成をすみずみまで把握しておきたい場合
全体構成を隅々まで把握してなんの意味があるのだろうか？
どうせ数日たったら忘れるんだし。
> ・サーバの移植を想定しなければならないなど、環境があまり固定出来ない場合
> このような状況の場合は、クラスライブラリの使用を検討すると良い。
PHP4、PHP5両対応のフレームワークもあるし、
いろんなデータベースに対応している場合もある。
フレームワークの開発というのは、そもそもが環境が固定されていないので
そういう場合にはなおさらフレームワークを使ったほうが良い。
316 ：: 理解と記憶は別物だと思うけどな。
317 ：: >>315
> 全体構成を隅々まで把握してなんの意味があるのだろうか？
> どうせ数日たったら忘れるんだし。
じゃ、この項目は消しておきます。

> PHP4、PHP5両対応のフレームワークもあるし、
> いろんなデータベースに対応している場合もある。
> フレームワークの開発というのは、そもそもが環境が固定されていないので
> そういう場合にはなおさらフレームワークを使ったほうが良い。
PHPスレで言うのもなんだけど、ASP.NETなども含めた総論という考えだったんだけどね。
Windowsサーバなのかなどを気にするとか、PHP5のみ対応のフレームワークで
開発していて、PHP4しか対応していないサーバで動かすことになる場合を
という意味で、環境が固定されない書きました。
318 ：: 修正案
Ｑ：どんな時にフレームワークを使った方がいいの？
・短期間で仕上げなければならない時（この場合はフレームワークの使い方を把握しているのが前提）
・チームで分担してシステムを組む時
・バージョンアップや不具合修正など、納品後もメンテナンスが想定される時
Ｑ：フレームワークがあまり向かない場合は？
・個人で小規模アプリを組む時。（一度組んで終わりの場合など）
・サーバの移植を想定しなければならないなど、環境があまり固定出来ない場合
　このような状況の場合は、クラスライブラリの使用を検討すると良い。
319 ：: あえてPHP4の構文でやってるのは、PHP4との互換性を保つため？
PHP5でやっちゃうと、PHP4の環境で動かなくなるから。
320 ：: ChStrクラスの件を再開しようかな。
321 ：: >>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
ちょっとずつ読んでますが、全部はまだ理解できないです。(´；ω；｀)
レスも参考にしてみます。
（＝分からないことでも、検索で調べるときのヒント・手掛かりになるので）
322 ：: >>321
乙です。m(_ _)m
>>306ですが今後は
・認証の仕組み
・ロギングの仕組み
・エラーハンドリングの仕組み
・バリデイトの仕組み
・トークンの仕組み
・リダイレクトの仕組み
・入力→確認→完了の仕組み
・コアオブジェクトの実行権限の仕組み
など実装していく予定です・・
でも、こればっかりやってるわけにいかないので
気長に見守ってやって下さい。
323 ：: >>321
乙です。分かりやすくまとまっていますね。
私も少しずつ読んでいって理解しようと思っています。
他のものに比べ、コメントが多いのが助かりますよね。

>>322
読むほうも時間がかかると思いますので、
一気にやらなくていいと思います。（＾＾；
324 ：: MVCフレームワークを作っていただいてる流れとはおもいっきり違う事をいうけれど。
>>1さんのOOPで掲示板を作るところは、もう少しクラスを分けたほうが
いいと思ったので、自分なりに作ってみました。
index.phpに、いろいろと処理を詰め込んでいるような感があったので、
それを分ける考え方です。
しかし、DBはテキストベースにしているとか、書き込み欄と表示欄を
同じページにしているなど、基本構成から大幅に変えています。（＾＾；
http://www.geocities.jp/narutobakijp2/
OOPの勉強として、簡易なBBSを作ってみました。
BBS Version1(2008.2.11)
325 ：: クラス間のデータのやり取りにおいて、Listクラスを使う設計にしたけれど、
PHPの場合はハッシュでよかったような気がする件。
まだまだ未熟だな・・・
今後は、これを構造化指向へ変換したプログラムを作り、うｐする予定です。
この両方のプログラムを見比べてみることで、OOPのメリットとデメリットが
見えてくるかもしれません。
326 ：: OOPの継承やポリモーフィズムについての概念やそのコードの書き方に
ついては分かったけれど、その設計方法のノウハウの文章はぐぐっても
なかなか見当たらない。
「設計というのはそれぞれで目的次第」といってしまえばそうだけど、
hiroxpepeさんのソースや、.NET Framework や java の各クラスの
継承関係の設計を見ていると、何か共通したものを感じる。
その具体的な方針と、それを取る理由がはっきりとは分からない・・・
何か良い文章を見かけた、もしくは知っている方は、お願いします。
327 ：: ◎「メンテナンスを行う場合」の比較
【構造化指向の場合】
ソースコードに書かれている関数とグローバル変数が、どういう階層で組まれているか
（どの関数でどの関数が使われているか。また、どのグローバル変数を使っているのか）
は、その関数の処理内容と、その関係などを把握してからでないと、手をつけられない。
新しくグローバル変数や、関数を追加する場合。また、ローカル変数を宣言する場合は、
その名前がソースコード内で使われているかを都度チェックしなければならないので、
面倒である。
【オブジェクト指向の場合】
ソースコードそのものがクラス単位で分けられているため、手をつける場所がすぐに
分かる。他のクラスに影響するのは、そのクラスとのインターフェースを変更した場合のみ。
新しくメンバやメソッドを追加する場合は、そのクラスの中で使われているメンバや
メソッドを確認するだけなので、対象となる範囲が狭く、チェックが楽。
また、プログラムそのものがクラスで部品化されるため、チームを組んで、分担作業で
プログラミングがやり易い。
【注意】
構造化プログラミングであっても、関数やグローバル変数の名前の付け方を工夫すれば、
もちろん対応は可能である。そのため、メンテナンスを想定する場合は、
オブジェクト指向でなければならないわけでもない。
オブジェクト指向は、構造化指向に比べて特別に「これが出来る」というものではなく、
構造化指向で不便に感じる部分の便利機能である。
328 ：: >>324,325
なかなか参考になりました、ありがとう。
326さんのおっしゃる通り、"設計"は経験なんかも必要になってくるので、
考えるよりも手を動かして、簡単なスクリプトを組んでみるのが最良でしょうか。
329 ：: >>326
・リファクタリング―プログラムの体質改善テクニック
マーチンファウラー著
高いけどOOPに興味のある方には絶対お勧めですよ。
ポリモーフィズム適用の具体例がコードで解説されていますよ。
構造化プログラミングではGOTO構文を使うのはNGだけど
同様にOOPではswitch構文を使用しません。
ここの部分をポリモーフィズムで実装するのです。
あなたのプログラムにswitch構文がありますか？
その部分はポリモーフィズムで置き換えられますよ。
330 ：: >同様にOOPではswitch構文を使用しません。
>ここの部分をポリモーフィズムで実装するのです。
これは言いすぎ。
OOの基本はモデリングであって、コーディングのスタイルじゃない。
331 ：: >>329
情報ありがとうございます。
> 構造化プログラミングではGOTO構文を使うのはNGだけど
> 同様にOOPではswitch構文を使用しません。
> ここの部分をポリモーフィズムで実装するのです。
> あなたのプログラムにswitch構文がありますか？
> その部分はポリモーフィズムで置き換えられますよ。
この表現はすごく分かりやすかったです。
こういう感じの具体的なノウハウがあると分かりやすいですね。

>>330
「言いすぎ」というご指摘もごもっともだと思います。
しかし、OOPは、構造化指向に比べてダントツで良い所があるわけでも
ないので、（このため、すべてがOOPに移項してはいない。）
良いところを説明する際は、多少は強調した感じで言わざるを
得ないところがあると思っています。
332 ：: >>330
そうですね、確かに言い過ぎました・・
GOTO構文は習いませんでしたが、switch構文は習得しちゃいました。
あえてそれを使用しないで組んでみるのも勉強になるのではないでしょうか？
構造化的スタイルとOOP的スタイルを手っ取り早く理解しようとするなら
それぐらいのパラダイムシフトが必要だと思うんです。
もちろんGOTO構文もswitch構文もコーディングには必要です。
333 ：: switchがいらないということは、
if文もいらないな。
それともswitchを使わずに、
if文で書けばいいのかｗ
334 ：: >>328
（なんか、自分語りみたいなレスになっているけれど、
OOPの勉強方法についての意見交換にもなるかと思ったので書いておきます。）
私は、プログラミングをこれから勉強しようという時、「無駄・ムラ・無理なく
勉強する」という予備校の受験勉強の風潮を受けていましたので、先生に
「プログラミングを勉強する場合は、どんな風なやり方をしたら良いですか？」
とか「どんな順番で勉強をしていったら良いですか？」と聞いたことがあるのですが、
その先生は、「そんなことを考えている時間があるなら、その分コーディングを
した方が良い」とアドバイスをしました。
実際に手を動かしてやってみると、文章や口頭の説明では言えない、何か体感的な
ものが習得でき、その後の勉強方針もどうやったら良いのかが見えてきました。
「ああ、あの言葉は、こういう意味なんだな」と思いました。
プログラミングは、実技の世界なのだから、実際に手を動かしてみて見えてくるものだと
思っています。
過去に表計算をするプログラムを構造化指向で組むと、処理を関数に分けていく方法が
身についたなと思いました。なので、今度は、構造化指向で苦労をするプログラミングを
してみると、OOPの良さが見えてくるのでは、と思っています。
335 ：: BBSの構造化バージョンをうｐしました。
ttp://www.geocities.jp/narutobakijp2/index.html
OOPの勉強として、簡易なBBSを作ってみました。
BBS Version2(2008.2.11)入力したデータで改行に対応してなかったので、その部分を修正。
BBS Version2の構造化Ver(2008.2.11)上記プログラムの構造化バージョンです。
336 ：: そもそも起動したら即終了するようなPHPプログラミングにOOを使う必要性が感じられない。
337 ：: ここは必要性を語るスレじゃないですよ
338 ：: >>336
なんで実行時間とOOの必要性に関連があるの？
>>337
それは了見が狭すぎでしょ。
339 ：: >>336じゃないけど、オブジェクトは状態を保存しておくものだから。
複雑なデータを持つオブジェクトを作っても、mod_phpはリクエストの度にプロセス生成・終了するわけで、そのオブジェクトも消える。
そもそもウェブアプリはユーザからのリクエストを受けて処理が発生しする構造だから、オブジェクトを永続化しておくことにあまり意味はない。
オブジェクト指向に興味があるなら、GUIのあるアプリケーションとか、ゲームとかを作ってみるとよいよ。
340 ：: 永続化されていないオブジェクトには意味がほとんどないという主張ならば、どうだろうね。
Booch先生も、「永続性」に対して、「有用ではあるがオブジェクトモデルにとって
なくてはならない要素というわけではない」　って言ってるし。
(もう絶版だけど、Booch法第2版　2.2節より)
341 ：: >>336だけどphpはプロセスを生成してから破棄するまでに処理を1度しか行わない関数？が多いし、
イベントが非同期で発生したりするわけでもないからOOを使うのはどうかなー？って気がする。
だいたいフローチャートで処理書けちゃうしね。
あとデータベースなりファイルなりからデータを読み込んでそれをオブジェクトの形に整形して・・・・
って処理が無駄な気がする。
実際に行う処理よりもその整形処理が長かったりするとなんか本末転倒なような。
342 ：: >>341
>あとデータベースなりファイルなりからデータを読み込んでそれをオブジェクトの形に整形して・・・・
>って処理が無駄な気がする。
なるほど、それはそうだね。
いわゆるロジック的なものがほとんどない Webアプリってのは存在するし。（っていうか大半かも)
フレームワークでもなんでも、整理してるつもりで回りくどいだけってのは多い気がする。
話に付き合ってくれて、どうもありがと。
343 ：: > いわゆるロジック的なものがほとんどない Webアプリってのは存在するし。（っていうか大半かも)
どう考えても少数だろｗ
ロジック無しで何が作れるというんだ？ｗ
344 ：: > そもそもウェブアプリはユーザからのリクエストを受けて処理が発生しする構造だから、オブジェクトを永続化しておくことにあまり意味はない。
その理屈だと、PHPに限らず、JavaでもRubyでもオブジェクト指向は要らないということになるな。
それにアプリでも終了すると消えるわけで、結局はウェブアプリと同じ。
そもそもデータベースやファイルにデータを保存するのも
オブジェクトの保存・永続化なわけだが？
> あとデータベースなりファイルなりからデータを読み込んでそれをオブジェクトの形に整形して・・・・
> って処理が無駄な気がする。
> 実際に行う処理よりもその整形処理が長かったりするとなんか本末転倒なような。
だからフレームワーク使うんじゃん。
345 ：: >>343
単純に、SQLにパラメータ設定して、実行して、検索結果をエスケープしてHTML/XMLのタグつけて
返してるだけで出来てるWebアプリって多そうだけどな。ロジックというほどのもんでもないでしょ。
>>344
ムダなのは実装時間じゃなくて、CPU時間でしょ。
フレームワークで解決する問題じゃないと思うが。
346 ：: >>345　訂正
「本末転倒」って言葉からすると、実装量なのかな。
取り消します。
347 ：: >>341
> あとデータベースなりファイルなりからデータを読み込んでそれをオブジェクトの形に整形して・・・・
> って処理が無駄な気がする。
> 実際に行う処理よりもその整形処理が長かったりするとなんか本末転倒なような。
これはもともとOOPの特性じゃない？
再利用性や保守性を高めるために、他の処理とを完全に切り分ける代わりに、
構造化指向よりも、コード量が多く、動作が重くなるというのは。
これは、個人で組む小規模プログラムでは無駄でしかないが、チームで組んだり、
改変がある場合には威力を発揮する、という類のことでしょ。
348 ：: 確かに私もWebアプリの世界ではOOPの意味は少ないと思う。
指摘にあるように、フローチャートがかけるような処理しかしていないので、
主にPerlやPHPで構造化指向でコーディングするスタイルが流行っているのだと思う。
（PerlやPHPのOOP対応は未だに不十分なところがある）
また、ネットにあるサンプルアプリは構造化指向のものが非常に多い事からも、
構造化指向で十分に組めることを意味しているのだと感じる。
通常だと、「だったら、WebアプリをOOPで組む必要ないよね。」となるわけだが、
私がそれでもあえてOOPをやっているのは、その有用性などを自分で体感する形で
確認したいからだ。
大規模なアプリとなると、WebアプリでもOOPを活用して組むことが多いと聞くが、
それは具体的にどのような場面で、どのような有用性があるからなのか。それらを確認したい。
最近は、どうも（Webアプリの世界では）OOPの有用性を見るよりも、
各種フレームワークの有用性を確認した方が良いのでは、と感じている。
349 ：: > 確かに私もWebアプリの世界ではOOPの意味は少ないと思う。
> 指摘にあるように、フローチャートがかけるような処理しかしていないので、
OOPの意味が少ないの理由がおかしい。
フローチャートがかけるような処理しか”貴方が”していないから
必要ないといっているだけであって、そうではないものはOOPの意味がある。
「Webアプリはフローチャートがかけるような処理」という前提がそもそもおかしい。
> 大規模なアプリとなると、WebアプリでもOOPを活用して組むことが多いと聞くが、
> それは具体的にどのような場面で、どのような有用性があるからなのか。それらを確認したい。
OOPの有効性、そのものがわかってないだけじゃないか？
> 最近は、どうも（Webアプリの世界では）OOPの有用性を見るよりも、
> 各種フレームワークの有用性を確認した方が良いのでは、と感じている。
各種フレームワークは、すべて（といって問題ないレベルで）OOPで
作られていることを知らないの？
350 ：: >>349
別にOO的なモデリングをしなくても複雑さが増大しないのであれば、OOを選択するのは技術的な理由ではないでしょ。
前提がおかしいと主張するなら、どうおかしいのか言わないと、それこそ意味がない。
351 ：: >>349
じゃあ貴方がOOPを教えてあげたら？
352 ：: >>349
どういう利点があんの？
353 ：: クラスを使ってるだけで、オブジェクト指向でも何でもないよ。ウェブフレームワークは。
オブジェクト指向を謳うなら、オブジェクトをシリアライズしてDBやセッションに保存するくらいはしないと。
そんなフレームワークがどれだけある？
354 ：: なんで永続性に拘るんだろ。
355 ：: なんでオブジェクトに拘るのかってこと。
356 ：: ウェブアプリで扱うデータのほとんどはRDBMSだけど、RDBMS自体はフラットなデータ構造でまったくオブジェクト指向ではない。
だから、RDBMSからオブジェクトにいったん変換するんだけど、最終的にはHTMLというやはりフラットな構造に戻さないと行けない。
例えばgmailみたいに非常に複雑な処理が要求されるサイトなら、いったんオブジェクトにするのは有効と思うけど、gmailみたいなサイトは例外的。
ほとんどのウェブサイトは、ただDBに入った値を表示するだけでいい。
357 ：: >>356 あっそ、じゃおまえがオブジェクト使わずに書けばいいだけじゃね?
358 ：: OOプログラミングってのは、OO的にモデリングしたものをプログラミングすることであって、
オブジェクトを使ってプログラミングすることではないでしょ。
これを区別しないのは「VC++で作ったからオブジェクト指向だ」って言うのと同じ。
359 ：: >>358
概念じゃなく具体的なコードで説明して下さいお願いします。
360 ：: そんなんムリ( ﾟДﾟ)　本でも読んで勉強して。
今まで読んだ本でOOに関して一番良かったのは Booch法：オブジェクト指向分析と設計　なんだけど、
いくら Booch法自体が古いとは言え、こうした本が絶版になってしまっているというのは、なんとも悲しい。
361 ：: 勉強したい人が集まってるんだから、必要・不必要で論争しなくても……。
362 ：: >>336だけど話が広がり過ぎて正直びっくりしてる。
別にOOPしてもいいと思うよ。
俺もクラス使うし。
ただWebプログラミングだとクラス使っただけの手続き型プログラムになりがちだから
OOPの恩恵に与りにくいんじゃないかなーって思っただけ。
たとえば俺はいまPHPでゲーム組んでるんだけど
普通のゲームプログラムとかだと
$char_list[] = new Player();
for($i=0; $i<N; $i++)
{
　$char_list[] = new Enemy();
}
while($game_loop)
{
　foreach($char_list as $char)
　{
　　$char->Move();
　　$char->CheckHit();
　　$char->Draw();
　}
}
exit(0);
みたいな感じになるけど
363 ：: Webプログラミングだと
$buf = DataRead();
$player = new Player();
$player->SetData($buf);
$player->Move();
$player->CheckHit();
$player->Draw();
$buf = $player->GetData();
DataWrite($buf);
exit(0);
みたいなのになりがちじゃん。
364 ：: それなら
DataRead();
PlayerMove();
PlayerCheckHit();
PlayerDraw();
DataWrite();
exit(0);
でもいいじゃん的な気がするってだけ。
まぁひとえに俺のプログラミング力不足だと思うけど。
365 ：: また Booch法から引用すると　「ハンマーを手にする者には世界中の全てのものが釘に
見えるように、オブジェクト指向の考えに染まった開発者は世界中の全てのものがオブジェクトで
あると考え出す。この観点は少々無邪気すぎる。」だそうで、若干感情的な議論を呼びやすい
テーマではあると思う。
そういえば、同じ様なことがフラクタルとか 1/fゆらぎの本にも書いてあったな。
人間なんてそんなもんだ。
366 ：: >>360
・構造化プログラミング三要素
STEP01 順次進行
STEP02 条件分岐
STEP03 繰り返し
・OOプログラミング三要素
STEP04 カプセル化
STEP05 継承
STEP06 ポリモーフィズム
WEBデザイナがPHP使ったところでSTEP01止まり、
MS OFFICEのマクロ/VBAもそんな感じだね。
ifやforを使わず延々と処理を記述してるのあるよね。
STEP04で思考を止めちゃ駄目なんだ。
勉強の為に「継承」「ポリモーフィズム」を使った
プログラムをあえて書いてみるんだ。
モデリング云々とかそんなの関係ないんだよ。
そもそもここは>>1でしょ？
367 ：: >モデリング云々とかそんなの関係ないんだよ。
思考を止めてるのは誰だよ。
368 ：: モデリング無しにOOPで書けるんですか？
369 ：: >>367 >>368
じゃあモデリング房が設計について判りやすく教えたら？
OOPの概念すら理解出来ない初心者に上流から教えるんですか？
ぐだぐだ言ってないで初心者に判りやすく為になる発言したらどう？
370 ：: モデリングが重要かもしれないっていう情報を教えてもらったんだから、それで満足しろよ。
あとは自分で本でも読め。
371 ：: この基地外まだいるのか
372 ：: >>370
あれれ？モデリングを判りやすく教えてくれるんじゃないんだ？
さては本当は自分も理解して(ry
373 ：: OOP有用性の議論にDBの実装の話がこびり付いている。
純粋な議論ではないと思う。
374 ：: 熱意ある奴がケーススタディとして『やってみて』いるんだからさ
酸いも甘いも知ってる方はOOPで作るべきっていう良いお題を
出してあげたら盛り上がるんじゃないか
375 ：: ＰＨＰでＯＯＰの議論すること自体おかしい
オブジェクト指向が有用だからこそ
java,c++.c#,ruby最近の言語は全てＯＯＰになってる
大規模なものをつくるのにＯＯＰじゃないと非効率すぎる
376 ：: 簡単にいうと
規模が小さいほどＯＯＰの必要性が無くなり
規模が大きいほどＯＯＰの必要性がでる
377 ：: 規模が小さいならスパゲッティコードが最強てこと
大きいならＯＯＰじゃないとはなしにならない
378 ：: OOを議論するのにPHPをベースにするのはどうかと思うが、PHPにおけるOOを議論することは良いんじゃないの。
あと、規模というよりは複雑さだろうな。
379 ：: OOPの話は荒れる元だな・・・よし、

～～～～～～～～～ここからOOPネタ禁止～～～～～～～～～～～～～～
380 ：: (ＯＯ)Ｐ
↑
マスコット（笑）
名前はオッピー君。
育ち盛りのオスです。
パスタは嫌いだよ！
最近、俺俺オブジェクト指向にはまって
同僚達から嫌われる羽目にｗ
そんな落ち目のオッピー君と一緒にオブジェクト指向の真髄を極めよう！
381 ：: おいらに力を・・・・
382 ：: どうして荒らしが粘着し始めたのだろう。
383 ：: 思い切って質問してみる。
テーブルAの操作をするクラスA、テーブルBの操作をするクラスBを作った。
両方のクラスで個別に接続するより、1番最初に接続して、その接続IDを使って処理させたほうがいいのかな？
384 ：: >>383
取得するテーブルの数ごとに別々に接続はしない方がいいよ。
DBの処理負荷が大きくなるから。
私だったら、テーブルごとにクラスを分けたりはしないかな。
テーブルの構成そのものを隠蔽するために。
検索と更新は同じフォーム上では行わない前提にして、こんな感じにするかな。
// 接続に関するクラス
// PostgreSQLに接続する為のメンバとメソッドを持つ。
class CDB_PostgreSQL
// MySQLに接続するためのメンバとメソッドを持つ。
class CDB_MySQL
// 個人情報の検索をするクラス。
// 以下の検索メソッドを持つ
// ・電話番号を指定し、候補の個人情報一覧を得る。
// ・苗字を指定し、候補の個人情報一覧を得る。
// このクラスのメンバに上記２つのどちらかのDBクラスを持たせる。
class CSearch_Personal
// 個人情報の更新をするクラス。
// 以下の更新メソッドを持つ
// ・主キーを指定し、個人情報を更新する。
// ・新しい主キーを設定し、個人情報を新規追加する。
// このクラスのメンバに上記２つのどちらかのDBクラスを持たせる。
class CUpdate_Personal
385 ：: コードまで丁寧にありがとう。
クラス設計は、慣れがないと難しいね……。
> このクラスのメンバに上記２つのどちらかのDBクラスを持たせる。
申し訳ないんだけど、「メンバにクラスを持たせる」の意味が理解できない。
少し補足してもらえるとありがたいんだけど、ダメかな？
386 ：: 規模と言うか、どれだけ複雑なロジックがあるかだよね。２ちゃんねるは物凄く規模が大きいけど、ロジックはごく単純。ただの掲示板だもん。
387 ：: テーブルAを操作するモデルクラスAとは行かない場合もあるよ。リレーションがある場合。
388 ：: テーブルクラスはDBクラスと分けて
テーブルの中からgetConnection()するのが普通だよ
コネクション管理とテーブルを切り離す
389 ：: >>385
設計の仕方は、その人が作ろうとするアプリ次第なので、その人が
やりやすいスタイルでやっていいと思うよ。
OOPの設計理論は、あくまで一般論なので、必要性を感じないのであれば、
必ずしも守らなくていいだろう。
私は、DBをPostgreSQLからMySQLへ変換する必要性も生じることを
想定した設計をしただけだよ。
こうやっておけば、書き換えるコードも少なくて済む。
class CSearch_Personal{
// DBを格納する
var $m_db;
// コンストラクタ
function CSearch_Personal(){
$db_info = ""; // ここでDB接続に必要な情報を入れる。
$this->m_db = new CDB_PostgreSQL($db_info);
}
// 電話番号で検索
function Search_by_TEL($tel){
$sql_str = "SELECT * FROM TableA WHERE TEL = '" . $tel . "'";
$this->m_db->Execute($sql_str);
// ここで、データをうけとり、返す。
}
}
390 ：: どうしてもテーブル単位でクラスを作る場合は、こんな感じになるのかな。
// PostgreSQLへ接続処理などを管理する基底クラス（抽象）
class CDB_PostgreSQL_Connection
// TableAの操作を管理するクラス。
class CDB_TableA extend CDB_PostgreSQL_Connection
// TableBの操作を管理するクラス。
class CDB_TableB extend CDB_PostgreSQL_Connection
391 ：: OOPの設計をする場合は、処理を文章で書き表して、
その中から名詞や役割を抽出していけばいいと聞いたことがある。
その単位を１つのオブジェクトとして設計する。
１つのオブジェクトを、１つのクラスとしてコーディングする。
392 ：: >>390
CDB_PostgreSQL_Connectionを拡張してCDB_TableAにするのはまずい
子クラスと親クラスはis_a関係にしないといけない
言い換えると子クラスは親クラスの範疇に含まれていないといけない
テーブルがコネクションの一部でないことは明らか
393 ：: 異論はあるだろうけど、SQLに関しては、パフォーマンスの都合上実装の仕方が限定されるから、
モデルに合わせて考えるのではなくて、SQLを考えてから、それに会うモデル（クラス構造）を考えた
方が良いと思う。
394 ：: >>393
ｋｗｓｋ
395 ：: 具体的に聞かれないと、答えようがない。
396 ：: >>393
テーブル構造が複雑な場合、そういうのもアリだと思うけど
それはオブジェクト指向じゃないよね
397 ：: 微妙だけど、抽象化のレベルが低い(計算機寄りな)だけで、OOではあると思ってる。
ただDBアクセスについて、パフォーマンスを保ったまま、高い抽象化ができない・やりにくい
というのは、OOが本質的にDB向きではないということだと考えてる。
398 ：: とりあえずDBアクセスはPDOでいい。
各操作系に保持させるならプリペアドステートメントを。
個人的には各テーブルってよりも各テーブルのレコードクラスを作るかなー。
テーブルに対する操作は静的メソッドで実装する。
どうでもいいがクラスってのは抽象データ型なので関数と比べるなんてしてるとハマる。
399 ：: UMLモデリングツールでPHP書いている人いる？
具体的には「Umbrello」を業務で使っている人

400 ：: C#の記事だけど、継承に関するものをみつけた。
Column　- 継承を使うべき場合、使うべきではない場合 -
http://www.atmarkit.co.jp/fdotnet/csharp_abc2/csabc2_004/cs2_004_03.html#cs0406
401 ：: >>397
> というのは、OOが本質的にDB向きではないということだと考えてる。
逆逆、リレーショナルデータベースが、OO向きじゃない。
402 ：: >>398
> 各操作系に保持させるならプリペアドステートメントを。
プリペアドステートメントは条件の数を変えにくいという
大きな欠点があるからなぁ。
> 個人的には各テーブルってよりも各テーブルのレコードクラスを作るかなー。
一般に言われている、ActiveRecordパターンですね。
Ruby on RailsやCakePHPで採用されている奴です。
403 ：: >>383
> テーブルAの操作をするクラスA、テーブルBの操作をするクラスBを作った。
> 両方のクラスで個別に接続するより、1番最初に接続して、その接続IDを使って処理させたほうがいいのかな？
処理の負荷というより、決定的な問題がある。
それは主にトランザクションを使ったときに起こる。
複数のテーブルを操作することで、一つの処理を完成させる場合
中途半端な状態を他に見せないようにしなければいけないし、
また一つのテーブルで処理が失敗した場合すべてを元に戻さなければならない。
これを実現する為に同じ接続から見える状態と、違う接続からみえる状態で
違うことがある。
404 ：: PHPやWebアプリに限らないけど、OOPってのはフレームワークを作るためにある。
ここで言うフレームワークには、汎用の名前があるフレームワークだけじゃなく
たとえばあるゲームの独自の基本システムなんていったものも含む。
このフレームワークを使って作るもの・・・すなわち、
フレームワークから呼び出されるコードは、単純な処理になるので
（というか単純な処理ですむ為のフレームワーク）
OOPにならないことが多い。
だからといって、システム全体がOOPになっていないとは思わないけどね。
システム全体の一部。つまりクラスの中のメソッドだけを見て
非OOPというのはおかしいでしょ？
405 ：: >>404
誰に言ってるの？？
406 ：: 誰に言ってるのかも気になるが、そんなこと誰が言ってるのかも気になる。
OOPがフレームワークのためにあるという主張は初めて聞いた。
407 ：: >>384 も >>389 も >>390 も気持ち悪すぎだ
普通に考えるとこういう感じだろう？
// 接続に関する抽象クラス。汎用で使える関数があれば定義しても良い。
class CDB_Connection {}
// PostgreSQL接続用クラスの実装
class CDB_PostgreSQL extends CDB_Connection {}
// MySQL接続用クラスの実装
class CDB_MySQL extends CDB_Connection {}
// テーブルに関する抽象クラス。汎用で使える関数があれば定義しても良い。
class CTable {}
// 個人情報クラス。
class CPersonal extends CTable{
　function CSearch($connection) {} //コンストラクタかメソッドでコネクションと接続
　function search() {}
　function update() {}
}
408 ：: >>407
概ね同じ意見だけど、Cpersonalを実体化する必要ってあんまりなさそうだから、
自分はメソッドを staticにすることが多い。
あと、connection をオブジェクト内部にもってしまうと、そのオブジェクトはいつでも
SQLを実行できてしまうので、引数で渡すようにしてる。
(まぁ、staticにしたら引数で渡すしかないけど)
409 ：: >>408 に補足
必要性がないというより、CTable (のサブクラス)のインスタンスをnewするということは、
意味論的には、そのテーブル自体を新規に生成するということだから、ちょっと気持ち悪い。
410 ：: >>389
> 私は、DBをPostgreSQLからMySQLへ変換する必要性も生じることを
> 想定した設計をしただけだよ。
> こうやっておけば、書き換えるコードも少なくて済む。
とか言っておきながら、
> // コンストラクタ
> function CSearch_Personal(){
> $db_info = ""; // ここでDB接続に必要な情報を入れる。
> $this->m_db = new CDB_PostgreSQL($db_info);
> }
CSearch_Personalのコンストラクタで
CDB_PostgreSQL決め打ちなのはナンセンス。

DBをPostgreSQLからMySQLへ変換する必要性も生じることを想定した設計というのなら
設計としては、Personalデータを扱う（Search専用？）クラスは
接続するデータベースに依存すべきではない。
（限られた環境だけで動くものを作ればいいだけならどうでもいいが）
接続オブジェクト（CDB_PostgreSQL）はCSearch_Personalクラス外部から
与える。そのときの引数は（PHPに厳密な型は無いが）抽象クラスのCDB_Connection型で与える。
こうすることで、DBをPostgreSQLからMySQLへ変換する必要が生じたとき、
CSearch_Personalを一切修正しないですむ。
411 ：: >>404は、「バージョン6までのVBって構文は構造化だけど、
内部的にはクラスが動いているんだよ」といってるのと
同じ意味のように思える。
誰に何を伝えたいのかは良く分からないが。
412 ：: >>408-409
まあ、そこは設計しだいでいくつかやり方があるけど、
ActiveRecordパターンの場合、インスタンスはテーブルを作るという意味ではなく、
クラスがテーブル全体で、そのインスタンスはテーブルのレコードという扱いになる。
そしてフィールドがプロパティ。
413 ：: >>411
一応突っ込み。VBにはクラスがある。（少なくとも5以上）
もちろんnewでインスタンスも生成できる。
414 ：: >>412
これですかね。
http://www.martinfowler.com/eaaCatalog/activeRecord.html
細かいけど、
>そのインスタンスはテーブルのレコードという扱いになる。
なら、searchメソッドは、staticなり外部に置くのではないかと思う。
確かに updateはこの場合 staticにすべきものではないですね。失礼。
415 ：: >>408
> あと、connection をオブジェクト内部にもってしまうと、そのオブジェクトはいつでも
> SQLを実行できてしまうので、引数で渡すようにしてる。
なんで「そのオブジェクトはいつでも SQLを実行できてしまう」のが悪いのかわからないけど、
> (まぁ、staticにしたら引数で渡すしかないけど)
これが理由なら、そのクラスをシングルトンパターンで
実装するという方法もある。
CPersonal::search() などという書き方で呼べるぞ。
ただし、PHP4に対応した書き方だとすごく気持ち悪いんだが（笑）
CakePHPでgetInstance()というメソッドをキーワードにして探せば
実装例が見つかると思う。
getInstance()関数内のstatic変数に配列[0]にで確保（なぜ？）した後
各メソッドの初めで$_this = getInstance() して$_thisで参照するという・・・
まあ見たほうが早い（？）
416 ：: >>415
>なんで「そのオブジェクトはいつでも SQLを実行できてしまう」のが悪いのかわからないけど、
DBなんて巨大なグローバル変数の固まりみたいなものだし、アクセスもメモリと比べて遅いし、
トランザクションの都合からもある範囲でDBアクセスしている可能性がないかが
簡単に見分けられないのは怖いと思うけど。
417 ：: >>414
> なら、searchメソッドは、staticなり外部に置くのではないかと思う。
あー。staticでいいです。単に個人的な環境の理由から
PHP4を使っていて忘れていただけです。
418 ：: >>416
でもどっちみちデータベースに操作を出来るところなら、
コネクション知っているわけで、結局同じことでしょ？
それにクラスの変数はグローバル変数じゃないからｗ
419 ：: >>418
必要なメソッドにしか connection を渡さず、オブジェクト内に保存しないことで、
「データベースに操作できるところ」を限定するという話。
connection をDBアクセスする権限と見るならば、その権限は処理に対して与えるべきで、
オブジェクトに対して与えるべきではないだろうということ。
420 ：: DB周りはZendFrameworkの実装でなんら不満ないなあ。
421 ：: >>419
しかし、テーブルに関するクラスでデータベースを操作しないメソッドって
あまりないからなぁ。まあ別にいいけどね。
422 ：: >>421
例えば Personテーブルに depart_codeがあるとして、$person->getDepartName() としたときに、
暗黙のうちにdepart_codeをキーとしてDepartテーブルから検索する SQLが実行されたら嫌だし、
setPersonNameされたときに、そのタイミングでupdateが実行されていないか疑わなきゃいけないのも嫌。
423 ：: >>422
メソッドの実装がどうなってようが呼んだ方の知ったこっちゃないだろ。
そのどっちの例もそのクラスの仕様なんだから。
それを外側から知ろうとか制御しようだなんておかしな話だ。
424 ：: そもそもstaticも存在しないPHP4で機能をまとめたようなクラス（CDB_PostgreSQLクラスみたいなの）
を作ろうとしてるのが気持ち悪い。
しかもOOPなんてデータベースの各要素に関数をくっつけたようなもんなんだから既存のデータを単体でしか扱わない
データベースと相性が悪いのは分かりきったことだろう。
425 ：: OOPはデータベースの各要素に関数をくっつけたようなもの？
既存のデータベースはデータを単体でしか扱わない？
だからOOPとデータベースと相性が悪い？
(　ﾟДﾟ) ﾜｶﾗﾅｲ
426 ：: >>424
staticはあくまでstaticだよと明示しているだけで
本質的には必要なものとは思えないけど。便利だけどね。
それと、CDB_PostgreSQLは「機能をまとめたクラス」ではないよ。
たとえば一つのアプリでサーバー負荷分散などで、
複数の接続を使用するときとか、複数のインスタンスが出来る。
427 ：: ＰＨＰでもメンバポインタとかつかえれば
インスタンスに縛られない柔軟なＯＯＰができるのにな
428 ：: 少しだけど、クラス分割のコツが掲載されてたのではっておきます。
VBプログラマ向けの情報だと、OOPの考え方の情報が結構ありそうです。
業務Webアプリの作り方の基礎（前編）
業務アプリ開発で失敗しないコツ
http://www.atmarkit.co.jp/fdotnet/vblab/bizappbasic01/bizappbasic01_01.html
> 1つの機能（＝たとえWebアプリで複数のページにまたがっていたとしても一連の作業を
> 完了させるまでの一連の操作）に対して、1つのビジネス・ロジック層のクラスを
> 作ってみることをお勧めする。
> 一般的な業務アプリでは、クラスを細かくしすぎてしまうとどこで何を行っているのかが
> 分かりづらくなり、結果的にメンテナンスしづらいアプリになることがある。
（パフォーマンスを考慮し、）
> 可能な限りクラスのインスタンス化が必要ない静的メソッド（Sharedプロシージャ）で
> 作成したステートレスな設計にすることをお勧めする。
429 ：: たまに昔のサイト触ったりすると非OOPなんてもうやってらんねーと思う
DRYになってないから直すの大変
430 ：: OOPってのは設計的な考え方ってのが含まれるんだけど、
そういう考え方は別として、単にコーディング技法として便利だよ。
431 ：: >>272
プリミティブだけど実装してみました・・
もはやQuickFormとSmartyがないと動きませんが・・
ttp://briefcase.yahoo.co.jp/bc/oopfw
432 ：: 風邪をひいてしまい、最近頭が回らないです。レスも遅れてしまってます。。。
>>392
確かにそうですね。継承をして作ったクラスはすべてPostgreSQLに依存してしまいます
ので、is-a関係が正しいですね。
>>407
接続に関して抽象的にクラスを定義するところは勉強になりました。
私はまだまだ継承を使いこなせてないですね。
>>410
> 接続オブジェクト（CDB_PostgreSQL）はCSearch_Personalクラス外部から与える。
この発想は思いつきませんでした。
確かに言われてみるとそうです。CSearch_Personalを一切修正しないで済むようになります。
433 ：: >>431
サンプルありがとうございます。
あとでソースを読んでみます。
434 ：: 質問しておきながら、反応かなり遅れてしまってごめんなさい。
具体的なコードやアドバイスを提示してくださった方々、ありがとう。
ちょっとまだ、自分には敷居が高くて色々大変そうですが、
考えるよりも産むが易し、と言うので、手を動かして色々試行錯誤してみます。
ありがとうございました。
435 ：: フレームワークの利点などの検証の参考となるかと思ったので書いておきます。
ASP.NETでは、「検証コントロール」というのが便利そうだ。
「プログラムを作成するたびにこういうのをいちいち書いたりしなくていい」という
部分の利便性は良く分かる。
ASP.NETで学ぶVisual Studio .NETの魅力
第2回　Visual Studio.NETでプログラム・レス開発を学ぶ（前編）
http://www.atmarkit.co.jp/fdotnet/aspandvs/aspandvs02/aspandvs02_04.html
だが、こういうのは逆にそのフレームワークに縛られてしまうのが欠点だな。
準備されてるコントロールを自分の意図するようにやりたいが、その方法が誰も分からない
もしくは、出来ない場合は、それで終わりみたいな。
話はずれるが、Accessで開発してる時、各種コントロールやウィザードの組み合わせでは
対応出来ないと感じたのを思い出した。ウィザードが準備する通りの物が目的ならば良いのだが、
それにちょっと変更を加えたい場合はどうしたらよいのかという感じ。各種プロパティーの
値を変更してみても変な方向に変わっていくだけ。
自分の意図するようにカスタマイズしたい場合は、非連結のテキストボックスを貼り付けて
VBAで制御するスタイルでやってたな。
436 ：: Accessではグリッドが無いけれど、サブフォームで代用する方法はある。
しかし、そのカスタマイズ度は低い。（確か、クリックしたセルの場所を
取るとか、一つのセルだけ色を変更するとかがかなり苦手だったような。）
サブフォームで代用できない場合は、フォーム上にグリッドを貼り付けるような
モジュールは無いので、DBへのアクセス手段が手軽なものを捨ててでも
VBで0から作り直すのが一般的な選択方法となる。
Webアプリのフレームワークでもこのような状況になる事ってあるのかなぁ？
437 ：: PDOを継承する形でこんなクラスにしてみました。
突っ込みどころ満載だと思うんだけど、とりあえず、このコーディング方法はやめておいたほうがいい、
っていうところを教えていただけると嬉しいです。
class DBConnect(){
// メンバ変数にDB接続情報を記述
function __construct(){} // PDOをインスタンス化
function getConnID(){} // PDOオブジェクト格納変数を返す
}
class TableCtrl extends PDO{} //PDOを継承、汎用関数を定義してもOK.
class CtrlA extends TableCtrl{ // テーブルAを操作する
protected $ConnID;
function __construct($ConnID){} //PDOオブジェクト格納変数を渡す
}
438 ：: スクリプト先頭で、DBConnectをnewして、PDO格納オブジェクトを受け取ってから、
それを引数にCtrlAをnewする感じ……。
一応動きはするけど……全然ダメだな……。
439 ：: >>438
なんでもいいけど、既存のフレームワークがどうなっているか見てみろ。
見たら自分で作るきなくなるけどなｗ
440 ：: >>439
返信ありがとう。
まったくわかってないみたいなので、クラスの設計方法から学び直します。
実際の処理をする具象クラスを作って、また別に、それを統括するクラスを作っていく。
複数のクラスを設定によって使い分けしなきゃいけない場合は、抽象クラスなりインターフェイスなりを継承（後者の場合は実装）させて、
メソッド名を統一させた上で、ポリモーフィズム――クラスによって同名メソッドの振る舞いを変えさせるって解釈でいいよね？――で実現させる。
基本こんな感じかな？
プリペアドステートメントに惹かれて、PDOを継承する形で作って見たんだけど、
DB接続関連の場合、接続IDを返してくるmysql_connect(); なんかのほうが、使いやすい気がする。
フレームワーク自作なんて、自分にとってはとんでもない話しですよ……。
441 ：: お前の下らない御託はいいから見ろっつの
442 ：: >>441
ごめん、無視してたわけじゃないんだ。
とりあえず、軽い「ちいたん」とやらを見てきます。
スレ汚し、ごめんなさい。自重します。
443 ：: なぜちいたんを選ぶか・・・
444 ：: ( ﾟдﾟ)ﾎﾟｶｰﾝ
445 ：: 救いようが無いな。
446 ：: スレのレベルを下げちゃってごめんなさい……。
軽い「ちいたん」が入門にはちょうどいいかな、と思っての選択です。
いきなり、CakePHPなど大きいのを見ても、余計に混乱しそうだったので。
スレのレベルを余計に下げるだけなのでROMします。
度重なるスレ汚し、失礼しました。
447 ：: >>324
>>335
掲示板スクリプトの改善、どうもありがとうございます。(*^^*)v
↓動作サンプルを設置しました。
http://ssurl.net/n777
http://ssurl.net/ioah
448 ：: フレームワークをみてみろとアドバイスをしてくださってる方は、
もう少し具体的なアドバイスを出して欲しい。
具体的に、どんなフレームワークの構造を見て、どんなことを
学んだのかなどをあわせて出してくれたら、勉強もしやすいと
思うのですが。
449 ：: お前は人に逐一指示されないと何にもできないんだな
450 ：: フレームワークはどこに行けば手に入りますか？
451 ：: >>449
漠然としすぎていて良く分からないのである程度は具体例が
欲しいという意味なのですが。

>>450
こちらへどうぞ
【PHP】フレームワークについて語るスレ10【総合】
http://pc11.2ch.sc/test/read.cgi/php/1202521438/l50
452 ：: >>451
そのくらい自分で探せよという意味なのですが
453 ：: >>451
自分でDBの抽象化を考えてみて、クラスの定義だけでも書いてみろ。
その後にZFのZend_DBを見て、自分のとどう違うか、なぜそうなっているのかを考えろ。
それから、偉そうな態度で教えてもらおうと思うな。
454 ：: 別に偉そうじゃないだろ。
むしろお前のほうが偉そうだ。
何被害妄想してるんだｗ
455 ：: 本気でOOP勉強したい人はまずPHP止めないと・・
PHPの世界にOOPの参考になるものがどれほどある？
javaやらずOOP出来ましたってありえないでしょ。
456 ：: >>455
OOP勉強するなら、SmallTalkだな。
Javaとかアフォ？ｗ
457 ：: 本気でOOP勉強する為にPHPをやめる必要は無い。
PHP使いながら、OOP勉強すればいいだけ。
本気でOOP勉強をするなら、非実用的な言語も含めていろいろな
言語を使うことになる。そしてそれらが実用的かというと別の問題。
いくらsmalltalkでOOPをマスターしました！とかいっても
それでウェブサービスを作ることはまずありえないんだから
手段と目的を逆にしないようにね。
458 ：: その論争は、きりが無いから、マ板とかのOOPのスレでやって欲しい。
「スクリプトの世界ならRubyだろ。」とか、結論が見えてこないし、
このスレの趣旨とは違うと思う。
459 ：: >>457は非常にすばらしいことを言ったと思う。
460 ：: 確かにPHPでOOPの解説をしている情報は非常に少ないので、
勉強の際はjavaやC#などの情報を読みながらやることになると思う。
しかし、PHPを辞めるまでする必要性は無いと思う。
言いたいのは「OOPの勉強するのなら、PHPに限定してはいけないよ。」
じゃないの？
461 ：: 本気で勉強する為にPHPをやめた。
そしてOOPをマスターした。
しかし、Javaでは共有サーバーで動くソフトを作れなかった。
多くのオープンソースアプリはPHP製だった。
OOPをマスターしたが、何も出来なくなった。完。
462 ：: 前から思ってたんだが、頭の悪い人間が粘着してるな。
自分がどんな風に思われてるかも分かってないんだろうなｗ
463 ：: >>457
> いくらsmalltalkでOOPをマスターしました！とかいっても
> それでウェブサービスを作ることはまずありえないんだから
今やウエブサービスに欠かせないMVCはそもそもsmalltalkのOOP由来なんだが…。
継続ベースだって覚えておいて損はない。
http://www.ibm.com/developerworks/opensource/library/os-lightweight8/
http://www.ibm.com/developerworks/jp/java/library/j-cb07056/index.html
464 ：: PHPでOOPする為に別の言語でOOPの勉強をする。
自分の為に必要だからやるだけ。
465 ：: >>463
うん。だからさ勉強・研究の為の言語と
実用・開発の為の言語は別なの。
466 ：: このソースの解析をがんばればいろいろ見えてくるだろうけど、
一人じゃ到底無理だろうな。別スレでも立てて、解析して
ドキュメント作ろう！見たいなことやってみる？
Visual Studio 2008で見る.NET Frameworkのソースコード
http://www.atmarkit.co.jp/fdotnet/insiderseye/20080222sourcecode/sourcecode.html
> 公開されたソースコードには（もちろん英語だが）多くのコメントが入っており、
> ローカル変数名も元のままの“生”のソースコードである。
> そしてそれがVisual Studio 2008でシームレスにトレースできるようになる
467 ：: >>447
サンプル見たけど
Viewで変数が入らないとこで”を使ってる意味がわからない
”と’の使い方間違ってると思う
面倒な使いわけするならsprintfという手もある
パラメータ変数が渡ってくる
switch文のcaseに頭文字を大文字にしてる意味がわからない
468 ：: function html_head(){
echo "<html>";
echo "<head><title>BBS</title></head>";
echo "<body>";
}
上は、こうでいいやん！
function html_head(){
echo '<html>';
echo '<head><title>BBS</title></head>';
echo '<body>';
}
なんでダブルクォートやねん
469 ：: >>447
class View_Baseは
helper的な役割だからいいとしても
View_List
View_WriteFinish
コントローラで判断させるべき機能が
Viewで書かれてるし
テンプレート化されてないのもあって
ぐちゃぐちゃですね。
ここがＯＯＰ構造を理解しにくい作りになってる
コントローラは面倒でもＯＯＰ理解するには必要だ
理解しやすくするためにテンプレート化も必要
470 ：: >>447
本来コントローラとModelがやりとりする部分が
コントローラが無いために
Ｖiewで処理されてる
ＭＶモデルですね！
ＯＯＰ構造化理解のためには
面倒でもＭＶＣモデルじゃないと
初心者を間違った方向に導きますよ！！
471 ：: >>469
具体的にどうすればいいの？
条件分岐してないから切り分けは良さげに見えたんだが。
viewは機能ごとの静的HTML吐くのとは違うの？
472 ：: http://www.microsoft.com/japan/msdn/practices/type/Patterns/enterprise/DesMVC.aspx
これの
アクティブモデルは、コントローラとは関係なくモデルで状態が変更される場合に使用されます。
これは別のソースでデータが変更され、この変更をビューに反映する必要がある場合に起こります。
株価相場表示を例に考えてみます。株価データが変更された場合、外部ソースからデータを受け取り、チッカーバンドや警告ウィンドウなどのビューを更新する必要があります。
モデルの内部状態の変更が検知できるのはモデルだけなので、モデルからビューに表示を更新するよう通知する必要があります。
って、hoge.php?param1=aaa¶m2=iiiみたいなリクエストを解析してコントローラがそれに応じたビューを選択して云々
ではなくて、例えばブログだったら記事テーブルにまだ一つもデータが無いときは「まだ記事が登録されていません」のビューをモデルが選ぶ、ってことかい？
だとしたらどうやって実装したらいいんだろ・・・
そのモデルを使用するビューをモデルに登録しておいて、モデルのデータによって分岐させて使うビューを選択。そのときにビューは出力に必要なデータをモデルからひっぱりだす
MSDNは書き方がやたらめんどいぜ
473 ：: コントローラがリクエスト解析
↓
そのリクエストにおいて必要なモデルのインスタンス生成
↓
モデルのメソッド呼び出す
↓
選択したビューのupdate呼びだして出力に必要な変数定義
↓
モデルがビューの出力するメソッドを呼ぶ
ビューはモデルからの変更を受け付けるupdateメソッドと出力するためのputHtmlメソッド持つインターフェイスを実装する
なんか間違ってますか＞＜　教えてください！＞＜
474 ：: なんですでにあるフレームワークを参考にしない？
475 ：: 474は無視してくれ
476 ：: >>472
それはようするに、株価データのようにユーザーが
ページを更新しなくてもデータが更新されるときの話。
コントローラがモデルからデータ引っ張ってきて
そのデータをビューに渡して表示という処理は変わらない。
↑この処理を、普通は「URLを開いた」というタイミングで行っているわけ。
しかし、そのタイミングだと株価データ表示のようなリアルタイムでの表示は難しい
人間がF5を押す必要がある。この場合も更新されているとは限らず無駄に負荷が高くなる。
それを（ウェブアプリ以外では）モデルからデータが変更されたよーと
コントローラ・ビューに通知し、その通知が来たタイミングでコントローラ・ビューが
モデルからデータを引っ張ってきて（ｒｙ）という設計方法がある。
それが>>472で言っていること。
モデルに対して、コントローラやビューを「変更あったら俺に通知してくれ」
登録することでそれを実現する。
（データに変更があったらコントローラ・ビューのこの関数を呼び出してくれとモデルに登録する）

でも、この設計。モデル（つまりサーバー）から変更の通知をすることになるので
ウェブアプリでは一工夫必要になる。結局は、JavaScriptを使って
一定ごとに変更チェックをすることになるわけだが、まあそれをAjaxとかの技術で
非同期的にバックグラウンドで行うことにより、見た目上はサーバーから
変更通知がくるような感じに出来るんでしょ？やったこと無いけど。
その通知を元に、画面の一部、もしくはすべてを再描画する。

あとは詳しい人に任せた。
477 ：: >>476
レス㌧
オブザーバパターンはWebアプリに不向きなのかー。
じゃあ、
//コントローラの実行メソッド
public function doExecute(){
if($this->model->getArticleNum() === 0){
$message = '記事がまだ一つもありません';
require_once('./template/Error.php');
}else{
$this->view->putHtml();
}
}
こういう、コントローラがモデルからデータ引っ張ってきて分岐して、ビューを選択する、ってのはアリなのかな？
ちょっとCakePHPとかの資料ググってくるは
478 ：: そういう場合Comet使うんじゃね？
Cometすげえ！って大騒ぎになってたころ資料見ても俺には何がなんだか理解できなかったけど
479 ：: １を含めてコントローラの役割が全然わかってないんだよ！
ＭＶモデルになってるんだよ！
CakePHP、symfonyのソースをよく解読してみろよ！
１のサンプルにはＶＩＥＷにコントローラで処理するコードかいてあるんだぜ！
480 ：: ＰＨＰでＯＯＰを追求すると
結局はＭＶＣモデルのフレームワークにテーマが行き着くんだよね
だったらＰＨＰフレームワークのスレと同じじゃんて感じで
ここでＯＯＰを議論するときは
ＭＶＣモデル以外を議論の対象にしたいよ
481 ：: >>478
ワロタ。目からうろこｗ
httpってのはクライアント（ブラウザ側）から聞くことしかできないんだ。
どうやってもサーバーから話しかけることはできない。
だから、たとえば一分おきに、
「データ変わったかい？」「変わってねーよ」
「データ変わったかい？」「変わってねーよ」
「データ変わったかい？」「変わってねーよ」
「データ変わったかい？」「変わってねーよ」
「データ変わったかい？」「変わったよ！」
って聞かないといけない。たとえ4分半の時点でデータが変わっていても
5分後に聞くまでわからない。Cometというのは、
「データ変わったかい？」・・・・・・・・・・・(4分30秒後)「変わったよ！」・・・（数分後）「また変わったよ！」
とこうなる。
本質的にはクライアントから聞いているわけだが、変更があるまで
みのもんたみたいにずっと溜めてから返答するため、
負荷の軽減とリアルタイムな通知が実現できるというわけ。
しかし、いまさらだけどhttpで無茶やりすぎだｗ
482 ：: 例え巧すぎﾜﾛﾀ
483 ：: >>479
だから具体的にどこがだよ？
484 ：: >>480
> ＰＨＰでＯＯＰを追求すると
> 結局はＭＶＣモデルのフレームワークにテーマが行き着くんだよね
それはPHPに限らず。
そもそもOOPが一番よく使われるのは、フレームワーク部分なんだよ。
OOPはフレームワークを作るときに使うものといっても過言じゃない。
通常のビジネスロジック部分は基本的に単純な命令の集まりになるので
OOPを使っているという感じは無くなる。
485 ：: >>484
だから結局フレームワークの議論になるんなら
このスレの意味が無いんだよ
486 ：: >>483
>>469
487 ：: >>485
フレームワークスレは、フレームワークの比較などを話すスレ
OOPはフレームワークを題材に、OOPの話をするスレ
おｋ？
488 ：: >>486
class View_List extends View_Base{
//
function Write_HTML_head(){
$this->html_head();
$this->html_title("---　PHP で OOP の BBS　---");
echo "<hr>";
}

// 書き込みフォームを表示させる。
function Write_HTML_form(){
$this->html_form_start("index.php");
echo "<b>[メッセージを投稿する]</b><br>";
$this->html_input_hidden("PAGE", "Write");
echo "タイトル：<br>";
$this->html_input_text("title");
echo "<br>";
echo "メッセージ：<br>";
$this->html_textarea("msg");
echo "<br>";
$this->html_submit("　書き込む　");
$this->html_form_end();
}
489 ：: //
function Write_HTML_foot(){
$this->html_foot();
}
//
function Write_HTML_data($line){
echo "<b>タイトル：</b>";
echo $line->GetName();
echo "<br>";
echo "<b>メッセージ：</b>";
echo $line->GetMsg();
echo "<hr>";
}
}
この中のどこがコントローラで判断させるべき処理なんだ？
490 ：: >>487
OOPはフレームワークを題材に、OOPの話をするスレならプログラム板だろ？
初心者だらけの、ここよりも良レスが来ると思うんだが
ＰＨＰにこだわる理由がわからない
ＷＥＢでのフレームワークならどれも仕組みは同じだろうに
じゃあperlでＯＯＰ、rubyでＯＯＰていうスレが無いのは何でなんだ？
491 ：: function GetNextData(){
if( $line = fgets($this->m_file_hd, 1024) ){
$line2 = split($this->m_pause_chr, $line);
$ans = new Line();
$ans->SetData($line2[0], $line2[1]);
}else{
$ans = "";
}
return $ans;
}
これは下記がいいだろ？
function GetNextData(){

$ans = "";
if( $line = fgets($this->m_file_hd, 1024) ){
$line2 = split($this->m_pause_chr, $line);
$ans = new Line();
$ans->SetData($line2[0], $line2[1]);
}

return $ans;
}
492 ：: // データを１行読み出す。
function GetNextData(){
if( $line = fgets($this->m_file_hd, 1024) ){
$line2 = split($this->m_pause_chr, $line);
$ans = new Line();
$ans->SetData($line2[0], $line2[1]);
}else{
$ans = "";
}
return $ans;
}
変数名の最後に数字使うのは初心者だろ？
もしコード拡張で数値計算が入ったら紛らわしい
493 ：: // データを最後に追記する。
function AddLast($title, $msg){
// ファイルを開く
$hd = fopen($this->m_file_name , "a");
// データを書き込む
$line = $title . $this->m_pause_chr . $msg . "\n";
fwrite($hd, $line);
// ファイルを閉じる
fclose($hd);
}
なんでflock入れないの？
494 ：: $line2 = split($this->m_pause_chr, $line);
はこれの方がわかりやすいだろ？
list($name,$msg) = split($this->m_pause_chr, $line);
495 ：: function GetNextData(){
if( $line = fgets($this->m_file_hd, 1024) ){
$line2 = split($this->m_pause_chr, $line);
$ans = new Line();
$ans->SetData($line2[0], $line2[1]);
}else{
$ans = "";
}
return $ans;
}
これは下記に修正した方がわかりやすいよ
function GetNextData(){
$ans = "";
if( $line = fgets($this->m_file_hd, 1024) ){
　list($name,$msg) = split($this->m_pause_chr, $line);
　$ans = new Line();
　$ans->SetData($name, $msg);
}
return $ans;
}
496 ：: 変数にオブジェクトが入ってくるなら
初期化はこうだった
function GetNextData(){
$ans = null;
if( $line = fgets($this->m_file_hd, 1024) ){
　list($name,$msg) = split($this->m_pause_chr, $line);
　$ans = new Line();
　$ans->SetData($name, $msg);
}
return $ans;
}
497 ：: else{
$ans = "";
}
これ全部
$ans = null;
に初期化に変えて
elseとっぱらった方がいいよ
返り値はオブジェクトが入ってるか入ってないかという処理なのに
空文字を返すのよくないよ！
498 ：: まぁ空文字もnullも演算子によっては同様にfalse扱いできるという点がPHPの特徴なわけで
499 ：: >>490
> じゃあperlでＯＯＰ、rubyでＯＯＰていうスレが無いのは何でなんだ？
人気が無い言語だからｗ
500 ：: プログラム初心者がPHPだけでOOPを習得するのはほぼ不可能に近いと思う。
OOP習得が目的ならあまりにも無謀だし、全くもって得策ではない。
フレームワークとか利用しても、ユーザが$_POSTとか直接呼べちゃうと
結局OOPの意味が無いんではないだろうか？むしろそれが出来てしまうPHPは
OOP理解には全く向いていない言語だとも思うのだ。
でも不完全ながら、PHPでOOPっぽくコーディングすること自体は楽しいと思う。
501 ：: >>500
> プログラム初心者がPHPだけでOOPを習得するのはほぼ不可能に近いと思う。
どんな言語でも当たり前。
> フレームワークとか利用しても、ユーザが$_POSTとか直接呼べちゃうと
> 結局OOPの意味が無いんではないだろうか？
まったく関係ない。
502 ：: PHPでＯＯＰするには
初心者じゃ無理だよ
オブジェクトの設計は上手に出来ても
コーディングレベルで初心者ならではのミスが目立つ
503 ：: ＰＨＰでＯＯＰ勉強は適してないよ
JAVA,C#,rubyみたいに
ＯＯＰを前提として作られた言語じゃないからね
504 ：: 「PHPでOOPは」みたいな話は何度も出てるのに、いつも具体的な話にならないのは何で？
505 ：: お前に知識がないから
506 ：: (　´･∀･`)へｰ
507 ：: 関係なくはないよ。グローバル変数として、どこからでも呼べちゃうんだから、カプセル化できてないってことになる。
だいたい$_REQUESTや$_SESSIONがオブジェクトじゃなくって、変数な時点で、PHPのウェブアプリでオブジェクトなんて使うなっていう、PHP開発者からのメッセージと理解すべき。
508 ：: グローバル変数が使えたら、カプセル化できない言語ってことになるのか。
そりゃすごい。
509 ：: 俺も、>>469に書いてる、コントローラで判断させるべき処理の具体的な
コードを教えて欲しい。
このコードの話が質問されても出ていないのはなぜ？フレームワークを
使わないと、理論を完全に実現できないとかそういう話だから？
510 ：: >>479=486も結局答えられてないしな。
だめだだめだと言うものの、何故だめなのか、どう書けばいいのかということには答えられない低レベル批判厨なのさ
511 ：: また見えなくすることをカプセル化と勘違いしてる高レベルプログラマさんのお出ましだ
512 ：: >>1 ◆SWtzLesEmM ：2007/02/23(金) 13:35:52
このスレも１周年を迎えてましたね！
…時間が経つのは早いなー。＞＜
１年前からあまり進歩してないのは気のせい？(・∀・)
513 ：: >>487
PHPでOOPを勉強するとき、フレームワークは良い見本になりますね！
>>490
>ＰＨＰにこだわる理由がわからない
ホームページ作成でPHPの勉強を始めました。
プログラミングの勉強をしていたら、手続き型以外にOOPという方法があることを知り、使えるようになりたいと思いました。
>>502
Zendが積極的に音頭を取って、初心者向けの情報提供をやってくれたらいいですね。＞＜
http://www.zend.co.jp/tech/
Zendの代わりに、PHPプロというサイトがPHP初心者のニーズをカバーしてくれているでしょうか？(・∀・)
http://www.phppro.jp/
>>503
Javaもちょっと勉強してみました。＾＾
…今使っているレンタルサーバだとJavaが動かない＞＜
>>507
自分で作ったクラスに関しては、クラス内に変数を封じ込めておけるので、スコープ（変数が操作できる領域）をコントロールできるのではないでしょうか？
PHPが最初から用意してくれているグローバル変数（$_REQUES等T）のデメリットがよく分からないのですが、いつでもアクセスできるのでこれはこれで便利だと思います。
とりあえず、PHPでOOPが使えるようになりたいです。
PHP以外の言語も使ってみて、必要に応じて使い分けができるようになれればイイですね！（´∀｀）
514 ：: フレームワークに関して情報提供どうもありがとうございます。
>>479
MVモデル…(ﾉ∀`) ｱﾁｬｰ
以前作った掲示板を、MVCフレームワークの形で作り直してみました。(^^)v
↓
http://ssurl.net/ryol
515 ：: 結局１のやりたいことは
アマゾンのアフィリエイトの誘導らしいｗｗｗ
516 ：: >>515
PukiWikiPlusでamazonプラグインをデフォルトのまま使うと、プラグイン作者さん？のアフィリエイトコードが付くようですね。＞＜
ttp://cafelounge.net/dev/?PukiWiki%20Plus!%2FPlng-in%20Customize#a5aa9e2a
>amazonアカウントを設定します。
>define('AMAZON_AID','mikoscafeterr-22');
アフィリエイトはやってませんが、とりあえず本の情報をまとめるのに便利なのでamazonプラグインを使ってみます。＾＾
517 ：: >>516
本の情報とかいらんよ
あと、valueclickのアフィリエイトも出てるし
あとＴＯＰページいくとgoogle広告も出てる
結局こういうことかいな
最悪やなお前
518 ：: 具体的な本の紹介をサイトに掲載することは俺は賛成だけどな。
でも、単に羅列してるだけよりも、読んでみてどう思ったのかという
レビューをだして、その人なりの評価を出して欲しいとは思った。
羅列しているだけだと、そのサイト特有の色を感じない。
519 ：: どう考えても本の紹介を書くのおかしいだろう？
ここだけじゃないけど
技術的なサイトに広告とかマジうざい！！！！
520 ：: 「OOPやるのならば、PHPを辞めた方がいい」といっている人は、
それをいいたいのならば、もっと具体的に言って欲しい。
「RubyはもともとOOPとして設計されている」とか抽象論で終わってるから
何も話が進まず、同じことの繰り返しが続いているんだと思う。
「$_POSTなど、グローバル変数があるからオブジェクト指向的な考えには
ならない」とかそういう話をしてもらえれば、勉強する人はそれを
それぞれに解釈して学んでいけるのではと思う。
「じゃ、辞めようか」と思う人もいれば、「じゃ、その部分だけ気を
つけていけばPHPでもOOPがやれるんだな」と思う人もいるわけで。
521 ：: １は誤解を招くことは面倒だからやめた方がいいよ
522 ：: >>519
そこまでいいきるのなら、じゃ、みなけりゃいいじゃんとか思うけどな。
あからさまなＣＭじゃなければいいと思うけどな。俺はこの本をつかって
こういう勉強をして、こういう役に立ったとか、いいじゃん。
このスレは勉強しようっていうスレなんだから。
523 ：: >>521
それにおいては俺も同意だな。
524 ：: 特に２ちゃんはスレ利用して
最終的に宣伝目的にするやつが多いからな
リンク先に広告があるかどうかだけはシビアに見てる奴が多いよ
525 ：: １００歩譲って本を紹介しても、それは構わないけど
それがアフィリエイトになってるのがおかしいよ
526 ：: 以前、面白いレスを自分のサイトに集めて、面白かったと思う
投稿も受け付けたりしていて、そのサイトに広告を出して儲けてた
人がいて、叩かれたことがあったからな。
あと、のまねこ。
そういう事件があったから、２ちゃんねるをつかって管理者が
儲けようとする目的で広告が掲載されていることにはぴりぴりと
している傾向はあると思うな。
２ちゃんねるを通じて何か企画をするのには賛成だけど、やるのなら
GPLライセンスでやるみたいな意識でやらないとだめなんじゃないかな。
527 ：: 書籍の紹介は良いと思う。そうしないと、@ITの紹介もだめになるわけで、
本当に内容の無いことしかかけなくなってしまう。
情報をまとめていることで、便利だというものもあるしね。
だけど、「アフィリエイトはダメだ」という意見には賛成だ。
528 ：: １がアフィリエイトするのは構わないけど
２ちゃんを利用するというのが問題あり
529 ：: ２ちゃんねるのスレのまとめサイトであるにもかかわらず、
アフィリエイトされていると、それがどこかで告知されて、
大きく騒がれると思う。このスレに厨を沢山呼ぶことにも
なりかねない。
記念パピコとかが大量に来るので、１は早急にアフィリエイトは
辞めるべきだと思う。
530 ：: 嫌いだと思う事と否定すべき事は分けるものだと思うが、ここでのOOPの議論を見れば
それができないのも仕方がない。
531 ：: >>530
ｋｗｓｋ
532 ：: ２ちゃん利用して金儲けはよくないし
まとめサイトで書籍紹介するのも始めてみて正直びびった
533 ：: ご意見どうもありがとうございます。もう少しPHPでOOPの勉強を続けてみます。
>>517
2chでソースコードを投稿（>>36-50）したら、>>53さんが「わかりにくいからWebサイトにまとめてくれ。」とアドバイスしてくれました。
とりあえず、無料サーバ（XREA）にまとめサイトを設置しましたが、XREAは広告を表示するようになっているので仕方ないですね。
ttp://www.xrea.com/?action=ad
>当サイトは、無料運営のため、広告コードを自分で挿入する、または、自動的に挿入して頂く必要があります。
>>521
アドバイスどうもありがとうございます。
PukiWikiPlusのamazonプラグインに付いていたプラグイン作者さん？のアフィリエイトコードは外しました。
>>526
CGM型のサイトを運営して収益が出る場合、運営者だけが利益を得て、参加者に利益が還元されないと、不公平＝不満に感じる人もいるかもしれませんね。
このまとめサイトは、ソースコード置き場＋自分のメモという感じで使っていますが、利益が出せるでしょうか？
営利目的の企画として行なうなら、企業や出版社等に運営してもらった方が、本格的になっていいかもしれませんね。(^^;
…どこかで「PHPでOOP」講座を作ってもらえないでしょうか？＞PHPプロさんとか？
>>527
勉強するとき、本を読む人っていますよね？
本は読まない人もいると思いますが、本の情報も調べたのでついでにまとめました。
534 ：: １の目的がよくわらん。
１がコテハン使ってスレをリードするのおかしいやろ？
まとめサイトも１が作るのちゃうやろ
名無しがやることやろ
535 ：: １がスレをリードせんといて
長くレスが続くなら
それは本当に需要のあるスレであって
１が作り上げたスレになってるやん
536 ：: >>533
１（個人）に利益が出てたら、必ず騒ぐ人が出てくる。
しかし、利益が出てなければ、その旨を断っておけば、
騒いでいる意見は無視しておけば、しばらくすれば蒸発
すると思う。
537 ：: >>534
俺は１ではないが。
> １の目的がよくわらん。
スレタイの通り。PHPでOOPを勉強する。
> １がコテハン使ってスレをリードするのおかしいやろ？
何がおかしいのかがわからん。
こうあるべきだとかいうガイドラインでもあるわけ？

> まとめサイトも１が作るのちゃうやろ
> 名無しがやることやろ
お前のローカルルールを押し付けるな。
１がまとめサイトやめたら変わりにお前がやるのか？
538 ：: >>535
お前のやりたいことの方が分からん。
変な哲学押し付けるな。
539 ：: スレ主がまとめサイト作ってるスレてあるの？
広告目的以外に見たことないんだけどｗｗｗ
540 ：: なんで事例が必要なの？
541 ：: >>539
だったら君が利用しなきゃいいだけでは？
542 ：: ＷebProg板で
スレ主がまとめサイト作ってるスレどこにあるんだよ？
543 ：: ２ちゃんにふさわしくない行動は見て見ぬふりは出来んよ
544 ：: １は需要のないスレを無理に上げるのやめて欲しいよ
自分の存在を認められたいだけのオナニスレだよ
545 ：: アフィリエイト見てオナニスレてことに確信がもてたよ
このスレは１の自己満足以外に何も生まれないよ結果としてね
546 ：: >>543-544
何で君はスルーができないの？
誰も書き込まなければそのまま消えていくんじゃないの？
547 ：: コテハン使って自慢げにソースコード公開するやつは
よほど腕に自信がある奴か
初心者相手に自己満足したい奴かのどっちか
548 ：: >>545
君の語りを見てオナニレスてことに確信がもてたよ
これらのレスは君の自己満足以外に何も生まれないよ結果としてね
549 ：: >>547
ああ、そうか。だったら君はもう来るな。
550 ：: １が名無しとなって言い訳してるくさいな
551 ：: >>550
俺は１じゃないんだけどな。言い返せなくてそれしかいえないんだな。
それにお前がここに常駐する意味はないよな。
552 ：: 記念パピコ
553 ：: コマツも軍需だよね
554 ：: さ　あ　、　も　り　あ　が　っ
　　　　　　　　　　　　　　　　　　て
　　　　　　　　　　　　　　　　　　　　　ま
　　　　　　　　　　　　　　　　　　　　　　　い
　　　　　　　　　　　　　　　　　　　　　　　　り
　　　　　　　　　　　　　　　　　　　　　　　　　ま
　　　　　　　　　　　　　　　　　　　　　　　　　　し
　　　　　　　　　　　　　　　　　　　　　　　　　　た
555 ：: １が書き込みしないと
恐ろしいほどさびれてんねｗ
１だけがＰＨＰでＯＯＰに興味があって
その興味を無理矢理に広めようとしてる
このスレの落胆ぶり見ればよくわかるｗｗｗ
556 ：: PHPにかぎらず、「オブジェクト指向」が一般化したと言っても、実際にはライブラリ（フレームワークを含む）が
クラス化されて、プログラマはそれを使ってるという程度の話でしかないから、OOPそのものの話が盛り
上がらないのは、当然といえば当然。
557 ：: WebProgで勢いあるのなんてくだすれぐらいだろ
558 ：: 何度も１のこと前向きにとらえようとしたけど
やはり1が何をしたいのかよくわからん
559 ：: OOPの勉強じゃないの？
560 ：: 自称非営利団体の運営を本業に転換する難しさのバーチャル体験学習。
乗せられたボランティアからの不満が噴出。
ありがち。そして解散。ありがち。
561 ：: 私も１が必死にスレ継続させてる意味が？？？
営利団体なら意味はわかりますが
562 ：: このスレ1年以上在るのに、 1 ◆SWtzLesEmM が書き込んだことがある日数って 16日だよ。
必死どころか、やる気があるのかと言いたい。
2007
02/23 02/24 02/27 02/28 05/12
06/12 07/06 07/11 07/26
2008
01/29 02/02 02/06 02/10 02/17
02/24 02/25
563 ：: 暇人乙
564 ：: まー、ここで勉強するな、とは言わないけど、本気でやろうと思ってる人は、まず自分で本買うなりして勉強すると思うよ。
別に興味ないやつはスルーでも何でもしときゃいいと思う。
565 ：: >>562
1自演乙！
566 ：: 自演度は THE END
567 ：: 保守
568 ：: このスレで、今日から貴方もOOP！！！＼(^o^)／
>>1
オッパッピーの間違いですよね
569 ：: 保守
570 ：: 保守
571 ：: 難解も、難解も、オブジェクト指向
572 ：: スレタイの主旨からずれるけど、
やはりC言語は、一度は学んでいた方が良いな。
Javaからプログラムに入ったから、PHPのOOPでアロー演算子使うのにとても違和感あったのだけど、
Cの構造体を知って、ドットシンタックスよりアロー演算子の方が正統派と思えるようになった。
573 ：: どっと疲れる
574 ：: どっと込む
575 ：: >>573
>>574
バカアロー
576 ：: 諸事情により、Web系のプログラミングから離れていたけれど、
また時間がとれたら舞い戻ってきます。よろしくｗ
577 ：: PHPに触る機会が・・・なんで、VBばっかりなんだ・・・
578 ：: 保守
579 ：: 保守
580 ：: クラスの作り方（設計）について、考え方が参考になる本がありました。
http://www.amazon.co.jp/dp/4798110558/
モデルとプロセスをめぐる冒険
「モデリング」ということについて調べてみると、いろいろノウハウがあるようです。
581 ：: 保守
582 ：: 保守
583 ：: 保守
584 ：: 大手ECサイトのヨドバシドットコムが、サイトリニューアルから大規模な障害を3日間...
http://detail.chiebukuro.yahoo.co.jp/qa/question_detail.php?qid=1220150877
506 ：目のつけ所が名無しさん：2008/10/26(日) 00:47:20
大手ＥＣサイトで、ここまで派手なリリース失敗は初めて見た。
エンジニア向けＩＴ情報誌や関連サイトは、ぜひ取材して原因を明かして欲し
いは。
585 ：: 保守
586 ：: 保守
587 ：: 定期的に保守してるの誰？
糞スレに対してその執念が怖いんだが。。。
588 ：: お前の粘着質の方が怖い
589 ：: PHP でオブジェクト指向の設計をするための 7 つの良い習慣を身につける
http://www.ibm.com/developerworks/jp/opensource/library/os-php-7oohabits/
PHP での適切な OO の習慣を身につけることによって、より安定していて、保守が容易で、拡張も容易にできるアプリケーションを作成することができます。そのためには、次のことを忘れないでください。
* 控え目である
* 良き隣人である
* メドゥーサを見ないようにする
* 結びつきを極力弱くする
* 結束性を高める
* 家族の一員として扱う
* パターンで考える
こうした習慣を身につけ、使いこなせるようになると、皆さんはきっとアプリケーションの品質が変わったことに驚くはずです。
590 ：: 内容は否定しないが、その書き方はどうかなと思うな。
英語の翻訳だからなのかな。
「メドゥーサを見ないようにする」なんて飛躍した比喩表現では
イメージつかないだろｗ
591 ：: http://phpspot.org/blog/archives/2008/11/php_7_1.html
パクりblog乙
592 ：: >>589
メデューサの項目でインタフェースを使う意義って何？
ファクトリーパターンの利点しか説明してないような気がするんだが
593 ：: >>591
広告の方が多いってどうなんだよ
1:4で広告じゃねーか
594 ：: DIコンテナとかどうなのか
595 ：: オブジェクト指向のカンタンな例
<?php
class A
{
function foo()
{
echo 'hello <br>';

}
}

$a = new A();
$a->foo();
$b=new A();
$b->foo();

?>
596 ：: 簡易なMVCモデルのサンプルってないのかなぁ。
フレームワークを作るとか、フレームワークを使うとかじゃなくてさ。
考え方を学ぶためにみてみたいんだけど。
過去ログにあるように、つい、MVモデルになってしまうもんで。
597 ：: 巷に星の数ほどあるだろ
598 ：: Googleで、
簡易なMVCモデル
と検索させる
ttp://www.google.com/search?client=safari&rls=ja-jp&q=簡易なMVCモデル&ie=UTF-8&oe=UTF-8
ドゾ...
599 ：: 結構前の話だけど、>>488-489へのレスってついてるのかな？
過去ログ読み直してみても、何処が批判されているのかが分からん。
Viewはこれでいいと思うのだが。

600 ：: http://www.zend.co.jp/tech/index.php?cmd=read&page=%A5%B3%A1%BC%A5%C7%A5%A3%A5%F3%A5%B0%BB%D8%BF%CB%2F%A3%B4%A1%A5MVC
ひょっとして、「Viewではhtml出力をしてはいけない」という考えを示している
ということなのか？
html出力は別のクラスに任せるべきで、Viewはそのクラスのインスタンスの生成
と実行までを行うべきだという視点で批判してるとか。
601 ：: はい？批判ってどれ？
602 ：: >>601
批判している書込みは>>479です。
「に」のサンプルが、（コーディングにかかわるルール以外で）
MVCの設計はこれで良いのかがあいまいなまま終わってる気がします。
603 ：: 気になってる批判は>>469もだな。そして>>471となっているが、そのレスが
無くておわってないかい？
604 ：: よくわかんないんだけど、OOPとMVCって両立できるの？
605 ：: MVCをOOPで実現するんだろｗ
606 ：: これどうなの？
ttp://www13.plala.or.jp/naka_jima/php/chapter12.html
607 ：: どうって何が？
608 ：: MVCだと必ずフレームワークを使わなければならないわけでもないよね。ちがうの？
それとも、非常に単純なクラス構成でMVCを実現しようという考えが間違いとか？
609 ：: 別にいいんじゃ？
610 ：: >>606見たんだけど、MVCってこんななの？
View や Model 1つに対して1ファイルみたいだけど、ファイル量半端ないことになりそう。
611 ：: DBの形式や最終的な見せ方によって、ファイル数は変わるんじゃないの？
でも、MVCってわりとファイル多めだよな！
1ファイルのコード量、大して多くないけど
612 ：: ファイルが多めなのが嫌なら１ファイル内に複数書けばいいじゃない
613 ：: OOPそのものをやろうとするとクラスやファイル量が多くなるからね。
汎用性を考えて作ろうとするとなおさらだ。それはしかたがないのかも。
そこをあえて、フレームワークや外部のモジュールなどを使わずに
非常にクラス数を少なくしてやってみたいなと思うんだけどね。
MVCの理解の一環として。
614 ：: やってみればいいのでは？
615 ：: <?php
class Framework{
// コントローラー
public function controller(array $inp){
$model = $this->model($this->di('Action', $this->di('Action_Mapper',$inp));
$this->view($model);
}
// モデル
protected function model(Action $actions){
return $action->do();
}
// ビュー
protected function view($model){
print ($this->di('View_Helper', array($model));
}
// DIコンテナ
protected function di($class, $options){
return new $class($options);
}
}
class HelloWorld extends Frameworkd{}
App::controller($_GET);
616 ：: なんじゃそりゃ
617 ：: 最後の一行間違い
618 ：: せめてクラスは３つ以上にするべきだろ。
最低限といっても、ファイルを読み込んで表示とか、書き込みとかの処理まで
出来る機能を持ったほうがコントローラとビューの違いが明確に分かりやすく
なると思うんだけど。
619 ：: これはMVCどこがやるのが妥当か？
ってところで迷う。
時々、曖昧なのが出てきちゃう。
620 ：: >>619
ここで事例を通じて具体的な意見を交わしていけばどうかな？」
例えば・・・
掲示板
■コントローラ：処理の内容を判断するクラス
・プログラムが実行された時、一番最初に実行される
・POSTの値をみて、以下の処理にてどれに該当するかを判断する
　・データを表示する
　・データを書込む
　・編集用のフォームを表示する
■ビュー：htmlのレイアウト表示を担当するクラス
・以下のメソッドを持つ
　・データをhtmlで表示する
　・データ編集用htmlを表記する
■モデル：データファイルを管理するクラス
・ファイルの読み込み、書込みをする
・外部とは１件分のデータはBBSLineクラスでやりとりする
621 ：: >>620
『■コントローラ：処理の内容を判断するクラス』の
> 　・データを表示する
> 　・データを書込む

『 ■モデル：データファイルを管理するクラス』の
> ・ファイルの読み込み、書込みをする

って、意味が重複しているような感じがするのですが...

ならば、
■コントローラ：処理の内容を判断するクラス
　　・モデルからデータを受け取る
　　・モデルにデータを渡す
とかでは、おかしいですか？
622 ：: >>621
>>620じゃないけど。
・データを表示する
・データを書込む
・編集用のフォームを表示する
実際に上記の作業をするのは View と Model だよ。Controllerがするわけじゃない。
コントローラーはどれがリクエストされたかを判断して、適切な Model と View を呼び出す。
623 ：: >>469は具体的に何処のコードを批判しているのかが分からないので
どなたか解説を頼みます。
624 ：: MVCモデルでM同士で連携することってあり？
それとも必ずC経由？
C経由の場合、Mをなるべく疎結合になるように細分化してると、
Cの各Actionに書くロジック量が半端なく多くなってくるんだよね。
（Aデータを取ってきてBデータを取ってきてBをCバリデータに通してAとBを基にDを作成して・・・みたいな）
一つのAction内にロジックが増えるのもどうかと思うし、それって新しいモデルじゃんという気もしてこないでもない。
625 ：: >>624
俺はM同士で連携するかたちでも良いと思うけどね。
CからMを見た場合、あるまとまった処理単位でメソッドを呼び出す形であることが
重要だと思うから。
CがMを使うときは必ずメソッドＡ呼び出してメソッドＢ、メソッドＣを実行しなければならない。
さらに、そういう３連呼び出しがCの中に何箇所か書かれているなんていうのは再利用性などが
悪くなると思うから。
626 ：: 試しに掲示板をMVCでやったら、なんかやっとそれっぽくなった。
627 ：: >>626
うｐきぼん
628 ：: >624
変化する内部状態を持つモデル同士で連携させると見通しが悪くなる。
生成してから、（観察される）内部状態が変化しないようなモデルはどこから呼んでもそれほど大きな問題はない。
オブジェクトの生成期間中に（観察される）内部状態が変化するようなモデルは、C直轄にしといた方がいい。
629 ：: 生成期間→生存期間
なんか寝ぼけてた。
要は変化する「状態」を持っているもの全てはCの管理下に置いておいた方がいいってこった。
「状態」が無いもの（生成時にファイルからデータをロードしてそれっきり、とか）はどこにあったって構わない。
インスタンスの生成を行なうクラスは自分ルールでもいいからある程度絞っておかないと混乱すると思うけどな。
630 ：: 変な質問だけど、OOP での Validator ってのがよくわかんねえ。
is_numeric(); とかをModel内にべた書きしないで、Validatorオブジェクトを通じて、変数の内容を確認すればいいの？
$str = 'string';
$valid =& new Validator();
$valid->isStr($string);
みたいな感じで。
BaseValidator みたいな基本的なチェックをするクラスを作って、継承した先で複雑なチェック用のメソッドを実装させればいいのかな。
631 ：: 引数間違えてる。最後の行。
$valid->isStr($str);
ね。まぁ、別に問題ないが。
632 ：: 問題はありまくりだろ
633 ：: >630
ttp://gist.github.com/38261
俺はValidatorクラスはコントローラ単位で実装してる。「入力値の検証」なのだから、コントローラの責任。
Validatorだけ独立させるのはコードの見通しを良くするためであり、責任はあくまでコントローラにある。
ただ、実際にそっからコールするのはModelのメソッド。何が許可されるかを知ってるのはだいたいModelだからな。
たとえば受け付ける値が日付なら、そっから日付クラスのvalidateメソッドを呼び出す（MyDate::validate($string)）。
POSTされる中に列挙型（<select>から送られるような、選択肢が限られているもの）とかがあった場合にこの構成は滅茶苦茶強い。
<select>のためのデータ生成とか、送られたvalueから画面表示用の文字列（「～モード」とか）への変換を一箇所に集められる。
あと、文字列が決まったフォーマットになっているか調べる場合とかな。
is_strとかctype_stringとかstrlenだけで検証が終わるものはvalidatorクラス内に直書きする。
validateNumericとかvalidateStrとか書くよりその方が分かりやすい。
634 ：: >>633
ものすごく丁寧にありがとう。
まだぼんやりとしかわからないけど、サンプルコードを読み解いて、いろいろ試してみる。
635 ：: >>633
>「入力値の検証」なのだから、コントローラの責任。
「検証する」んじゃなく「検証させる」のが仕事じゃないの？
ここでいう入力値の検証って例えばどんなこと言ってる？
3行目で
>何が許可されるかを知ってるのはだいたいModelだからな。
って書いてるってことは、なにか、Modelに関係ないものを想定してると思うんだけど。
636 ：: >635
大雑把に言うと、処理を始める前に可能なパラメータの検証全般。
純粋に入力値だけを見て判定できるものだな。システムや環境の状態を見なくとも判定できるエラーを出す役割。
処理を始めないと分からないもの（DBに指定されたエントリーがあるかとか）は、バリデーションでは扱わない。
DBにこの値があった場合はクッキーにこれが無いといけない…みたいなのも対象外。
日付として「'9999-12-31'」が指定されてもバリデーションでは引っ掛けない。これは有効な入力。
「'2008-13-45'」はバリデーションでエラーとして引っ掛ける。この日付が有効になる事はあり得ないから。
メールアドレスが正しいフォーマットかをチェックするのはバリデーションで、それが有効なメールアドレスかをチェックするのはモデル。
ユーザーIDとして正しいフォーマットならばバリデーションは通るが、当該ユーザーがいない場合モデルがエラーを出す。
637 ：: >>636
なんとなく分かるけど、
例えばそれだと「2008-13-45は日付(のつもり)」ってことを
コントローラが知っとかないといけないってことだよね？
あと、日付が必要なくなった、とかいうときは
コントローラーを変更しないといけないってことにならない？

なんか拘ってるようでアレだけどお勉強スレってことで許してｗ
638 ：: って、もしかして、リクエストとして渡ってくるものを想定してるのかな。
hoge.php?date=20081231
とか。
639 ：: >637
「コントローラ」の指している範囲が俺と違う気がする。
俺はディスパッチャ（処理の振り分け）部分じゃなくて、そこから振り分けられる先のコントローラを指している。
ぐぐったが、「アクション」としてクラスにして丸ごとコントローラから切り離す文化圏もあるようだな。
「日付のつもりで送られてくる文字列がある」という事実は、ディスパッチャは（たいていの場合）知らない。
が、コントローラ（アクション）は知っている。だって知らないと日付具象モデルに処理を引き渡しようがないからな。
Cにはどの道変更が入る。リクエストをモデルに引き渡すのが仕事だからな。
「日付がどこからどう渡ってくるか」はCの管轄であってMじゃない。Mはそれを知っていてはいけない。
Mは「日付を渡されたらどうする」だけ知っていればよく、実際問題どこに日付があるかはCが隠蔽すべき。
たとえば、日付指定でDBからレコードを取っていたのを、「無指定時は今日と見なす」と変更したとする。
この場合は、Cを「日付省略時は現在の日付でMを呼び出す」ように変更し、Mには触れないのが正しい。
「省略時は日付を無視して過去のレコードを全取得する」という場合は、データ取得ロジックが変更なのでまずMは変わる。
制御の構造、呼び出しインターフェイスも変わるのでCも変わる。
640 ：: まあ実際は、日付省略時のMの挙動を変えるだろうけどな。
>638
入力値以外のもの（DB内の値とか処理結果）の検証は当然モデル。
というか、そういうのは一般にはバリデーションとは言わずアサーションと呼ぶ。
641 ：: >>639
Cは振り分けだけが仕事だと思ってたんだけど。
その先にさらに C があることなんてあるのか。
サブコントローラーみたいな感じ？
642 ：: >641
やっぱ、そこか。
例えばブログの場合、エントリー群を司るモデルや、タグクラウドを司るモデルができる。これは自明だな。
で、データを受け取って画面を表示するだけの、ごく単純なビューがいる。これも自明。
で、それら呼び出してページのデータを作る、という「データの統合」を司るクラスが必要になる。
これをMVCのうち、MとCのどっちに置くかの問題。
MVC、MVCって言ってるけど、本質的には4層なんだよ。
処理の振り分けに1層を割くならば、4層なくてはならない。
処理の振り分け=呼び出すCの決定（ディスパッチャ）→どのMを呼び出すかを制御する（コントロール）
　→データを実際に扱う（モデル）→表示（ビュー）、となる。
実際のフレームワークだと、RailsやZendはDispatcherが振り分けを担当し、制御はコントローラが執っている。
（だから、おまいの目から見れば、コントローラは仕事をやりすぎに見えるはず）
SymfonyやCakeだとControllerがディスパッチを担当し、制御はActionが執っている。
CodeIgniterだとディスパッチは単一のエントリポイント（リクエストを受けるphpファイル）であるindex.phpが行なって、制御はCが行なっている。
643 ：: >>642
>たとえば、日付指定でDBからレコードを取っていたのを、「無指定時は今日と見なす」と変更したとする。
>この場合は、Cを「日付省略時は現在の日付でMを呼び出す」ように変更し、Mには触れないのが正しい。
これって制御じゃなくてロジックだからモデル的仕事じゃねぇの？
644 ：: >>642
横槍で質問してすまんかった。
すげーわかりやすい。
勉強になった。ありがとう。
645 ：: 4層ｗｗｗ
646 ：: >>645
あなたの顔に死相が出ていますよ。4層だけに。
647 ：: 考え方としてディスパッチとコントロールは分けるべきだが、
実装するときは、コントロールで括るよな？
648 ：: >647
M・V・Cで分けるならCってのは同意。いちおう
> 処理の振り分けに1層を割くならば
と予防線は張ってあるわけだが。
俺はControllerの親クラスとかControllerFactoryでディスパッチする事が多い。
649 ：: >>648
> Controllerの親クラスとかControllerFactoryでディスパッチする事が多い
ディスパッチャーのインターフェースを作って、コントローラクラスでインプリメンツするってのは駄目なの？
650 ：: 保守
651 ：: 保守
652 ：: 手始めに、サイトのリニューアルついでにSmarty入れてCMS'っぽく'してみる。
653 ：: お？サンプルか？
654 ：: 勉強すればするだけフレームワーク使えば手っ取り早いことがわかった。
自作のモチベ下がっちまったい。
655 ：: 自作する理由は楽するためじゃないだろう
656 ：: もっと手っ取り早く使えるフレームワークをつくるために勉強すればいい
657 ：: 元々目的としては自サイトで使うための軽量フレームワークを作るために勉強してたの。
で、既存のフレームワークのマニュアルとかソースを参考にしながら作ってたんだけど、取り込むつもりが逆に呑まれた形。
658 ：: 凄く難解なソースを引き継ぎさせられて、途方にくれかかった。
で、市販のモジュールを使うなどして０から作り直すなどの方法を
模索したが、結局は引継ぎしたソースを解読して手を加えるのが
楽で、早い道であることが分かった。みたいな話かな？ｗ
PHPではないが、俺はちょうどこんな感じの体験をしたことがあるｗ
659 ：: まぁ、たぶんそんな感じ。
要するにフレームワークの魅力に気付いたわけですよ。
660 ：: 先に気づいてからやれば良かったな
661 ：: そういうのは簡単に気づけないだろう。
プログラムは体感して分かっていくものなのだから。
662 ：: 俺としては魅力に気付けただけでも大きな進歩だ。
自作云々は別にして。
663 ：: あけおめ
664 ：: では、その気づいた魅力的な部分をここなどで紹介してみるというのはどうよ？
PHPでOOPのスレの趣旨に添ってると思うし、他の人の意見を聞いて
参考になる部分もあると思うのだが。
665 ：: >>4
宣伝乙
666 ：: えらく昔の書き込みにレスしてるな。
667 ：: フレームワークの魅力についてまとめてみるか？
668 ：: どうぞ
669 ：: >>667
wikiにしてもらえるなら俺も手伝う
670 ：: いや、俺はそんなに文章がかけるほど知識は無い。申し訳ないが、サポートに回る
671 ：: なぜにフレームワークの魅力をまとめようと？
672 ：: >>662 ≠ >>667
だからね。
俺は人に語れるほどまだ理解してないから。
673 ：: なんだ教えて君か
674 ：: おまえもな
675 ：: サポートするといってるんだから、教えてじゃないだろｗ
676 ：: ttp://q.hatena.ne.jp/1188498291
677 ：: >>676を読んでみて、PHPに限らず、ASP.NETを体感してみると、フレームワークの
メリットやデメリットがみえてくるんじゃなかと感じた。
あれは、ポストバックとか独自の理論があって、それを学ばないと使えるようになれない。
しかし、ページをまたがってデータの受け渡しをする際は、非常に便利な機能であり、
使いこなせるようになると、生産性が向上する。
678 ：: 一問一答形式でwikiでも作るか
679 ：: visualstudioが優秀すぐる
680 ：: Java とか C#やったほうが飲み込みは早くなるのかな。
でも両者とも動かせるサーバって高いからなぁ。
Web以外にも用途はあるけど。
681 ：: >>680
いろいろな言語に触れてみると、その分視野は広くなることだろう。
共通して実装している機能を見ることで、OOPの概念をつかんだり
出来るはずだし。
しかし、広く浅くにとどまっていると、何も作れないで終わるので、
物を作る際は、一つの言語に絞り込んでいた方が良い。
なので、java や C# においてはローカルで稼動させるのにとどまらせて
おいたらどうかな？ASP.NET だと、Webアプリでもローカルでテスト動作
させる環境が Express にもついてるし。
682 ：: ウェブアプリの範囲なら、どの言語のどのフレームワークでも大差ないよ。
ASP.NETは、デスクトップアプリケーションからのアプローチなんで、これだけちょっと勝手が違うけど。
プログラミングを仕事にするなら、最初は型ありの言語をやった方がいいと思う。
JavaとかC#が理解出来れば、PHPやPerlはすぐに分かる。
683 ：: でも、perlってすぐ忘れちゃうよな...
684 ：: >>683
それはそれで良いのではないかと思っている。
perlのモットーがあわないのであれば、PHPを使うで良いと思うし。
685 ：: PHP では OOP を学べないという意見があるが、結論だけ
いうのではなく、その理由の部分を述べていくといいかもね。
686 ：: 別に学べるのでは？
687 ：: ん、どこかにPHPでは学べないと書いてあるのかな？
個人的には、純粋にOOPを学びたいのであれば別の言語がいいかなーとは思う。
理由は、Webは身近だし使い慣れてると言えるかもしれないが
PHP以外のHTMLやらJSやらHTTPプロトコル等知らなければいけない知識が多くあるから。
その辺を知っていれば問題はないと思うけどね。
688 ：: オブジェクト指向を本格的に勉強したければ、GUIのプログラムを書いた方がいい。ウェブアプリじゃオブジェクト指向が出る幕はない。
689 ：: 出る幕はあると思うが、最終的にフレームワークを構築することになると思う。
いきなりWEBフレームワークを作ることは難しいので、
実際に存在するフレームワークのソースを追いかけ、参考にしながら、
オレ的フレームワークを組み上げることで、様々な知見を得ることができると思う。
また、これらのフレームワークはたいてい、何らかのデザインパターンやアークテクチャパターンが使われているため、併せてこれらも学習する必要があると思う。
690 ：: WEBアプリでもActionScript3なら、バリバリOOPだYO!
691 ：: まあ、いつかはサーバサイドはAPIを提供するだけで、クライアントのUIはFlashとかJavaScriptに任せるような時代がくるのかも。
692 ：: >>691
エンタープライズならそんなケースいくらでもあるだろｗ
693 ：: >>689
俺的フレームワークなんて作らないほうがいい。
自己主張ばかり強い勘違いになりがちだし、遠回り。
良い先人の手本を眺めるほうがよっぽど効率的だわ。
694 ：: >>693
ホントにそうだとしたらとっくに淘汰されて現状のフレームワークの乱立状態にはならないと思うが
695 ：: >>692
聞いたことないな。そんなことするぐらいなら、Windowsアプリケーションなり、Accessなりで直接DBを参照するから。
696 ：: クライアントマシンの性能がこれだけアップしているのに、
クライアントマシンの性能を利用しないなんて
どれだけ無駄なんだかｗ
697 ：: ぶっちゃけサーバサイドのフレームワークは制作の効率のためであって
性能うんぬんは考えてないんだよな
698 ：: 勉強不足で申し訳ないんだが、制作の効率より性能うんぬんを優先したフレームワークを教えて欲しい
699 ：: つーか開発効率は性能に含まれるだろう
700 ：: は？
701 ：: 699 名前：nobodyさん[sage] 投稿日：2009/02/27(金) 05:45:51 ID:???
つーか開発効率は性能に含まれるだろう
699 名前：nobodyさん[sage] 投稿日：2009/02/27(金) 05:45:51 ID:???
つーか開発効率は性能に含まれるだろう
699 名前：nobodyさん[sage] 投稿日：2009/02/27(金) 05:45:51 ID:???
つーか開発効率は性能に含まれるだろう
699 名前：nobodyさん[sage] 投稿日：2009/02/27(金) 05:45:51 ID:???
つーか開発効率は性能に含まれるだろう
699 名前：nobodyさん[sage] 投稿日：2009/02/27(金) 05:45:51 ID:???
つーか開発効率は性能に含まれるだろう
699 名前：nobodyさん[sage] 投稿日：2009/02/27(金) 05:45:51 ID:???
つーか開発効率は性能に含まれるだろう
702 ：: >>698
性能を求めるならフレームワークなんて使うなって話
703 ：: >>698が言ってる「性能」って何？
これは釣りなのか？
704 ：: 「やあ、とりあえず性能の一番いいやつを一つくれないか。」
「今日はCakePHPがお勧めとなっております。」
「じゃあ、そいつをくれ。」
「かしこまりました。」
705 ：: >>703
なんで俺に絡むんだよ。
たった1個上のレスも読めないのか？
釣りなのか？
706 ：: >>705
何言ってるんだ？
1個上のレスを読んでるから性能って何って話だよな
707 ：: >>697に聞いてくれよ
俺は知らんよ。
使われた言葉返しただけなのにｗ
708 ：: 1ファイルにphp+html+css+jsべた書きが催促
709 ：: ＳＥＯ的に最悪だな
710 ：: 出力されるHTMLがSEOに合ったものなら、途中経過は関係ない。
711 ：: PHPでMVCってModel, View, Controllerの3クラスに
それぞれ適当な補助クラスをコンポジる感じでok?
712 ：: ng
713 ：: 検索するとViewは普通にHTML部分にしてクラスにしない奴が多いが…
それはどうだろう…
714 ：: >>713
別にありじゃない？
PHPTALってのもあるし
厳密には、TALに値渡す必要があるので、Viewが純粋なHTMLのみという訳ではないけど
715 ：: 未だにコントローラが何者なのかわからねえｗ
コンポーネントってのもよくわからんし。
716 ：: 基礎中の基礎すぎるだろ
717 ：: コントローラの役割そのものがわからないというよりも『どこまでがコントローラがやるべきことなのか？』ってことかな。
ビューとコントローラで迷うことはないけど、モデルとコントローラのどっちに書くべきかな、って言うのが多い。

まぁ、経験で補うもんだろうね。
718 ：: 100%中の100%！！！！！！！！！！
ｂｙとぐろ兄弟
719 ：: ってか3つに分けようとするから分からないんじゃない？
720 ：: >>719
なんだ君も教えて君か
721 ：: アセクサ
722 ：: アホクサ
723 ：: 保守しときます。
724 ：: 保守要らない板だから・・
725 ：: PHP研究所って全然PHP関係の書籍ださねーな。
社内だけで技術囲ってんじゃねーぞ。
726 ：: 全然おもしろくない
727 ：: オブジェクト指向で、MVCのMとCがいまいちつかめない
処理はModel、ViewとModelを制御するController
ってある。
例えば、ある条件を満たしたときに、データファイルからデータ一覧をリスト形式にしたくて、
・データ1
・データ2
・
みたいにずらーと繰り返しして表示するとき、
modelには、ある条件を満たしたしたかどうかを判断する処理を、
viewには<div>やら<ul><li>を、
controllerには繰り返しのwhileを？
って迷ってしまう。
でもwhileて処理になるからmodelに書いた方がいいんじゃあいの？、と・・
でもmodelにwhileの処理かくと、同時に<br>やらもmodelに書いて
viewには何を？・・ってなってしまって先にすすめない・・
つづく
728 ：: ごめん、やっぱりつづかない。
非常にわかりにくいかもしれないけど
こういうときって、素直にcontrollerにwhile処理いれとけばいいのかな。
でも、controllerに制限させるものが二、三個ならいいけど
もっとwhile処理するものが多くなれば、
処理がかぶってくるんだけど、
それが気持ち悪くて・・
なにか上手い回避方法を教えてください
729 ：: で、一応考えたのが、
viewにはhtmlタグだけを、
modelには条件処理とwhile処理を、
このwhile処理の中にviewで書いたhtmlタグを
放り込んで繰り返し処理。
controllerで、このmodelに引数入れてやれば
このmodelの変数には、
条件処理された結果と、
htmlタグつきのデータ一覧が格納されて、
表示される。
みたいにしたんだけど、これでいいのかな。
wikiのまとめサイトみるとmodelにwhileかかずに
controllerに書いてたから、何か意図があってやってるのかなと
730 ：: MVCまだ早いんでないかな
731 ：: Model はデータをどこからともなく持ってくる。
View にはテンプレートエンジン使って View の中でループさせる。
Controller は Model に「データ持ってこい」と頼んで、受け取ったデータを今度は View に渡して「表示しろ」と頼む。
View は渡されたデータをぶん回して表示する。
「頼む」ってのはメソッドを呼び出すことを指す。

嘘教えてたら許して
732 ：: >>731
というとつまり、もしも動的にデータを一覧表示させたいときなんかは、
”データ持ってこいとModelに頼む→Viewに渡して表示させる”
という一回の表示を、whileなりなんなりを使って何回も繰り返す操作を
Controllerがやるってことでいいのか。
733 ：: date.txtにdate1,date2,date3,date4ていうデータが入ってたとき、
"2"という条件を与えたときに、
date1<br>
date2<br>
"4"という条件を与えたときに、
date1<br>
date2<br>
date3<br>
date4<br>
という一覧を行いたい場合。
Modelには、指定されるデータを一つ引き出せるメソッドを、
Viewには、Controllerから受け取ったModelの一つのデータの後ろに、<br>を加えてechoするメソッドを、
そしてControllerで、Modelのメソッドを実行して、得られたデータをViewのメソッドへ渡し、一つデータを表示させる、
この操作を条件分繰り返すwhileもControllerに書いておく。
で、いいのけ
超基本的な場合、イメージ的には、
・Viewは、htmlしか知らない人でも、(phpの変数以外は)htmlタグ部分がはっきりしてるので弄ろうと思えば弄れる作り
・Modelは、処理されたデータを与える
・Controllerは、初期条件をMVに与えたり、MVにあるいろいろなメソッドの中から、
　必要なものを選んで、データを得たり、表示させたり（MをVに渡して表示させたり）、
　MVを組み合わせて完成したものを表示させる
みたいな感じ
だけで基本的名ことがまだまだ全然わからん
734 ：: >>732
まあ作り方によるんだろうけど……
ループでViewを何回も呼び出すよりも、例えば配列でデータを一度に全部渡しちゃって、Viewにループしてもらったほうがスッキリしない？
Viewの中にPHPの生のコードが入るのを避けたいなら、先に挙げたテンプレートエンジン使うとかすればいいし。
735 ：: >>734
たしかにそうか
ループするデータ表示のデザインて単純なものが多いだろうし
デザイン変更するときも、viewにphpのコードが入っててもそこまで苦にはならないか。
テンプレートエンジンどれがいいか決めれないし、
controllerにphpコードの種類がいっぱい入ってくると見にくいし長くなりそうだから
とりあえずはviewでループさせる方法にしてみるわ
あんがと
736 ：: >>727
レス全部読んでないから、的外れになるかもしれないけど、
MVCの基本コンセプトは『プログラムの着火点（エントリーポイント）は、URLである』
という考え方が中心になっているらしいよ
つまり、どんなWEBアプリもそのプログラムにアクセスしないと何も起こらないという発想。
そこから更に考えを発展させて、URLの一部にメソッドを含めよたのがMVCのポイント。
この、メソッドを含んだURLを処理する枠組みをコントローラにした訳。
だから、コントローラを中心にデータをサーバに貯めるならModelに、
データをユーザに表示するならViewにと処理系を分けた。
一般的にビジネスロジックはModelにとか言われるけど、
このビジネスロジックとはデータに正規表現をかけて別の形に置き換えるとか、
特定の数値を暗号化したりとか、殆どの処理の処理を指す。
だから、ロジックの中心はModelで処理され、コントローラはただMやVにデータを振り分けるだけに徹するのが
正しいMVC設計と言われてる。
実際のコード量もControllerが異様に肥大しているMVCは、悪いMVCとされている。
迷ったらMにロジック書いて、Cから呼出すようにする。
どうしても呼出せないロジックだけCで処理しよう。
737 ：: >>736
なるほど
完全に思い込みで、
Vには、phpコードでの処理に関連するものはほとんど無くしてhtml表示メインが良い
みたいになぜか考えてしまっていて、なかなか進めなかった。
＞メソッドを含んだURLを処理する枠組みをコントローラにした訳。
＞だから、コントローラを中心にデータをサーバに貯めるならModelに、
＞データをユーザに表示するならViewにと処理系を分けた。
これで、C、M、Vにはそれぞれこれをしようっていう考えが固まってきて
踏ん切りがついて先にすすめそうだ
とんクス
738 ：: ループして全部表示させるっていうのはVの仕様って気がするんだよねー。
最初の1件とか最初から100件とか、或いは全部っていうのはVの都合なわけで、
変更したいって思ったときはVだけ触ればよくしたい。
ってことで、
無駄とかなんとかは気にせずに、純粋な感じでいうと
Cの人は全部もらって、そのままVの人に渡す
っていうのがMVCぽいかな、って思う。
739 ：: >>738
俺は、Vの役割は「もらったデータを表示する」だと思ってるから、
ループする処理とかはCの役割だと思うけどな。
Vは、大量データ表示用のフォーマットや、１件詳細表示用のフォーマットを
持っているという形。
Cは、指定された件数のデータを表示させる機能を持っている、という形。
740 ：: 抽象論も大事だけど、具体的にコードを書いていきながら進めると分かりやすくなるかもしれないね。
質問者さんは、自分の思う発想でコードを書いてさらしてみたらどうかな。
それに対していろいろな人がレビューをすると何か見えてくるかもしれない。
741 ：: PHPじゃないけど、こんな記事があった。
ASP.NET MVC入門
http://www.atmarkit.co.jp/fdotnet/aspnetmvc/aspnetmvc01/aspnetmvc01_01.html
742 ：: OOPの理論って奥が深いな。
デザインパターンなども学んで理論に忠実に沿った理想的な
プログラミングをしてみたいなとも思ったけれど、つきつめると
ケースバイケースってことに落ち着くから、こういう、忠実さを
追いかけるのは無駄な考え方のような気もしている。
この考えで合ってるよね？ｗ
743 ：: 結論出ちゃったじゃないか
744 ：: それ、ASP.NETに新しく導入された「ASP.NET MVC」ってフレームワークの記事なんだよ。
そもそもASP.NETはイベントドリブンなフレームワークで、本来の意味でのMVCを採用してたんだけど、StrutsとかRoRとかがウェブで流行ったから、MSも似たようなフレームワークを作ったわけ。
だからのこれまでのASP.NETの方が本来的なMVCに近い。「ASP.NET MVC」は「ASP.NET ウェブMVC」とかって名前にすれば良かったのに。
745 ：: M$って、紛らわしい名前つけるのが好きだよね。
ASP.NETにおいてMVCに関する詳しい記事かなと思ったけれど、
実際に読んでみると、まったく別なフレームワークってことだった。
違いについて理解するのがひとつ面倒になったなぁ。
746 ：: stackoverflowを作ったヤツね。
747 ：: 保守しとくね。
748 ：: なんでカソってんだー
749 ：: PHPにおけるOOPは100ｍを自動車で走るようなもの
自転車を使え
走れ
歩いてもいいぞ
750 ：: ＯＯＰを使いまくる必要はないけど
必要な機能をモジュール化したいときにＯＯＰをいいとこ取りすれば便利
751 ：: >>748
秋田ｗ
752 ：: >>748
最初に設定していた目標が概ね達成出来たからじゃね？ｗ
っていうか、このスレに求めているものを書いていけば
盛り上がりを戻す可能性もあると思うよ。
質問するとか、何かソースを提供するとか。
753 ：: 一応保守しておきます。
754 ：: OOPのしっかりしてるFWどれ
755 ：: FWは、その開発目的によるので、結論は出ない。
いや、あおりとかじゃなくて。
756 ：: コードの参考になるのはどれかと
757 ：: PHPのフレームワークでMVCのタイプを使ってみました。
同じ機能を作るのに、コードを書く量が少なくて済むと楽ですね！
ただ、MVCだとスクリプトのファイル数が多くなると、ゴチャゴチャして見づらいと思いました。
MVC以外のフレームワークでオススメのものはありますか？
http://www.slideshare.net/NetPenguin/mvc-2659370
・PAC
・RecursiveMVC（HMVC）
・MMVC
・Doc/View
という仕組みが紹介されていました。
758 ：: 特に無い
759 ：: >>754
ttp://d.hatena.ne.jp/sotarok/20091126/modern_php_programming_at_pfi
↑このスライド資料の72ページ目に、PHPフレームワークの評価が紹介されていました。
・CakePHP
　世界でも日本でも大流行り。当然日本語での情報量も多い。
　Modelが使いやすい。それ以外は嫌いだけど。
　Cake3が別フレームワークにfork
・ZendFramework
　世界的にシェアNo.1？
　書く量の減らないドＭフレームワーク
　　というかいわゆるライブラリ群
・symfony
　これも利用者多い
　大規模向け。がっちりしてる。
・Ethna
　グリーはこれで動いている！（古いバージョンだけど）
・rhaco2
　大本命の超変態フレームワーク
　すごい
Ruby（RoR）っぽいFW → CakePHP / Lithium
Java（Struts）っぽいFW → symfony
Python（Django）っぽいFW → rhaco
というかんじでしょうか？
760 ：: >>756
ttp://d.hatena.ne.jp/kagigotonet/20091215/1260851032
>PHPはWeb特化言語という特性上他の言語では見られない強力な仕組みがあります。
>その特徴は他の言語では参照で取り回すところを文字列で取り回すところである、と言えるでしょう。
>可変関数
>PHPのフレームワークは、これを基本としています。ライブラリ、モジュールを動的にロードするのが非常に容易
>可変変数
>このように可変変数や可変引数を組み合わせるだけでも、少ないコード量でかなり複雑なことが可能になります。
各フレームワークのディスパッチ（処理の割当て）の仕組みを見ると、参考になりますね。
761 ：: >>750
「名前空間」を活用すると、たくさんモジュールを作っても分類が楽になりますね！
ttp://d.hatena.ne.jp/Fivestar/20091215
ttp://prezi.com/0-vyhjdkslih/
762 ：: 人の書いた文章を全文コピペするのはどうかと思うよ
763 ：: あ、上のは主に>>759に対してね
764 ：: >>734
>Viewにループしてもらったほうがスッキリ
そうですね。
データをループ表示させるのは、ビューの役割。
ビューの部分には
・テンプレート（HTMLファイル）
・テンプレートエンジン（HTMLファイルに文字列を当てはめるパーサー）
の二つが含まれている形にすれば、
表示に関するロジック（繰返し表示の処理など）はビューの中に置けばOK
＝表示に関する機能を修正する場合、ビューの中を探せばOK
765 ：: >>727
MVCのモデルはどんなふうに作るか？という話で、
・トランザクションスクリプト
・ドメインモデル
という二つのスタイルがあるそうです。
ttp://pc11.2ch.sc/test/read.cgi/php/1241341332/
ttp://proshile.blog.drecom.jp/archive/616
・トランザクションスクリプト
　→古きよきC言語時代の関数が主体の書き方
・ドメインオブジェクト
　→オブジェクト毎に内包する値と役割の責務を明確にしたOOPライクな書き方
MVCのモデルの部分は２層に分けて、
(1)ビジネスロジックコンポーネント
(2)デーアクセスロジックコンポーネント（O/Rマッパーを含む）
と分類する考え方があるそうです。
ttp://satoshi.blogs.com/life/2009/10/rails_mvc.html
ttp://d.hatena.ne.jp/p4life/20091014/1255532618
>Skinny Controller, Fat Model
・コントローラーはシンプルにする
・モデルに処理を集約する → 上記(1)ビジネスロジック＝データの加工を担当
・モデルはデータの整合性を保証する → 上記(2)データアクセスロジック＝データの読み書きを担当
ttp://www.virtual-tech.net/blog/2008/10/reflex-restful.html
ttp://www.virtual-tech.net/blog/uploaded_images/designold-722880.PNG
↑この図だと、モデルの部分が２層に分かれていて、
サービス層＝上記(1)
ドメイン層＝上記(2)
という形になるかと思います。
766 ：: >>728
C側に書いてあるコードを、なるべくM側の方に移動した方がスッキリするかも？
CとMの間のデータ受け渡しについて、こんな記事がありました。
↓
ttp://q.hatena.ne.jp/1242894491
>個々のSetterをオーバーライド出来るところが
>symfonyの便利な部分じゃないでしょうか。
>これが出来ないと個々のコントローラでデータを加工するハメになります・・。
>「MVCとして洗練されている」というのは
>「MVCに忠実に機能している」というのと同義かと思います。
一口にOOPと言っても、各フレームワークでちょっとずつ使い方に違いがありますね。
767 ：: >>89
フレームワークを使ってみて、OOPの使い方の理解が深まりました。
皆さん、たくさんのアドバイスをいただき、どうもありがとうございました。
分からないことがあっても、検索したり質問して１個ずつ埋めていけば、確実に進歩できると思います。
どんなプロフェッショナルな人でも、最初は素人だった…
これからPHPの勉強を始める方がいましたら、焦らずに頑張ってくださいね！(*^o^*)/
768 ：: どのフレームワーク？
769 ：: http://www.phppro.jp/school/oop/vol1/1
サイト見つけたので紹介しておきます。
770 ：: オブジェクト指向ってrequire文とinclude文みたいな考えと同じかな？
必要なときにどこからでも呼び出せるプログラムみたいなものだよね。
771 ：: うん
772 ：: OOPの説明で一番わかりやすかったのがプレーヤーの例
プレーヤーを継承した CDプレーヤー，MP3プレーヤーがある
それぞれに再生，停止，早送り，巻き戻し，次トラック，前トラックという機能(メソッド)がある
具体的な処理はそれぞれが行うので，使う人はプレーヤーの処理している内容を
理解している必要はなく，再生したいときに再生ボタンを押すという事だけ
分かっていればいい。(カプセル化)
つまり考え方であって，そういう意味では間違ってないのかもしれない。
773 ：: それぞれにあるのではなく、プレイヤーという抽象クラスにあるのでは？
774 ：: >>773
ダックタイピングなら、それぞれにあってもいいよね
775 ：: OOPの説明でダックタイピングの例出すの？
776 ：: >>773
そうなんだけど，具体的な実装がそれぞれ違うという意味で
ああいう書き方にした。
777 ：: >>775
PHPは型にしばられない（しばられなさすぎて困る）スクリプト言語だからね。
逆に、静的言語のように型を意識しすぎると、スクリプト言語のメリットが少なくなると思う。
「じゃぁ、お前、クラス階層つかわねーのか？」と言われればノー
コンポーネント（レイヤ）の中では、型を意識し、拡張する場合は継承も使用する。
コンポーネント間の接続は型ではなくメッセージ（メソッド）に束縛させるように意識している。
でも最近は、interface作って、抽象クラス作ってというのがおっくうになってきたので、可能ならメソッドポインタによるコールバックで済ませちゃうこともしばしば。
778 ：: Yiiブログチュートリアル　日本語訳
http://www.craftgear.net/docs/yii_blog_tutorial/index.html
本家の日本語訳が途中でストップしてるけど、こちらは全部訳してある。
本家
http://www.yiiframework.com/doc/blog/ja
779 ：: 保守しておきます。
780 ：: javaや.NETはたまたPythonあたりの純血PGが書けばOOPっぽいソースになると思うよ。
PerlとかPHPから始めました、ってのはだめだな。
781 ：: PHP6のオブジェクト指向ってなにか大きな変化ある？
782 ：: 遅延静的束縛とか
名前空間とか
783 ：: 名前空間は5.3だろ
784 ：: 遅延静的束縛もですが
785 ：: 機能追加がほとんどか。
じゃあ、PHP5のコードをPHP6に移植しても問題なく動くってことでいい？
PHP4→PHP5のときは大変みたいだったけど。
同じ思いをしたくない。
786 ：: 互換性見れば分かるだろ
787 ：: 逆に互換性なんかいいから関数の無茶苦茶な命名規則とか直して欲しい
788 ：: 関数はもうほうっておいて、
公式にオブジェクト指向ライブラリを提供すればよい
789 ：: >>788
SPLって公式じゃないの？
790 ：: 質問するのが怖いんだけど、自分はフォームのパーツを呼び出すのに
オブジェクト指向（クラス）を使ってるつもりなんだけど正しいのか自信がない
クラスformPartsの中で各プルダウンやラジオボタンの要素（nameとvalue）を
外部ファイルから読み込んどいて
$fp = new formParts();
$pref = $fp->callPullDown('prefecture',$val);
$job = $fp->callPullDown('job',$val);
$sex = $fp->callRadioButton('sex',$val);
こんな感じでメソッドでパーツの種類を指定しつつ（ラジオボタンかプルダウンか）
そのパーツの要素（都道府県とか職業とか）と既定値（$val）を投げて呼び出してる。
プルダウン要素とかは各メソッド内部で引数によって外部ファイルから読みこんでる。
クラスってこんな使い方でいいの？　継承とかはさっぱりわからない、どういう状況で使うんだか。
あと1さん凄いね、ガッツがあるなぁ。。
791 ：: OOではないな
792 ：: 分からないなら普通に勉強しろよ・・・
793 ：: ツールの勉強する前に基本を勉強しろ
794 ：: oopってさ
ＰＨＰ最大の武器であるＨＴＭＬとの親和性の高さを殺してるよね
795 ：: なんで？
796 ：: いまの流行はテンプレートだから
PHPのHTML埋め込みなんてもう古い
797 ：: そんな流行もあったねぇ。今は違うよ。
798 ：: kwsk
799 ：: テンプレートってどんな利点があるの？
そもそもPHP自体テンプレートみたな言語じゃん。
index.php
　<?php
　$title = "hoge";
　$hello = "hello world";
　include "template.php";
　?>
template.php
　<html>
　<head><title><?php echo $title ?></title><head>
　<body>
　<h1><?php echo $hello ?></h1>
　</body>
　</html>
こういうのとは違うの？

800 ：: ほとんどの言語は、HTMLの中で
コードを動かすという発想で作られていない。
コードーの中でHTMLを出力するという発想。
そういう言語ではテンプレートが重要。
PHPでテンプレートの意味が薄いのは確か
ただテンプレートの意味がまったくないかというと、そうではなく
分業作業。つまりプログラマとデザイナに分かれて開発するときは便利。
デザイナはphpコードはまったく知らない。だからなるべくシンプルな
記号レベルの書き方であってほしい。しかもDreamweaverのような
HTMLエディタで見たときに不具合無く表示されるものの方がいい。
801 ：: デザイナーでもHTMLとPHPの繋がりぐらいは分かる
いや、分かるようにPHPを書かなければならいと思う
それがPHP
802 ：: デザイナーって馬鹿だな
まで読んだ
803 ：: ここで議論してる奴らは世に影響力のないカスばかりだから参考にしなくて良い
804 ：: 廃れてるねー
805 ：: 852 忍者Perl ◆M5ZWRnXOj6 [] 2010/08/20(金) 13:30:09 ID: Be:
    マルチしてんじゃないですよクソゴミww（笑）wwww（笑）wwww（笑）wwww（笑）ww
    ww（笑）wwww（笑）wwww（笑）wwww（笑）wwww（笑）wwww（笑）wwww（笑）ww
    ww（笑）wwww（笑）wwww（笑）wwww（笑）wwww（笑）wwww（笑）wwww（笑）wwww（笑）ww
    ww（笑）wwww（笑）wwww（笑）wwww（笑）wwww（笑）wwww（笑）wwww（笑）ww
    ww（笑）wwww（笑）wwww（笑）wwww（笑）wwww（笑）wwww（笑）wwww（笑）wwww（笑）wwww（笑）wwww（笑）ww
    ww（笑）wwww（笑）wwww（笑）wwww（笑）wwww（笑）wwww（笑）wwww（笑）wwww（笑）wwww（笑）wwww（笑）ww
    ww（笑）wwww（笑）wwww（笑）wwww（笑）wwww（笑）wwww（笑）wwww（笑）wwww（笑）wwww（笑）wwww（笑）ww
    ww（笑）wwww（笑）ww
    PHPやってるやつノウタリンばっかりwwwwwwww
806 ：: PHPでOOPやると重いと感じませんか？
807 ：: いいんです！
コーディングが楽だから、OOPで良いんです！！
808 ：: 逆だろ
OOPだからボトルネックが把握しやすくてメンテナンスや新実装がしやすくなる
809 ：: しかし、実行速度遅くなるね
810 ：: 遅くなるって体感でわかるほど遅くなるのか？
だったら書き方おかしいよ
811 ：: >>810
体感できないとは幸せだね。
812 ：: case by case.
813 ：: >>736
コントローラを肥大させてはならないという概念ではわかりにくい。
もっと具体的に境界線を引くべきだと思う。以下俺の意見なんだけど、
MVCってユニットテストために
ユニットテストを難しくする汚染要素を隔離するためにあるのだと思う。
具体的に言うとこんな感じ。
View(GUI, xml, html, json)
Controller(Session, Request, Form, 画面遷移などWeb独自のデータ)
Model(RDB, KVS)
MとCが分離されることでMはWebスコープから分離され、CはSQLから分離される。
でもこの理屈だとVとCの関係がおかしくなっちゃうね。
CがVにデータを渡すときはリクエストスコープを経由しないで
直に関数の引数で整数や文字列、オブジェクトを渡すべきって話になるから。
814 ：: >>813
ゴバクしただけあって、センス悪いな。
815 ：: >>813
> MVCってユニットテストために
> ユニットテストを難しくする汚染要素を隔離するためにあるのだと思う。
正しいが、これは現場的な視点の１つの考え方。
MVCは、スケーラブルなサイト構築のためのパラダイムという方が、しっくりくると思うが...
816 ：: 新米PGに教える方法としては良いかもしれん
817 ：: PHPのOOPフレームワークを教えて下さい。
イメージとしてはJavaのStrutsのようなものです。
818 ：: JavaStrutsはさておき、おすすめはYIIだな。PHPの中では美しい。
819 ：: >>818
YII以外では無いのでしょうか？
YIIはOOPフレームワークとしては不完全です。
820 ：: >>819
どの辺が？
821 ：: >>820
オブジェクト指向言語であればオブジェクトを使用するところで、
配列を使用する点。
822 ：: >>821
なんでOOPフレームワークを使いたいの？
823 ：: >>822
OOPに慣れてるからです。
オブジェクトとして定義するところで
phpの場合、配列になるのでいらいらします。
たとえばCakePHP。ModelがModelになっていない。
やはり後付けでOOP機能が加わった言語では無理があるのですね。
824 ：: >>823
ModelがModelになってないというのは具体的にどういうこと？
825 ：: >>824
どのオブジェクト指向言語を経験しましたか？
それにあわせて話をします。
826 ：: >>823
phpで本格的なオブジェクト指向ははじめから無理だよ。
827 ：: PHPのOOP自体、後付けだし...
828 ：: >>825
Java
829 ：: >>828
ぜひStrutsの話を聞きたいですね。
たとえばCakePHPやsymphonyとどう違いますか？
830 ：: PHPのOOP関連機能が中途半端なのは当たり前。
実行速度が遅いPHPではそもそも向いていない。
831 ：: >>829
話をすると言って聞くばかりなのはなんでだ？
832 ：: >>831
Javaのフレームワークのことを教えてください
833 ：: >>832
ModelがModelになってないというのは具体的にどういうこと？
834 ：: >>833
Javaのフレームワークの比較で語りましから、あなたが今までにどのJavaフレームワークを使ってきたのか教えてください
835 ：: いやです
836 ：: >>835
無知の自慢するべきではない。
あなたは一生、PHPでOOPの真似やってた方がよい。
837 ：: 語りまし？
いやです
838 ：: phpでOOPはダメぽ
839 ：: いやです
840 ：: 完全にoopオリエンテッドな言語でしかoopしないって主張が、かなりダメぽ
841 ：: phpは継ぎ接ぎだからoopに向いてない
速度の面でも不利
842 ：: ダメな理由は遅いから。
843 ：: >>834
答えられないなら最初から言うな見栄っ張りｗ
844 ：: >>843
JavaのOOPについて語ってください。
話はそれからです。
845 ：: 質問者がJavaのどのフレームワークを使ったことがあるか書くべき
回答者がそのフレームワークとCakePHPを比較すべき
846 ：: そんな比較はどうでもいい。
phpのOOP機能は単なるおもちゃ。
847 ：: ttp://kameleon.s241.xrea.com/wiki/index.php?%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0%E3%83%AF%E3%83%BC%E3%82%AF%E3%82%92%E4%BD%9C%E3%81%A3%E3%81%A6%E3%81%BF%E3%82%8B
すいません
ここのフレームワークのソースをダウンロードしたいんですが、ダウンロードできません。
どこかで入手できないでしょうか
848 ：: ログインできませんでした。
10分ほどしてから再度お試しください。
849 ：: PHPでOOPやるとかアフォだろ
PHP自体カス以下だし
850 ：: ほらほら、釣り釣り。
参加者募集中
851 ：: 関数のオーバーロード
852 ：: 関数？
853 ：: phpの標準関数はどのクラスに属するのですか？
854 ：: PHPはC++と同じで、クラスに属さない
関数があるんだよ。
855 ：: クラスに属さない関数が多すぎ
そして、関数名が長くて、使いたいときに思い出しにくく覚えにくい。命名法が統一されてない。
856 ：: PHPでOOPやるとかwwww
笑わせるなよwwww
857 ：: 黙れ、情弱！
便所に行ったら手ぐらい洗え
つttp://sociorocketnews.files.wordpress.com/2012/06/after-toilet-wash-your-hands-japan01.jpg
ttp://sociorocketnews.files.wordpress.com/2012/06/after-toilet-wash-your-hands-japan02.jpg
ttp://sociorocketnews.files.wordpress.com/2012/06/after-toilet-wash-your-hands-japan05.jpg
858 ：: 俺はゴミカスだがエリートゴミカスだ
お前らのような下級ゴミカスとは格が違う
859 ：: 『オレは本当はスゴいんだ』病 www
860 ：: >>857
逆に女子はトイレ行ったら手を洗うの禁止な。
861 ：: phpでOOPとは単なるアホ
862 ：: じゃあOOPでphpするよ。
863 ：: ？
でも、よく言った！
864 ：: Java WicketとかPHP Piece Frameworkに流行ってほしいな。
平たく言えば何でもセッションに突っ込んでるだけなんだけどね。
865 ：: ここまでトレイトの話題無しかｗ
866 ：: 実際トレイトって、あれば便利な気はするけどどこで使うのか思いつかん。
だれか使いこなせてるって人いますか？
867 ：: PHPはむしろトラッシュ
868 ：: まだ5.4使える環境に出会ったことが無いわ
869 ：: なんでもセッションでいいよな
PHPってそういうもんだろ
870 ：: セッションハイジャックの脆弱性を可能な限り排除できるなら、
セッション利用でOK。
871 ：: >>1
PHPでOOPかよw
872 ：: PHPでOOPなど愚の骨頂
PHPなど愚の骨頂
873 ：: 3Pとか4Pがあるように00Pもあるのです
874 ：: OOPチーズ
875 ：: >>1
PHPでOOPはできねえよ
876 ：: PHPもOOPも時代遅れ
今はLOOP、すなわち論理オブジェクト指向プログラミングの時代
877 ：: 無限ループ
878 ：: PHPerがJavaのIDEなんか使ってんじゃないよ。
秀丸でちょちょいとやるのがオツってもんだ
879 ：: >>866
>実際トレイトって、あれば便利な気はするけどどこで使うのか思いつかん。
>だれか使いこなせてるって人いますか？
traitは scala から持ってきた仕組み。
(もちろん scala も他の言語から影響を受けている）
trait とは：
- Mixin - Wikipedia http://ja.wikipedia.org/wiki/Mixin
- traitは実装を含めることができるinterface
- コードのコピペをfunctionalityにしただけ
利用シーンとしては、継承したくないけど、
ある実装を、このクラスだけでは使用したいという場合に
traitを作って、それを使います。（だから、コードのコピペと表現した↑）
AS3を書いてたときはmixinはイベント機能を追加する目的で
よく使ってた
以下PHPでの実例をどうぞ↓
880 ：: カス言語PHPには無理
881 ：: phpのオブジェクト指向機能はおもちゃ。
882 ：: おもちはおもちや
883 ：: https://www.google.co.jp/#q=php+oop
約 10,600,000 件（0.13 秒）
PHPのオブジェクト指向入門 | オブジェクト指向PHP.NET
http://www.objective-php.net/&#8206;
884 ：: php
885 ：: >>1
オブジェクト指向は愚かな考え。排便メソッドを実装した人間クラスから美少女クラスが作れない。
http://toro.2ch.sc/test/read.cgi/tech/1393660194/88
886 ：: メソッドを実行しなきゃどうってことはない
887 ：: 美少女オブジェクトに排便しろというメッセージを飛ばすのか
胸が熱くなるな
888 ：: ガベージコレクションは自動で実行されるものなので我々が命令するものではない
889 ：: PHPでOOPなんてPOOP以外の何物でもない
890 ：: 誰でも簡単にネットで稼げる方法など
参考までに、
⇒　『半藤のブブイウイウレレ』というサイトで見ることができます。

グーグル検索⇒『半藤のブブイウイウレレ』

TVD73U3V71
891 ：2019/05/09: phpについて役立つ情報とか
http://mevius.2ch.sc/test/read.cgi/tech/1557329831/l50

4Z0

XSL/XSLT
FreeStyleWikiスレ
ウェブプログラミングで使えるデザインパターン
【Python】Webフレームワーク Djangoスレ Part2
PukiWikiスレ　Part8
FreeStyleWikiスレ
symfony PHPフレームワークpart2
赤ちゃん拾いました＠WebProg板
【Go言語】 webapp GO Part1 【Golang】
＠＠Ｐｅｒｌチャットでの荒らし対策＠＠
--------------------
【KFC】ケンタッキーフライドチキン 141【Ponta】
ｱｶﾐﾐｶﾞﾒで頑張るｽﾚその9
EPSON MOVERIO BT-300 Part.3
【4680】ラウンドワン2ゲーム目【ファイッ！】
FAIRY TAIL フェアリーテイル part50
KNG247★神奈川県鉄道障害情報
【デレステ】スターライトステージ★8249
ViVo 総合Part2
IDにバイクの名前が出たら神 Part.21
【効いてる効いてる】官邸、ネット上の政府批判にイラついていた ★7
☆★★筋トレなんでも質問スレッド571reps★★★
【イワナ】渓流釣り総合スレ12魚籠目【ヤマメ】
【一番左】サンデーモーニングを語る 42喝！
ラザニア
40代の阪神タイガースファン☆その33
シーバス阪神沿岸部★4【神戸空港～関西空港】
2019年埼玉西武専用ドラフト談義スレ 7位指名
結局岡山の奇跡は桜井日奈子と渋野日向子どっちなの
ツたんカーメンの秘宝　第2集「ファラオの愛と死」★1
別館★羽生結弦＆オタオチスレ12938
TOP カテ一覧スレ一覧 100～終まで 2ch元削除依頼