アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
Perlの (スコア:0, 興味深い)
Perl4からPerl5にバージョンがあがったときも、
オブジェクト指向的な要素を取り入れましたが、
ほとんど使われてないんじゃないのかな。
だいたい、PerlにしろPHPにしろオブジェクト指向が
やりたくて選択したわけじゃなくて
Re:Perlの (スコア:2, 参考になる)
少し規模のあるアプリケーションを書こうと思ったりコードを再利用しようと思うと PHP でも OOP にした方が楽だと私は感じています。
コードを追いかける時も労力が違います。
全てのシーンで OO 万歳とは言わないけどオブジェクト指向でなければ耐えれないシーンが増えてきているのも確かでは。
# でないと誰も使わないかと。
Ruby などに比べると月とすっぽんですが一度慣れてしまえば迷路としか思えない function と include には
中途半端さがイイ! (スコア:1)
引数とか、シンプルで、わかりやすくかけますし。
パクリもしやすいと。
Rubyなんかと違って、
「すべてがオブジェクトで無い」
というところに、可能性を感じております。
書くは天国、読むは… (スコア:1)
OOP好きな俺が言うのもなんですが、
(自分で何をどうしたいか判ってる状態で)書くのは確実に楽になりますが、
読むのはどうかな?と思うことが有ります。
よく言われることですが、処理の流れが見えにくくなりますね。
まあCでも関数が多くなるとそれと近い状況になりそうですが、
OOPだとそれに加えて、多態が(デフォルトで)出来るので、
今どこを通っているのかを追うには、そもそもクラス構成を理解してないと
(ちなみに、ある変数にどの場面でどのクラスのオブジェクトが入ってるかの問題なので、
静的なクラス図だけじゃ情報不足です。動的なほうも判ってないとね)
先に進めない、ってことが…
その見えにくさを押し進める(笑)ものが、
テンプレートメソッドパターン(穴埋め問題を解くのは未来に任せる)であり、
ストラテジーパターン(具体的にどう処理するかは未来に任せる)であり、
チェインオブレスポンシビリティーパターン(どこまで行ったら解決してくれるのかは実行時に任せる)であり…(^^;
ま、OOP以前だと逆に「使って天国、作って地獄」と言われてたわけですから、これでオアイコかなという気もしますが(^^;
あと、説明になる情報(javadocにせよ「ソース自体が(読めるような)ドキュメント(になってる)」にせよ)があれば
結局なんとかなる、とも言えないわけではないんで、アレですが。