Webでオブジェクト指向プログラミング
サーバーサイドWebプログラミングのOOスレです。
・OOP、MVC、デザパタなどのコンセプト的な話題
・OOにまつわる言語比較（言語批判はその言語で開発してる人に失礼にあたることが多いのでなるべく禁止でお願いします）
・保守、再利用、生産性、開発環境などの実践的な話題
・Webサーバ、DBなどの外部との親和性に関する問題
・学習、教育などの方法論
などなど。
前スレ
PHPでオブジェクト指向プログラミング
http://pc8.2ch.net/test/read.cgi/php/1113724557/
>>174
いや、そんな自己満コード晒してもらっても >>189
ぱっと思いつくのは
憂鬱なプログラマのためのオブジェクト指向開発講座―C++による実践的ソフトウェア構築入門とか
>>188
OO分かってない奴にいきなりコードを見せても
ﾁﾝﾌﾟﾝｶﾝﾌﾟﾝだと思う >>128
JavaやC++のように大規模開発でも使う場面が
多い言語ではprivateは重宝するよ。
なにせprivateをうまく使うとデバッグがしやすいしバグもとりやすく
テストもしやすくソースコードの信頼性も上がる。
>>137
PHP使えるレンタル鯖が多いからだろ。
Ruby使える鯖は少ないし
Rubyというだけで日本人が作った言語だから
ショボイと思われがてで不キュしていなかったと思われる。 >>156
おれはよく継承を使いまくってる。
将来拡張する予定があるものは
かならず(空でもいいので)スーパークラスを作って
継承してつかっている。
継承は使い方を間違えたり勘違いしている人間が使うと
継承＝拡張そのものだと
誤解してだたやみくもに継承しまくることがあるので、
継承を使いこなしたければ
デザインパターンについてよく勉強した方が良い。
>>160
> ・関数がいい人は関数でやればいい
> ・クラスがいい人はクラスでやればいい
> ↑ここまではおｋ。それじゃ、
> ・クラスがいい人は何のためにクラス使ってるの？しかもPHPでｗ ←いまここ
大規模化する可能性のあるソフトをPHPで作るとき。
顧客がPHPを使えと言ってきたら
PHPを使わざるを得ない。けれどもオブジェクト指向を
使わないで開発すると一体どんなとんでもない目に
あうのか散々味わってきたので
漏れはかならずオブジェクト指向でPHPコードを書く。
継承 = inheritance
拡張 = extends
なんだよな・・・・ >>163
それに関してはPHPでもJavaでも同じように実現できている。
PHPで問題なのは名前空間と型安全性問題。
メソッド引数に型指定もクラスしか使えないこと。
integer型やstring型などをメソッド引数に指定できないのが
今のPHP5の難点。Javaでいえば引数の型をObjectにしているようなものだ。
Perlでも同様だが。
>>171
PHP5はどうみてもJavaのパクリとしか
思えないほど十分にオブジェクト指向できるような
言語となった。問題なのは上でも述べているとおり
名前空間と型指定の曖昧さ、ほかに戻り値の型を指定できないことだね。 >>199
PHP6もgoto付けるとか言ってないで
そのへん整備すりゃいいのにな >>174-175
そんなに汚くないコードだけど
ちょっと抵抗があるソースコードだな。
クラス名が全部小文字で
名前空間の替わりの役割を果たしているわけでもないのに
区切り文字に_(アンダースコア)つかうという
表記を未だに使っているとは・・・・。
やっまりキャメルケース(CamelCase)がわかりやすいと思うのだが。
それから一ファイルにつき一クラスにしておくのがベスト。
一つのファイルに複数のクラスを入れておくことはお勧めしない。
ファイル名とクラス名も一致させておく。名前空間が使えないので
そこだけ例外的にクラスだけ名に_(アンダースコア)を使う。
詳しくはPEARライブラリのソースコードを見てみてくれ。
それから文字コードがＥＵＣだとは。
Unicode(UTF-8)で統一してくれれば
DBとのやりとりも楽なのだが。 >>188
悪いがあなたが書いたソースコードが実用的な例だとは
とても思えない・・・・。
あのコードがPHPで有ろうとJavaに置き換えようと実用的になるとは
とても思えない。 >>190
オブ脳
オブジェクト脳のつくりかた
で良いんでないかな？ >>198
PHPやJavaではextendsで継承しているともいうし拡張するともいう。
しかしクラスそのものを拡張しているだけであって
それによってそれだけで簡単にソフトウェアの拡張性が高まるとは限らない。
という落とし穴に気をつけないといけない。
その辺りを素早く理解するにはデザインパターンを学ぶことをお勧めする。
この本は初心者には非常にわかりやすいので
かなりお勧め。
増補改訂版Java言語で学ぶデザインパターン入門
http://www.hyuki.com/dp/ >>201
gotoか。Javaみたいに例外処理限定や
ラベル付きbreak, continue文だけにgoto同様の機能を
限定的に持たせるだけにしてくれればいいのだが・・・・。
C#みたいにJavaのラベル付きbreakやcontinueをgotoキーワードで
実装すると言うだけのレベルだろうか？ 188はTemplateMethodの実例を見せたかったんだろ
俺は悪いコードだとは思わないが >>205
結城本はガチだな
ただOOPはじめたばかりの人がいきなり分かるほど
簡単だとも思わないが… 何でいまどきgotoなんだろ。
俺的には無限再帰を可能にしてwhileとforみたいなダサいもんも排除した
関数言語にして欲しいと前から思っているんだけどそんな人いませんか。 PHPで継承はあんまり必要ないな。
使い道がないから。
ウェブでオブジェクト指向するなら、JavaScriptが一番使いどころが多い。 >>193
そりゃあれば使うよ
ないものねだりしてもしゃーないでしょってこと finalとabstractとinterfaceが
とりあえずどんなものかは
わかったけど実際にどうやって
それを有効利用できればいいか
わからない香具師に結城本はおすすめだと思う。 >>211
> ウェブでオブジェクト指向するなら、JavaScriptが一番使いどころが多い。
まてまてw それはJavaの間違いではw >>212
privateの利点が解らない香具師はあっても使わない。 デフォルトがprivateだったらすげー便利だったのになぁ。 Javaだったらデフォルトでpackage privateになるのにな。
publicと明示的につけないとパッケージ外部からアクセスできなくなる
ってことが名前空間がないPHPではできないから
デザインパターンの実装も中途半端になる。
>>215
そんなやつの話を持ち出されても知らない
ダメコーダに強制できないとかいう話ならご愁傷さま
としか言いようがないですな
>>213
俺も最初そのへん「これ必要か？」と思ったな
他の人（近未来の自分含む）に対しての「使われ方の説明」を
ソースの中に機能的として組み込むものだとわかって
得心した。 PHP6のgotoは、gotoというキーワードが実装される訳ではなくて、
for () {
if () {
break foo;
}
print "bar\n";
foo:
print "baz\n";
}
こんな感じに書けるようになるもの。
>>199,200
型安全性ならis_arrayとかis_stringとかinstanceofでチェックすればいいだけじゃないの？ それはそうだが
何が求められているのかを知るために
中身まで見ないといけないのはあまりよろしくないだろう。 動的型付け言語であるPHPで、型を指定したいってのがそもそも可笑しな話なんだよな。
それでもタイプヒンティングみたいにオブジェクトの型を動的にチェックしてくれるようにする構文はいいアイデアだと思った。
Javaでいう変数の静的な型指定（つーかC/C++からだけど）と構文を似せたってのも良い。
JavaScript2.0なんかもそういう方向に行ってるね。
>>199
> integer型やstring型などをメソッド引数に指定できないのが
たぶんだけど、統一性の問題があるからだと思う。
例えば引数にintを指定したメソッドがあったとして、呼び出すときにstringを渡したからってエラーにすべきではないでしょ。
その辺の仕様がうまくいかないんじゃないかな。 >>220
普通にJavaのパクリじゃないか。
Java自体もCあたりからパクッタ者だが >>222
以前もどこかのスレで議論があったが。
それだけでは以下の問題を解決できない。
$number = 9;
$value = 1;
$x = $number + value *2;
$y = $x * $x + 4 * $number;
$number = 1000;
$z = $x / ($y + $number);
とした適当なコードがあったとき、
あとから
$x = $number + value *2;
の部分を
$x = $nunber + value *2;
と書きかえても $numberと$nunberとの違いの
に気づかない。
そして路頭に迷ったあげくにデバッグに無駄に時間をかけることになって
開発速度が衰える。 >>225
Javaみたいにラッパークラスを作ってしまえばいいかもしれんな。
final class Integer extends Number {
$private $value;
__construct($value){
if($valueがint型であれば){
$this->value = $value;
} else {
throw new NumberFormatException("整数以外入力するんじゃねえぞこのバカ野郎氏ね！");
}
}
} privateに＄が余分についていた。
あとは適度に必要な変換メソッドを追加しておくべし。
intValue()とか >>228
お、いい方法じゃん！って一瞬思ったけど、
function method(Integer $param)
を呼び出すときmethod(10)って書けないし＞＜
>>227
えーっと、それは型安全性の問題なの・・・？ >>227
コンポーネントに対する入力値と戻り値をちゃんとチェックするような
ユニットテストを書いとけばいいんじゃないの？
>>230
ひとこと「それだとAUTO-BOXINGが欲しくなるな」と言えばいいのにｗ >>233
つ 「それだとAUTO-BOXINGが欲しくなるな」
満足戴けたかな？
PHPみたいな型なし言語なら、Javaみたいなプリミティブ型とそのラッパークラスのオートボクシング/アンボクシングだけでなく、もう少し汎用的な自動型変換が欲しいところだな。
function method(int $x) {}
を
method("100");
っていうふうに呼び出したならintにキャストするくらいの自動化はあってもいいと思う。
（今あるPHPのタイプヒンティングだと、型が違うとエラーっていう設計だから）
もともとPHPは変数の実行時における型が文字列か整数かを意識しなくても適宜変換してくれるように設計された言語なわけだし。 >>234
type hintingのメリットが台無しじゃね？
>>234
それなら、
function method($x)
{
$x = (int) $x;
}
でいいんじゃないの？
>>232
型宣言しておけばミスに即座に気が付く、
のだけれどあれだと気づかない。 >>235
メリットって？
>>236
間違えて配列やオブジェクトを渡したときに自動的にエラーを出してくれるかもしれない。
もちろんis_intで確認してエラー出せば同じことだから絶対なければならないっていう必然性はないけど、あったら便利かとは思う。
あとタイプヒンティングでintやstringなどの基本型だけは指定できないっていう今の状況より統一感あるかと。
オートボクシングや構文糖と考え方は一緒ね。 PHPでそんなことするくらいなら、素直にJava使うわ。 普通のclassと、
abstractなclass,
interfaceは、
クラス名から変えた方がいいんかな？
どうやってる？ >>241
俺はabstractもinterfaceも普通の名前にしてる。
abstractやinterfaceをある特定クラスの仕様だけ抽象したことを表現したい場合に限り「Abstract〜」とか「〜Interface」にするかも。
例外だったら「〜Exception」てつけるけど。 >>241-242
というか、C#やC++みたいに継承も実装もおなじ::をつかっているわけではなく
PHPはjavaのようにちゃんと継承はextends、インターフェース実装はimplements
を使うように指定されているから
名前を見ただけでインターフェースかクラスかわかるようにまでしなくてもええと思う。
IDE使えば名前指定しなくてもさらに一目でわかるし。PHPのIDEはよくわかんないけど
>>242-243
レスさんくす
あんまり考えすぎなくてもいっか 質問です。
ビジネスロジックとドメインロジックとアプリケーションロジックは、プレゼンテーションロジックと対比的な位置づけですが、基本的に同じものですか？ >>245
使用する分析・設計手法によって、使われる用語とその定義は違ってきます。
こういうインフォーマルな場では、それぞれが別の立場・定義で勝手に用語を使う
ことが多く、基本的な認識がすれ違ったまま不毛なレスが飛び交うのが常です。
まずは専門書で系統立った知識を得てから、自分なりの経験と知見を積んでいけば
その類のどーでもいい疑問は解決すると思われます。
プロパティをtrue/falseにするメソッド名ってそれぞれどんな命名にする？ >>247
setTrue、setFalse
setOn、setOff >>247
どんなクラスのプロパティを作るかがわかれば
自ずとそれに見合った名前がわかると思うんだが。
どうしても名前がわからないときは>>248のようになるが。
そのプロパティがオセロの駒であれば、
setWhite(), setBlack() みたいな名前にするだろうし。
もしくはset(Color.WHITE). set(Color.BLACK)など。
表、裏を表すなら setHeads(), setTails()など
0か1なら setZero(), setOne()または>>248のように。
あと、メソッドを複数にする必要も、メソッドに引数を
割り当てる必要もないケースであるケースもありうる。
trueだったらfalse, falseだったtrueに反転するだけのメソッド
public void reverse(){
this.flagment = !this.flagment;
}
を定義するだけのものとか。 スレを読まずに書くけど。
俺オブジェクト指向ってよくわかんないのね。で、
PHPでさ、テーブルごとにクラス作ってその中で
SQL発行してるソース見て思ったんだけど。こういう
のってテーブルのJOINはどう扱ってんの？ だからそれはテーブルじゃなくてデータオブジェクトです >>247
enableXXX/disableXXX
>>251
railsのactiverecordとか調べてみればいい
テーブル同士の関係の属性を設定して取れるようになっている
でもSQLを元にデータを取得することもできるし
複雑なJOINの場合はSQL書くのが推奨 OOPを0から学ぶとすると、やはりJavaが最適なのでしょうか？
Railsで有名になったRubyでもよさそうですが、
どれを勉強しようか悩みます。
どちらも実行環境を整えるのが自分にとって一苦労な気がするので、
今まで環境が作りやすいPHPに逃げていましたが、
一向にOOPの概念がわからずじまいで、
本格的にJavaかRubyを入れてやってみようと考えています。 >>255
つ ttp://smalltalk.cincom.jp/scripts/smalltalk.dll/tutorials/index.ssp オブジェクト指向プログラミングの学習が目的なら、ウェブアプリやっても無駄だと思うよ。GUIのあるデスクトップアプリ作った方がいい。 > オブジェクト指向プログラミングの学習が目的なら、ウェブアプリやっても無駄だと思うよ。GUIのあるデスクトップアプリ作った方がいい。
はいはいわろすわろす。 GUIのプログラミングで身に付くのはオブジェクト指向よりむしろイベントドリブンだよね。 >>258
ある意味>>257は言い得てると思うぞ。
WebアプリはWebならではの都合で、本来のオブジェクト指向には反する設計を
強制される場面も少なくない。
webアプリでがちがちのオブジェクト指向やると重くならね？ リクエストがあったらhtml吐き出して終わり、なタイプのwebアプリでは
オブジェクト指向はあまり身につかない。
なにしろ、インスタンスの寿命が短かくて、全員が突然死するわけだから、
時間軸がそっくり抜けてるのだよ。
気にしながらライブラリを作れば、ソースの構造的な部分はある程度身につくかな、くらいだろう。
JavaでWebアプリしかやらない人は、J2EEパターンとかDIコンテナとか使って
「オブジェクト指向」と思っているんじゃないかな？
今のJavaのWebはレイヤー構造や
ドメインモデル（エンティティ）とビジネスロジックを完全に分離した設計、
ステートレス・スレッドセーフ・request/sessionスコープなどが優先されて、
本来のオブジェクト指向信者から見ると、論理的にあまりきれいな設計ではない。
とは言える。
言語レベルを超えた「モデリング」（UML等は使っても良いが）を
そのまま実装にまで落とすには無理がある。 要するに Java なんかつかうやつはばかですってこと？ JavaでWebなんて業務外では使わないしどうでもいい。 >>266
OOPを極めたいという目的だけのために
JavaでWEBをやるならバカと言えよう。
本気でオブジェクト指向やりたいならウェブでは役者不足ってこと。 OOの概念を把握したりOOの組み方を学ぶだけなら
PHPでもそれなりに勉強できると思うけどな
PHP5で書かれたフレームワークやライブラリのコードを眺めてみたら それOOをまったく理解できなかった俺が買ってみた
どうなるか人柱になるわｗ
著者でググったらブログが一番上にヒットした PHPのデザパタ入門ってどうなんだろうか。
レビュー期待ｗｗｗ >>272
その言葉を信じて眺めてるんだが、
なんかごちゃごちゃしてて返ってわかりづらい･･･
コメント英語で何書いてるかわからないし。
やっぱ俺みたいな凡人は丁寧に解説してるサイトに限るな。 一口にオブジェクト指向って言ってもメッセージ主体かクラス主体かで変わってくるからね。
C++, Java, PHP は後者。前者は Smalltalk, Objective-C, io とか。 >>276
簡単なライブラリから眺めていけばいいよPEARのDBとか
OOPを一番手っ取り早く理解する方法は
OOで適当な分野のライブラリを自分でコード書いてみる事
当然よく分からないうちはコードは汚い
なのでPEARで同じような分野のライブラリコードを眺めて
どういう構造なのかを調べてみながら自分のコードを書き直す
それの繰り返しで把握していくもんだと思う
いきなりデザパタの勉強とかやってもあんまり意味がない
OOPを理解していく上でどういう局面で
どういうパターンを使ったら良いという事がわからないから
パターンってのは結局ノウハウの事だし
ノウハウってのは必要に応じて生まれて出来上がっていくもんだから
ノウハウ自体を先に説明されてもピンとこないはず
英語は勉強するしかないがまめに単語の意味を引くようにしておけば
文法を正確に理解してなくてもだいたい把握できるようになるはず
ネットならすぐに調べられるんだからそのコストは無駄にはならない
コードは万国共通だ
ごちゃごちゃしてても所詮はPHPのコード、Cやアセンブリじゃない
ゆっくり読んでいけばわかる
小さなライブラリでもよくできてるライブラリはたくさんある
その区別がつくようになっていけば
自ずといいコードも書けるようになるだろう オブジェクト指向について語るとき、
「どのような概念か」と「どう使うのか」
を分けないで話すとひどいことになる、
ということだな。 >>278
PEARってOOPで書かれてるの？
クラスからインスタンスをnewして使うってのが多いですね。
>>279
って>>273の本の説明の仕方がごっちゃでよくないってことなんですか？ 昨日本を読んでみた。
サンプルコードが載っていて分かりやすかった。
UMLの説明はさすがに他書で勉強しないと、このページ数じゃフォローできんね。
（ないよりましだけど…）
デザインパターンが活用できるようになれば、OOPが楽しくなるだろうなー☆＼(^o^)／ 届いたよ！
眠くてまだ読んでない
ちょっと開いたけど このスレ、
サーバサイドプログラミングでのＯＯかよ
期待して損した・・・ >>283
クライアントサイドのOOPっていうと、JavaScriptでやるんですか？ WebObjectsがフリーになるから 勉強しといたほうがいいぜ 半分くらい読んだけど、7章が無いのが残念だった
そこらへんは著者さんのブログやサイトを参考に補完することにしようorz >>273
それ買って読んでみてる。
今5章の途中だけど
いまいちピンと来ない。
おれがアホだからだと思う。 PHP5のﾏﾆｭｱﾙ（オブジェクトとクラスの項）とJava入門書を読み始めたばかりなんだけど、
PHP5とJavaのメソッドオーバーロードって全然別物なの？ 
