クラスとか全然理解できない
ユーザ定義関数じゃだめなん？？
どういったときにクラスで書くとか
感覚が掴めない
こういうときに必要なんだぜって
やさしく教えてつかあさい；；

クラスなんて使わない。
関数も自分でつくらない。必要があれば使えばいいし使わないでもいいなら使わないでもいい。
無理に使う意味なんてないでしょ。

クラスってのはオブジェクト指向設計を実装するために使うものだぞ？

>>552
そう割り切っちゃえば話は簡単なんだが、理解が出来ないってのがつらい；；

>>553
だから、そいつをやさしく教えてくれ；；
そのオブジェクト指向ってのがよくわからんのだ＞＜

>>552
たぶんこいつはスパゲッティコード

ウェブプログラムの規模だとクラス使って書いても便利だと実感できないだろ

557 名前：nobodyさん[sage] 投稿日：2009/04/18(土) 14:14:54 ID:???
ウェブプログラムの規模だとクラス使って書いても便利だと実感できないだろ

557 名前：nobodyさん[sage] 投稿日：2009/04/18(土) 14:14:54 ID:???
ウェブプログラムの規模だとクラス使って書いても便利だと実感できないだろ

557 名前：nobodyさん[sage] 投稿日：2009/04/18(土) 14:14:54 ID:???
ウェブプログラムの規模だとクラス使って書いても便利だと実感できないだろ

557 名前：nobodyさん[sage] 投稿日：2009/04/18(土) 14:14:54 ID:???
ウェブプログラムの規模だとクラス使って書いても便利だと実感できないだろ

557 名前：nobodyさん[sage] 投稿日：2009/04/18(土) 14:14:54 ID:???
ウェブプログラムの規模だとクラス使って書いても便利だと実感できないだろ

>551
・自分の書いたコードを晒して、ヒマな人に添削してもらう
・腕のいい奴の書いたコードを読む
前者のほうが力になりやすいかね。
屑コードを、クラスを使った近代的なコードに書き直していく過程を見るのが一番わかり易い。
そこらで公開されているPHPのコードはゴミと芸術品の両極端が多いから、初級→中級の勉強には微妙。

そこのステップは知識云々じゃなく、考え方の転換を迫られるから、引っかかる奴が多いのは事実。
>557みたいに諦めちゃう人も多いけど、身に着ければ強力で便利なツール。

>>549
受信に使っているプロトコルの仕様にならって実装する



OOPについて勉強したい的な話題はこちらでどうぞ
http://pc11.2ch.net/test/read.cgi/php/1172205352/

>>551
まぁ、なんかWebアプリとかを作成していく中で、
誰かが作成したライブラリだとかPEARだとかを使うことになったとして
そのライブラリがただのユーザ定義関数だけで書かれていて、設定用に
大量のグローバル変数を有していたら、困ったことにならない？

それだけでも、機能の集合がクラスになっているということに意味はあると思うけど。

>>555
どの辺まで理解できて無いかによってはスレ全部埋めることになるが・・・ム板行ったら？

とりあえず全部自分ひとりで趣味レベルのモノ組むのであればオブジェクト指向にこだわる理由は無い。
どーしても理解したいって言うなら、近道は無いとだけ言っておく。

10桁こえとる

DATETIMEのままでいいだろ

(long)

そんなに速さ追求するならなぜＰＨＰ使ってるの？　ってつっこまれるぞ

staticしか使わないなら関数と大して変わらないじゃん

>>547
cakeはOOP必須ですよ

>>570
漢は手続き。

ちょっと言ってみたかっただけだけど。

OOPはわかってもMVCの概念を理解するのはむずかしい
それを分離して補ってくれるのがフレームワーク
OOPOOP言うのは面倒だからまとめてJavaのサイトで勉強してきなさい

PHPを書くのに使うIDEってーと、何がお勧めですか？
コードス補完があると便利なんですが

>>568
普及率が高いから。jspやaspは搭載してないレンタルホストがほとんどだしね。

>>569
カプセル化だけほしいんだよね。変数の扱いが楽だから。漢は手続きと言ってみたいけど、へっぽこなので変数汚染しまくり。

>>573
>>1

>>573
初心者のうちはＰＨＰエディタ。
中級以上はＰＤＴ

フレームワークの提供するMVC構造は型志向プログラミングの考え方からはそれなりに遠い地点にあるプログラミング構造だぞ。
例えばCakeやRailsなどのフレームワークはTableModuleパターンを押し付けてくるが、ストラウストラップのOOPの考え方に一番近いのはドメイン駆動型の設計。
で、フレームワーク上でドメイン駆動設計を実現しようとすると、クラス階層を1枚上に丸ごと被せざるを得ない、というくらい両者は相性が悪い。
（基盤となるM-V-C間の繋ぎこみ自体はポリモーフィックに行なわれている事が多いので、無関係でもないが）

まあ、その「押し付け」のおかげでscaffoldingなどの高い開発効率を確保できるわけで、悪いとは言わないけどな。
少なくとも、MVC構造を理解する事と、OOPの考え方を理解する事は、別の問題と考えるべき。
実際、GoFをひとつも理解してなくともRailsやCakeで生産性は出るし、OOPを突きつめると必然的にRailsやCakeの設計に行き着く、というわけでもない。

>>573
E-TextEditor　　ttp://www.e-texteditor.com/
EmEditor v9　　ttp://jp.emeditor.com/
TextMate　　ttp://macromates.com/
Redcar　　ttp://redcareditor.com/
jEdit　　ttp://www.jedit.org/

>>564
>>565
>>566
返事が遅くなりすいません。
単純にint型の最大値を超えてた訳ですね。
本当にありがとうございました！

>>580
http://jp.php.net/manual/ja/function.unset.php

配列の添字も詰めたい場合は、これに
http://jp.php.net/manual/ja/function.array-values.php

>>581
解決しました
ありがとうございます

>>577
日本語わかる？

プログラムは、「データ」と、データを扱う「処理」の２つの構成要素から成る。（チューリングマシン）
オブジェクトは、データに処理がくっついたもの。
言ってしまえばそれだけのことでしかない。
OOPを難しく考える必要はないよ。

OOPを勉強するためにJavaを勉強するのも良いけど、
ラムダ計算、関数型プログラミングに慣れておくために、LISPも勉強しておくと良いと思います。

>>584
オブジェクト指向設計が重要なんだろ
単なるギミックじゃないぞ

>>584　の言い方はどうかと思うが、OOPで出来ることを、単なるギミックとして使うのもアリだとは思う。
いわゆる Stateパターンとか OOD的にはかなりビミョーと言う認識。

>>588
unset($_SESSION['hoge'])すればいいんじゃ？

>>589
返信ありがとうございます！
入力画面、確認画面、投稿画面以外の全てのページに
unset($_SESSION['hoge'])を設定しとこうかなとも考えましたが、
もしかしたら違うスマートやり方もあるのかなと思い質問してみました。

hiddenでいいやん。

>>577

そうだよな。CakePHPの例で言っても、所謂OOP的な書き方って、Model, Controllerのextendsくらいだもんな。
基本、コンストラクタは省略されてるし、セッター、ゲッターなしにいきなりプロパティ変数に設定値を代入でOKとか。

あと、命名規則とか記述に縛りが多いのも独特。

>>591
返信ありがとうございます。
hiddenも検討したんですが今回は項目が多く
入力←確認、確認→投稿時に全ての値をセットしないと
いけなくなりますので出来ればセッションでいけたらと思います。
変な質問すいません・・

そのページにどこから来たかでわければ？

初々しいな

1. 入力フィールドが多数ある時は、そいつらを扱うクラスや関数を作っておくと楽。
複数の画面から同じフォームを生成する場合などは、使い回しが効くと非常にラクになる。

2. hiddenは別に面倒じゃない。確認画面は
foreach($_POST as $k => $v) echo "<input type=\"hidden\" name=\"$k\" value=\"$v\">";
でじゅうぶんだろ？（XSSを考え、実際はエスケープする事）。

>>547
まずCAKE使うだけならOOPの勉強しなくても、まぁ使える。
さらにCAKE使ってるとOOPに触れざる得ないから多少慣れるのもいい事かも。

で、クラスの書き方と使い方ぐらい入門系の情報でやっておくとある程度身に付いてくるよ。

>>593
まぁ好きにすれば良いんだけど、自分だったらそのセッションの内容をXMLに変換して、
これをhidden に持たせて、サーバ側ではsimplexml_load_stringでパースする。

どのみちCSRF防ぐためにワンタイムトークンとかHMAC仕込むときhidden使うしね
あんま意味ないけどhiddenはbase64_encode(serialize())とかすれば一個ですむよ

とこでいくつかのWebアプリでは、プレビューには投稿画面に入力データのリストを追加しただけのものを表示するね
確認画面というフェーズを新たに作るより省力化になっていいと思う。確認画面から投稿画面にもどって、、、という作業もいらないし

> あんま意味ないけどhiddenはbase64_encode(serialize())とかすれば一個ですむよ
ここだけケチをつけて済まないが
クライアントに渡すデータは他のフォーマットにしとけ
unserialize()時にコードインジェクションが起きる