http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1430714984
この人の言ってることがわかれば参考になると思うよ
わからないからそんな質問してるんだろうけどね
オブジェクト指向の勉強なんてのはPHPでやるもんじゃないので
一回Javaコース入ったほうがいいと思う

>>250

オーバーロードがポリマーフィズム実現手段かは
SmallTalkのときから長らく議論されてる問題

僕はポリマーフィズム実現手段派

ポリマーフィズム → ポリモーフィズム
SmallTalk → Smalltalk

ポリマーってエチレン思い出すからやめてくれ

俺は破裏拳

ご回答ありがとうございます。とても参考になりました。

>>243
多態性（ポリモーフィズム）のメリットを理解できました。
メソッド名の統一により楽できることが利点の一つなのですね。

>>246
抽象クラスで、メソッドの実装と名称を強制するのと同義と考えて大丈夫ですよね。

>>247
同一のメソッド名にすれば、その効果が、結局、ポリモーフィズムであるということですよね。

>>251
そのページの説明を読みましたが、解答がポリモーフィズムからずれて、オブジェクト指向全般の概要になっている気がします。
ただ、次の部分は、ポリモーフィズムの説明だと思いました。
もっとも、PHPのオーバーロードは、Javaとは別物のようです。

『他にも "オーバーロード" といった便利な機能があります。
引数の種類を変えれば、同名のメソッドを定義できるというものです。
いい例えが思いつきませんが、攻撃する際に "こうげき" のみでダメージ判定されるものと
"こうげき" と "まりょく" でダメージ判定される攻撃の二つがある場合、必要な引数が前者で１つ、後者で２つなのでどちらも記述できるといったカンジです。』

ありがとうございました。

>>241
外部からのデータを扱う場合、prepareメソッドを使う（無害化する機能有り）
外部からのデータを扱わない場合、queryメソッドを使う（無害化する機能無し）

分からなければ常にprepare使えばOK

order by ascかdescかを選択するときなんかの時はprepare使いづらいよね

>>259
え？

入力値でどっちにするか決まるけどbindできないじゃん
条件文使わないといけなくなるから使いづらい

>>261
それ何でやっても同じだろ

プリペアードステートメント使うことと
条件によってクエリが変わることは全く別物だぞ

はい

じゃやっぱクエリ2つ用意するのね

何のためにプリペアードステートメント使うか理解してから使おう、な

気持ちは分かる。
パラメータを無害化することしか知らない人には分からないだろうけど。

済みません、スレチでしたら誘導お願いできませんか？

>>267
そもそもなんでPHPスレだと思ったの？

>>234
それはそのサイトの管理者問い合わせしたほうがいいんじゃね？
連絡がつくなら修正してくれるんじゃね？

>>266
プリペアドステートメントの他の使い方って？

>>270
プリペアすることだろ

PHPがレベル低いって思われる最たるものが大手のFWでprepare使わずに、自前やquoteメソッドで対応してる例があることだ

そういうのをPHPガーって言うのが恥ずかしくない頭なんだろうな。

>>273
これに関しては仕方ないんじゃないか
FuelPHPとかあそこらへんも終わってたような

個別のソフトの問題や、使ってる人の問題を、言語自体の問題にすり替えて仕方ないと言ってるから、
あおりのレベルが低いんだよな。

使えないFWが多いのはちょっと問題だとは思うけどなー
使ってる人の問題だけど、そういうFWを推してる人はどうにかならんかな

下見て暮らしてる奴だからしょうがない

>>277は>>275に対してね

FWなら結局、CakePHPがいいよね。

よくない

CakePHPは日本と日本のオフショア先だけまだまだ盛んだな

>>283
ダメではないか

私JKで試したわけぢゃないけどーprepare+bindXxxって
query+quoteに比べて処理工数が多いだけに遅そうだしー
ただでさえ遅いFWの速度をあげるには仕方ないのでゎ

>>285
そんなんボトルネックにならん

ちっちゃいのが積み重なると大きくなるけどね

>>284
一昔前の文字コードやエスケープ処理での脆弱性を知らないんだろうし

シングルバイト系の人は知らない人多いし

>>284 >> 288
だめなの？
fuelphpてSQLインジェクション防げないんだ…
これはオワコンだわ

>>289
基本的には防げてるし、新たに発見された脆弱性も継続して修正されてる。
http://fuelphp.com/security-advisories

「プリペアードステートメントを使ってないからSQLインジェクションの脆弱性がある」というのはFUD。
とはいえ、プリペアードステートメント使えやとは思うけどね。

SQLインジェクションは、Prepare使わないと防げないわけではない。
そもそもでいえば、インジェクション防止の機構じゃねーし。
SQLの機構じゃなくて、ライブラリのラッパなので、仕様によっては
使っていても問題ないというわけではない。

>>285
クエリを実行するとき、データベースサーバでは、
1. 構文解析
2. 実行計画立案
3. クエリ実行
の処理が必要で、prepareでは1または1&2が行われる。（構文のみで実行計画を立てて固定する場合と、3で渡された
パラメータをもとに実行計画を立てる場合がある）
一方、exec queryでは毎回1～3が行われる。
なので、同じ処理をパラメータを変えながら複数回実行する場合、プリペアードステートメントを使った方が速い場合がある。

レスありがとうございます
>>268
PHPが何なのか解らず、単にネットプログラムの質問スレで質問させて頂きました

>>269
大手企業サイトなので厳しいですね

ど素人ながら、ログインボタンのURLとかPCでログイン後のURLとか試したんですが、無理でした

>>293
> 大手企業サイトなので厳しいですね
大手こそ対応してくれそうなもんだが。
「○○のサイトって、ガラケーのフルブラウザだとログインもできない糞サイトだわ」
とかネットで言われると困るだろうし。

>>289
そこそこ有名なPHPのフレームワークにそんな基本的な脆弱性があるなら、大垣氏あたりが騒いでるよ。

>>295
もちろん知ってる。>>284と>>288を皮肉ったんだよ、

>>288の話ってPHPの脆弱性の話じゃないだろ、常識だろ？

http://gihyo.jp/dev/serial/01/php-security/0042

>>295
quoteだけでは防げない問題を見つけてつぶしていってくれてるんだよ。

http://www.tokumaru.org/d/20100701.html

昔のMySQLみたいなprepareがクライアントサイドで処理とかゴミな実装されてると
prepareのほうが脆弱性の巣窟になりかねない。

この場合、徳丸氏や大垣氏が騒ぐから問題はいつか解決される