08/07/03 22:43:15
>>808
意味がわからない。kwsk plz
810:nobodyさん
08/07/03 22:55:35
>>808
agaviはContextクラスがAgaviModelの派生クラスのファクトリーになってて、
IAgaviSingleModelインターフェイスを実装している場合はSingletonになるようにしてる。
811:nobodyさん
08/07/03 22:57:16
>>808
想定しているのはこういうのじゃなくて？
＃ これなら継承しても特に問題なさそうなんだけど・・・
class A
{
protected static $obj;
public static function singleton()
{
if(!isset(self::$obj)){
self::$obj = new stdClass();
}
return self::$obj;
}
}
class B extends A{}
var_dump(B::singleton());
812:nobodyさん
08/07/03 23:14:16
ああ。なんとなくここまで流れで見えてきたポイントがある。
>>811 での Bクラスの singleton() では、例えば Aクラスを継承した
Cクラス・Dクラス・・・でも、「同じ」インスタンスが返ってくるなｗ
class B extends A{}
+ class C extends A{}
var_dump(B::singleton());
+ var_dump(C:::singleton());
んで、ぐーーーーっと戻るが、>>788 での記述でAクラスが書かれて
いたとすると、結果が変わる。
BクラスとCクラスでは、戻ってくるインスタンスが違う。
結局、こういうことなのかな？
詳しい人、解説頼む
813:nobodyさん
08/07/03 23:30:04
時代はSingletonなのか？
>>809
オブジェクトを管理しやすいんじゃないか？
814:nobodyさん
08/07/05 12:22:18
シングルトンは初期化のタイミング気にしなくて良いのも大きいやん
815:nobodyさん
08/07/05 15:04:11
>>813
シングルトンは昔からあるデザインパターンの一つだよ。
816:nobodyさん
08/07/05 21:17:29
DIコンテナがあればシングルトンパターンなんて使わねーから。
そんなことより、JavaもPerlもRubyもMVCフレームワークって
ほぼ１択なのにPHPは乱立してんの？
決定版が出てこない時点で終わってるな。
817:nobodyさん
08/07/05 21:51:53
>>816
ある意味、PHPの敷居の低さかな。もともとWEBフレームワークみたいなものだから、
基本機能（CookieだとかHTTP周りとか、出力とかサーバへのデプロイとかもろもろ）を
スキップしていきなり構築出来るし、書いてみれば結構できちゃった、みたいな感じじゃね？
818:nobodyさん
08/07/06 03:59:03
>>816
DIコンテナ何使ってる？
819:nobodyさん
08/07/07 15:48:06
・DIコンテナって何？その用途・利点は？
・DIコンテナとsingletonの関連は？
・DIコンテナを使ったPHPフレームワークってある？その得意とするケースは？
初心者が、ここでこれくらい聞いてもいい？
820:nobodyさん
08/07/07 16:02:09
だーめっ☆
821:nobodyさん
08/07/07 17:53:08
>>816
> ほぼ１択なのにPHPは乱立してんの？
PHPがオープンだからじゃないかな？
Javaも最近オープンになってきたから
フレームワーク増えてきているよね。
822:nobodyさん
08/07/07 18:39:37
>>819
ググれカス
823:nobodyさん
08/07/07 21:40:56
話についていけない！
Javaを勉強しないといけませんか？＾＾
824:nobodyさん
08/07/07 23:15:27
>>823
やさしいJAVA
825:nobodyさん
08/07/07 23:23:56
>>824
いやいやｗ それデザパタとかないしｗ
まずは、DIコンテナが有効なのかどうか、その辺の話が出来ないのか？
ググっても古い情報しかないのは、もう廃れたのか、常識的に使われている
からなのか、どうなんだ
基本的に、手法がXML等の外部設定ファイルだろ？PHPに馴染むとは思えん。
俺を含めて、本格的に使ったことの無い奴が多いんだろうとは思うが。
826:nobodyさん
08/07/08 15:28:51
PHPになじむかどうか以前に、
XMLなどの外部設定ファイルで設定するのって
大変だよ。
827:nobodyさん
08/07/08 17:39:01
>>816
Javaのフレームワークがほぼ一択だと思ってるなら、無知すぎ。
Rubyは開発者が少なすぎの過疎言語だったから。
Perlも廃れた言語だから。
Pythonも多い。
PHPも、乱立っても紹介が多いだけで、実際使われてるフレームワークは
限られてる
828:nobodyさん
08/07/08 19:27:16
>>826
特にXMLは大変だな。あの可読性の低さは尋常じゃない
専用エディタ使え？ああそうですね
829:nobodyさん
08/07/08 21:14:00
PHPって、まともなクラスライブラリがないから、それぞれ独自でフレームワークを実装し出すんだよ。
830:nobodyさん
08/07/08 21:14:32
DIコンテナ=XMLの設定ファイル使う、じゃないでしょ。
yamlの奴とかもあるよ
831:nobodyさん
08/07/08 21:16:09
>>829
zfってそこまとめようとしてるように感じたんだがな
その視点で言うと普及しなさそうで失敗ぽいけど
832:nobodyさん
08/07/08 21:21:43
ZendFrameworkに関しては、使える部分はあるんだけどね。
ともすればRouterやControllerあたりに目を奪われて、ライブラリ
部分の評価がおざなりになってしまったりする。
例えばCIに持ち込むとかすればいいし、双方ともそれが簡単に
出来るように作ってはあるんだけど、その時に何というか気持ち悪い
何故かと考えたが、クラス・変数・関数・ファイル名等の命名規則が、
分散しすぎているせいもあるなあというのが最近の実感。
異質な気持ち悪さがあるのは、きっと命名規則等も分散して
833:nobodyさん
08/07/08 21:22:18
>>832
最後の行はゴミｗ 消したい
834:nobodyさん
08/07/08 21:29:32
5.3の名前空間使えるようになったら少しはマシになるかな
835:nobodyさん
08/07/08 21:38:19
>>834
多分、それが普及するまでまた３年くらいかかるんじゃね？
名前空間全開で使ってると使用者が増えないという、何という二の舞ｗ
んで、5.2のサポート終了まで引っ張るとか。
836:nobodyさん
08/07/08 21:46:15
3と4と5で文法や仕様が大きく変わって、全部に対応するライブラリやフレームワークを構築するのが困難。
837:nobodyさん
08/07/08 21:48:24
3とかあり得ないし、4に対応するものを新しく書く必要もない、と思うけどね
4はそれこそ、今までの遺産でがんばれば良いじゃない
838:nobodyさん
08/07/08 22:09:17 PfgpRR5R
>>832
CodeIgniterにZendFrameworkのライブラリを引っ張ってくる＝いいとこ取りで、楽ができますか？
ＭＶＣならルーティングとか、コアになる部分は、どのフレームワーク使ってもに似たような処理になっているでしょうか？＾＾
839:nobodyさん
08/07/08 22:12:20
幕の内弁当のようにいろいろな具が詰まったフレームワークを、いったんバラバラの具に分解して
自由に組み合わせて食べられるとウマー？
時間があったら、フレームワークのコードを読んでみるか…。
840:nobodyさん
08/07/08 22:12:52
Perl5.0が1994年、Perl5.6でさえ2000年にリリースされてる。これが圧倒的なボリュームのCPANがあるPerlと、Pearが尻すぼみに終わり、Zendが始まりもしなかったPHPの違い。
841:nobodyさん
08/07/08 22:34:22
>>838
別にそんなに難しくないし、メリットはあるとおもう。例えばZend_Pdfとか持って来たり。
lib/Zend 以下をごっそりvendor/とかにコピーしてinclude_pathを通すのが一番楽だけど、
依存に注意しながら必要なものだけを持ってくるのでも、それほど難しくない。
例外が２系統投げられるので、その辺が気になるなら対処して。
CIの場合はそれほどコアに密着したライブラリって無いので、例えばSessionとかDbとか
も、好きなものを使おうと思えば使える。Registryとか、なんでCIにないのかなって思ったし。
＃ そうすると、CIの機能をいくらか無視することにもなるかもだけど、それで幸せになれるならおｋ
で、問題はそれをやると、ソースがカオスになると。メソッドの命名規則なんか、CIはZFの
対局にいると言っても過言ではないとおもうし。
＃ クラスにprefixつけない、CamelCase嫌い、クラスファイル名でもCamelCase式と
＃ lowercase-underscore式の、独自ルールによる混在、もろもろ・・・
そこに上乗せする俺のソースはどっちで書けばすっきりするんだああ、となるよ。
842:nobodyさん
08/07/09 00:45:59
DIの設定がXML地獄てSpring2.5とか使ったことないのか？
ここのアホ住人は。
今は、XMLにはほとんど記述せずにアノテーションでお手軽に記述できるんだよ。
843:nobodyさん
08/07/09 00:54:02
>>842
そうやって、どんどんJava風を進めて行くわけですね。＞アノテーション
出来れば、そのメリット・デメリットを絡めたレスが欲しいなぁ。
なんでJavaで一般的なものがPHPで一般的でないか、それを、
「遅れている」等としか捉えられないのなら、少しおかしいと思っていいよｗ
844:nobodyさん
08/07/09 01:06:31
>>843
842は設定ファイル云々に突っ込んでるだけでしょ
845:nobodyさん
08/07/09 01:12:38
>>844
それを言うなら、XML言い出した大本の>>825では自嘲している
> 俺を含めて、本格的に使ったことの無い奴が多いんだろうとは思うが。
むしろ、DI派の具体的な書き込みが無いから発展しないんだろうが。
846:nobodyさん
08/07/09 01:20:27
本当に、PHPでDIとかDaoとか、「これはいい！」と思って使ってる人っているの？
847:nobodyさん
08/07/09 02:45:49
そもそもPHPやRubyのような動的言語には、DIみたいな回りくどい書き方は不要。
静的言語の融通の効かなさを誤魔化すために生み出されたものだし。
848:nobodyさん
08/07/09 10:02:19
Tomcatの再起動とか面倒だったりするもんな。
849:nobodyさん
08/07/09 12:00:32 QmvziGkH
自分のプログラム技術が上手なことに気付いた
アルゴリズム能力は知識で補えない、もって生まれた能力
850:nobodyさん
08/07/09 20:19:04 My9jWWGd
>>849
オリジナルの式を組めるなら凄いな
851:nobodyさん
08/07/09 21:05:11
ゆがんだ車輪を再発明しまくってる悪寒
アルゴリズムってか、ロジックレベルで言ってるんでは無かろうかとも思う
ってか、何これ。コピペ？
852:nobodyさん
08/07/09 23:28:12
>>849
世界ＩＴコンテスト、慶大生が３位入賞
世界の学生がＩＴ（情報技術）の開発力を競う「イマジンカップ」（米マイクロソフト主催）の第6回世界大会が
8日までパリで開かれ、「アルゴリズム部門」で、慶応大の高橋直大さん（20）が3位に入賞した。
日本人の3位以内の入賞は初めて。アルゴリズムはコンピューターソフトの基礎となる計算手法で、
高橋さんのアルゴリズムの独創性などが評価された。
アルゴリズム部門のコンテストは数学パズルのような9問の課題を24時間の制限時間内に
コンピューターを駆使して解法を考案する。高橋さんは「好きな算数や数学の考え方をいかした。
2、3分しか寝なかった」と話した。
パリの大会には100カ国以上から124チームが参加した。予選を含めた総参加人数は20万人を超える。（パリ支局）(11:01)
URLﾘﾝｸ(www.nikkei.co.jp)
853:nobodyさん
08/07/10 03:46:42
何このきもい流れ
854:nobodyさん
08/07/10 03:57:12
>>853
「DIコンテナ」のこと？それとも
「自分のプログラム技術が上手なことに気付いた」の方？
はっきりしろやｗ卑怯者がｗｗｗ
855:nobodyさん
08/07/10 04:07:03
「自分のプログラム技術が上手なことに気付いた」の方に決まってんじゃん
なんで卑怯者？？？
856:nobodyさん
08/07/10 04:08:03
ネタが無いんだよｗ
857:nobodyさん
08/07/10 10:37:59 R+kirKl3
で、ここでPHPフレームワークの話をしよう！
ってなると、話がピタッと止まるから面白いｗ
858:nobodyさん
08/07/10 12:07:19
あぁ、Java厨が嵐に来ているだけだからね。
859:nobodyさん
08/07/10 12:11:37
PHPフレームワークの話題は規模が大きくなったので、
各フレームワーク専用スレに移行しております。
860:nobodyさん
08/07/11 18:54:57
どんなふうにしてクラスを作ればいいのか？
クラス作成の適切な方法を調べています。
分析（モデリング）→設計の流れにおいて、
・構造化プログラミングだとDFD
・オブジェクト指向プログラミングだとUML
ユースケースドリブン＝ユースケース図→ロバストネス分析→クラス図を作成する？
アーキテクチャセントリック＝アーキテクチャ（基盤）としてのフレームワークを選定→フレームワークの流儀に従って機能（クラス等）をどんどん追加していく？
…ということでしょうか？
本やサイトを調べると、Javaの事例がたくさん出てきました。
861:nobodyさん
08/07/11 19:04:44
なら死ぬ気でJavaやれよ。俺はJavaを書くと慢性的に薄い血尿が出てた頃を思い出すからコリゴリだけどな。
862:nobodyさん
08/07/11 19:28:36
javaのコードをphpに置き換えりゃいいじゃねえか・・・
863:nobodyさん
08/07/11 19:37:29
そうして行数や文字密度ばかりでかい、可読性最低のソースが量産されるのですね
864:nobodyさん
08/07/11 19:49:05
Javaは勉強しました。
＝簡単なアプレットを作れます。
オブジェクト指向分析→設計って、言語の仕様に依存しないで使えますよね？
クラス作成は、適当でも動くものは作れるけど、先人が体得してきた上手いやり方を知りたいです。
デザインパターンは、これから勉強してみます。
865:nobodyさん
08/07/11 19:53:01
構造化プログラミングの設計は、わかりやすいと思います。
文書を作成する場合も、フローチャート図やDFD図を書けば、人に説明できる。
データベース設計もER図で書ける。
オブジェクト指向設計はこれから勉強しますが、体当たりで試行錯誤するより、典型的な勉強方法を知りたいです。
866:nobodyさん
08/07/11 23:06:34
近道して楽しようと思わないことかな
867:nobodyさん
08/07/11 23:37:05 3Q95O5fB
オブジェクト指向設計は、まだ方法論が確立されていないのですか？
群雄割拠＞＜
868:nobodyさん
08/07/12 02:04:01
>>866
それは、自分で私は低脳プログラマですって言ってるようなものだぞ。
869:nobodyさん
08/07/12 09:41:14 jBMGyyJi
オブジェクトはな・・・Cの構造体を勉強してみると感じが分かるやもしれぬ。
が、そもそもCの勉強コスト自体が高いかね。
でも、勉強しておくと、後々効いてくる。
870:nobodyさん
08/07/12 09:52:14
オブジェクト指向を学習したいならPHPなんてしない方がいい
関連書籍のレベルも低いし
871:nobodyさん
08/07/12 11:05:18
オブジェクト指向なんて難しい事を考えずに、
関数の寄せ集めって考えれば、すごく楽なのに。
872:nobodyさん
08/07/12 11:12:05
関数の寄せ集めとは違うぞ。
より便利に関数・・・というか、プログラミングを、と考えていくとオブジェクト指向につながっては行くけどな。
873:nobodyさん
08/07/12 11:19:45
>>868
なんで？
874:nobodyさん
08/07/12 11:38:13
関数と変数の寄せ集めじゃない？
875:nobodyさん
08/07/12 11:39:05
>>873
楽したがる人の方が優秀っていうのは定説
876:nobodyさん
08/07/12 11:46:50
>>875
根拠を詳しく
877:nobodyさん
08/07/12 12:02:11
>>876
どうせ「ソースは自分」だろうからほっとけ。
オブジェクト指向はOOPだけ見てると、どうしても小手先的な話が多くなりがちだから
OODも勉強したほうが良いとは思う。ただ、これに関して自分が呼んだ範囲でよかったと
思える本は、Booch先生の「Booch法：オブジェクト指向分析と設計」ぐらい。
しかもこれはもう絶版で再版はされないだろうから、中々に難しい。
878:nobodyさん
08/07/12 12:26:50
>>876
少しはぐぐれ
879:nobodyさん
08/07/12 12:33:16
>>877
じゃあ、自分の言葉で、「OODも勉強したほうが良い」と思われることを一つでもよろしく
例えば設計手法としてドメインモデルに基づいた「名前」の抽出とか、そう言った具体的な
ものは、"OOではなく"普通に有効なものだと思う。
何がOOのエッセンスか、その辺がよくわからない。
例えば新しい手法が出てきたとして、それがある場面で有効であっても、付帯する、
例えばJavaを前提としたUMLの書式であったりJavaの文脈であったり、そういった
ものはあまり普遍的ではないように感じる。
例： Beanとかなんとか書いてある本を、PHPで実際に参考にするのは非常に難しい。
880:nobodyさん
08/07/12 12:41:03
>>879
> "OOではなく"普通に有効なものだと思う。
色々あるだろうけど、それはその通りだと思うよ。
ただ、例えばモジュール化とかの方法論は、機能単位に分解することを前提にしてたり、
して、モデリングの方法論としては使用されていなかったというだけの話で。
OO言語が流行るまで、個々のエンジニアレベルでOO的な思考がされていなかったのかと
言えば、そんなことはないでしょ。ただ、共通的なモデルとしては語られなかっただけで。
でも、それが出来るようになったのは、それなりに大きい。
後半は何言ってるかわからんから、コメントは控える。
881:nobodyさん
08/07/12 15:09:10 2oBRlMWN
モデル駆動型アーキテクチャ - Wikipedia
URLﾘﾝｸ(ja.wikipedia.org)
>フォレスターリサーチは2006年に MDA は死に体（D.O.A.）であるとした
OOA/OOD業界には、SIerが儲けるためのバスワードが混ざっているんでしょうか？
882:nobodyさん
08/07/12 15:11:44 2oBRlMWN
× バスワード
○ バズワード
バズワード - 【buzzword】(特にビジネスの世界における)流行語。
バズワード(buzzword)とは一見専門用語のように見えるがそうではない、明確な合意や定義のない用語のことである。
883:nobodyさん
08/07/12 16:00:51
OOA/OOD業界って何？って話があるけど、そもそもOOをまともに語れるSIerなんてそんなに居ないと思う。
昔、IBMでさえ、「VBはOO言語だから、VBで作ったシステムはオブジェクト指向技術で作られているんだ」なんて
意味の無いことを主張してたし。
ただ、近いところだと、SOAなんかはバズだなぁって思う。
884:nobodyさん
08/07/12 17:44:37
いや意味なくはないだろw
具体的に何が気に障ったのか判らんが
885:nobodyさん
08/07/12 17:54:21 bJKqKB86
ethnaみたいなシンプルなFWで十分
MVCとヴァアリデートだけできればいいし
886:nobodyさん
08/07/12 19:26:06
> MVCとヴァアリデートだけできればいいし
逆に、それ以外で要らないものって何だ？
887:nobodyさん
08/07/12 19:35:29
MVCが広すぎて何とも言えないが、独自セッションライブラリとかO/Rマッパとか
やたらと柔軟なrouterとか、使いやすいConfig、Repositoryクラスとか、そんなもの
のことかも
でも、ぶっちゃけヴァリデートはテンプレートライブラリと同程度にフレームワーク
からの独立性や選択肢が欲しいな。
一時期HTML_QuickFormが流行ったのは、独立したヴァリデーションライブラリの
側面もあったからだと俺は思ってる
888:nobodyさん
08/07/12 20:05:09
>>884
別に自分の話じゃないよ。
興味があるなら、九大病院 IBM オブジェクト指向 でググって見てちょ。
889:nobodyさん
08/07/12 21:52:20
>>887
> MVCが広すぎて何とも言えないが、独自セッションライブラリとかO/Rマッパとか
> やたらと柔軟なrouterとか、使いやすいConfig、Repositoryクラスとか、そんなもの
> のことかも
俺もそれのことだろうとは思ったのよ。
でも、本当にそんな便利なものをいらないと
言っているのかと疑問になってね。
890:nobodyさん
08/07/12 22:01:37
今時PHPてどこの乞食だよｗｗｗ
891:nobodyさん
08/07/12 22:05:04 yMqg6CvP
九大病院 IBM オブジェクト指向 に一致する日本語のページ 約 320 件
URLﾘﾝｸ(bizboard.nikkeibp.co.jp)
日経コンピュータ 1998/08/17号
大規模オブジェクト指向開発が破綻 早期稼働を狙いVisual Basicへ変更
九州大学医学部附属病院は98年5月，医師や看護婦のあらゆる業務を支援する「新医療情報システム」を予定より1年以上遅れて全面稼働させた。
当初は97年1月から順次稼働させる予定だったが，システム・インテグレータとして開発を担当した日本アイ・ビー・エムのプロジェクト管理の甘さなどが原因で，開発が大幅に遅れてしまった。
最初smalltalkを使って、頓挫してVisualBasicに変更＝オブジェクト指向プログラミングを捨てて、構造化プログラミングでデスマーチに対処したんですね？
892:nobodyさん
08/07/12 22:08:56
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
スルガ銀行は2008年3月6日、日本IBMに111億700万円の損害賠償を求める訴訟を東京地方裁判所に提起したと発表した。
「新経営システム」の開発を委託したが、「IBMの債務不履行により開発を中止せざるを得なくなった」（広報）ことにより被った損害や逸失利益などの賠償を求めたもの。
スルガ銀が導入を目指していたのは、IBMのオープン勘定系パッケージ「NEFSS/Corebank」。
2004年9月にプロジェクトを開始していた。
当初は2008年1月の稼働を目指していたが、開発遅れにより、延期していた。
俺なら111億円も弁償できないよ＞＜
PHPで月100万円儲けられれば十分です(^^)v
893:nobodyさん
08/07/12 22:10:53
>>888
結構古い話なのね
肝心の97年のnikkeiBPの記事がリンク切れなのでぐぐっても良く判らないな。
URLﾘﾝｸ(bizboard.nikkeibp.co.jp)
有料記事化してたこいつかな（SMLのML漁った方が早いのかな）
ともあれあの当時のVBでOO云々っていう事なら
俺も無理ある話だと同感ましたわ。
2006/7にも受注してんのな
URLﾘﾝｸ(www-06.ibm.com)
こっちの話題はいまんところ見当たんない感じ
894:nobodyさん
08/07/12 22:11:11
>>887
その発想はいいかもね！
PHPのフレームワークが乱立しているけど、いいとこ取りで自分で組み合わせて使うのがスマートだと思う。
＝大きすぎず小さすぎず、必要十分条件を満たすように使い分けられる時代が来るかな？
895:nobodyさん
08/07/12 22:11:24
>>891
被ったよ。失礼
896:nobodyさん
08/07/12 22:14:56
>>891
それだけじゃなくて、名前は忘れたけど九大病院にシステム好きなセンセイが居て、
システムの要件としてオブジェクト指向技術をつかったシームレスなシステム化っのが
あったらしい。
で、IBMはVBだってOOPLなんだから、これもOOだって言い張ってた。
結局どうなったかは知らんけど。
スレと関係なくなってるから、ここまでにしておくね。
897:nobodyさん
08/07/12 23:13:48
98年というと、Vistual Basic 6.0が発売されたとしか。
どうだろうね。
VB6なら、クラスもインターフェースもあるし、
オブジェクト指向として必要最低限の機能はあるんじゃね？
898:nobodyさん
08/07/13 08:44:03
オブジェクト指向って、厳密な定義が難しいよね。
URLﾘﾝｸ(d.hatena.ne.jp)
899:nobodyさん
08/07/14 14:03:45
まぁ、別にCでだってOOPしてるプログラムとかAPIはいくらもある訳で。
900:nobodyさん
08/07/14 21:48:58
当たり前だが使ってる言語だけでOOとか非OOとか言うことはできんわな
901:nobodyさん
08/07/14 21:58:48
>>900
PHPやPerlが一番いい例じゃないかｗ
そこまで行くと、何を今更と言ってもいいかと
まあ議論の内容は大事だけどね
902:nobodyさん
08/07/17 01:56:21 r8Tb5l59
外国語ではフランス語が一番オブジェクト指向に近い
903:nobodyさん
08/07/17 02:06:39
名詞に性がある言語はOpen Close Principleに反していると思う。反論は認める。
904:nobodyさん
08/07/17 09:42:03
きょうのむずかしいことば「Open Close Principle」
Open Close Principle に一致する日本語のページ 約 55,700 件
URLﾘﾝｸ(www.morijp.com)
Gang of Fourのデザインパターンは，全部で23個ものパターンがあります．
オブジェクト指向には，カプセル化，継承，ポリモルフィズムといった数少ない道具しかありません．
では，なぜ23個もの多くのパターンになってしまったのでしょうか？
このことは，デザインパターンの中に何かかくされた原理というべきものが存在するということを暗示しています．
それが今回紹介するOpen-Closed Principleです．
Bertrand Meyerによれば，Open-Closed Principleとは次のことを意味します．
「モジュールは拡張性について開いて（Open）おり，修正について閉じて（Closed）いなければならない」
このOpen-Closed Principle -- 「結んでひらいての法則」は，オブジェクト指向設計を考える際，その設計が正しいかどうかの指針を与えてくれるもっとも重要な原理です．
>>903
ネタThanksですｗ
参考になりました(^^)v
905:nobodyさん
08/07/17 13:41:46
理解できたようで理解できていないのがオブジェクト指向
906:nobodyさん
08/07/17 13:47:12
オブジェクト指向すら理解できてない乞食は
コンピュータ学園HALでも通っとけ
907:nobodyさん
08/07/17 20:12:06
>>904
> オブジェクト指向には，カプセル化，継承，ポリモルフィズムといった数少ない道具しかありません．
> では，なぜ23個もの多くのパターンになってしまったのでしょうか？
数字はたった10個しかないのに、
ものすごくたくさんの数値パターンがあるのと同じ。
文字はたった26文字（アルファベット）しかないのに、
いろんな小説が作られたのと同じ。
人間は少ないもので、数多くのパターンを表現できるように・・・ではなく、
数多くのパターンを、少ない物で表現可能にしてきたのだよ。進化とともにね。
908:nobodyさん
08/07/17 20:33:28
GoFのパターンがデザインパターンのすべてではないしね。
代表的なものであるのはまちがいないけど。
デザインパターンの重要な点は、有能なプログラマなら意識的
あるいは無意識にやっている、まっとうな設計に名前をつけたこと。
名前が付けられることで方法論が共有でき、会話やグループプログラミングがスムーズになるから。
909:nobodyさん
08/07/17 23:40:50
実際理解できてない奴大杉
910:nobodyさん
08/07/18 02:20:52 VtO/mWcS
GoFというネーミングセンスに痛さを感じてしまう。
と思ってたらこれが元ネタ？
URLﾘﾝｸ(ja.wikipedia.org)(%E3%83%90%E3%83%B3%E3%83%89)
911:nobodyさん
08/07/18 02:33:21
その程度で痛いとか言ってたらdankogaiなんてどうなるの？
912:nobodyさん
08/07/18 20:21:15
PHPのフレームワークはpradoが圧倒的に人気みたいですね
URLﾘﾝｸ(q.hatena.ne.jp)
913:nobodyさん
08/07/18 20:43:14
Pradoってなんだよｗｗｗｗ
914:nobodyさん
08/07/18 20:47:51
これはひどいｗｗｗｗ
915:nobodyさん
08/07/18 21:11:58
pradoはかなり特殊だから信者がこぞって入れたんだろうな
916:nobodyさん
08/07/18 22:09:19
潔くPHP5だというだけで特殊扱いか。SAXが流行ってた頃を思い出すし、Pradoを俺は嫌いじゃないよ。
917:nobodyさん
08/07/18 22:37:15
いや、PHP5とか好きとか嫌い以前にね。
そのアンケート結果不自然すぎでしょｗ
フレームワーク自体の問題じゃなくて
認知度の問題から、その結果はありえないの。
918:nobodyさん
08/07/18 22:37:45
いやPRADOの特殊性はPHP5縛りとかそんなチャチなものじゃなくて
もっと恐ろしいというか、どう見てもDelphiですな所。
不作為であの結果はありえないっしょ。
919:nobodyさん
08/07/18 23:40:48 w/EYto11
汎用性ではETHNAでしょ
920:nobodyさん
08/07/22 03:55:09
>Mapleは存在をしりませんでした。T-T。これ日本でつくられているのかな。
ワロタｗ
921:nobodyさん
08/07/23 17:01:32
URLﾘﾝｸ(radar.oreilly.com)
GAEにPerlが載ってPHP静かに脂肪ｗｗｗ
922:nobodyさん
08/07/27 19:58:30
脂肪ネタ、実は好きですｗ
923:nobodyさん
08/07/30 15:19:27
Rails の migration のように、データベースのテーブル定義を複数人で同期させる仕組みって PHP にありますか。
なんかよさそうなライブラリやツールがあれば教えてください。
924:nobodyさん
08/07/30 19:35:58
>>923
俺も知りたいな。
うちでは、Excelのテーブル定義書とテストデータ（や初期データ）ファイルから、
誰かが書いたVBAマクロでSQLをテキストファイルにしている。
テーブル定義やデータが変更されたら、データベースごとドロップして再度流し込み。
この辺をフォローしているフレームワークやライブラリってあるのかな？
まあ上記のやり方で、わかりやすくてしかもPHP以外でも使えるのであんまり必要は
感じていないのも事実だけどｗ
925:nobodyさん
08/07/31 12:29:49
>>924
それだとデータは再入力しないといけないよな。それは困る。
データはどうしてるの?
926:nobodyさん
08/07/31 12:52:20
924じゃないけど、そんなの先にダンプしとけばいいんじゃないの？
カラム名変わってたらちょっと手を入れるけど、
追加とかなら大抵平気だろ。
つか、そもそもそんなにrailsが好きならrailsのmigration使って管理しろよ。
開発環境なんだし、PHPであるひつようなんてないだろ、どうせ。
927:924
08/07/31 13:24:55
>>925
共通で使うデータ（テストデータ・初期データ）はデータファイルとして
これもExcelにしておく。INSERT文には自動変換。
データのファイルを作るのが結構手間だけど、alterなんちゃらでテーブル
定義を変更し続けて、開発者間での整合が取れなくなるのが一番嫌だから、
あくまでドキュメントベースでやってる。
ただのテスト用データなら、>>926が言うようにそれぞれが勝手にダンプ
すればいいし。
928:nobodyさん
08/07/31 14:10:50
>>926
>924じゃないけど、そんなの先にダンプしとけばいいんじゃないの？
>カラム名変わってたらちょっと手を入れるけど、
>追加とかなら大抵平気だろ。
それを、スキーマが変更されるたびに、手作業で、開発者全員がやらないといけないの?
>つか、そもそもそんなにrailsが好きならrailsのmigration使って管理しろよ。
>開発環境なんだし、PHPであるひつようなんてないだろ、どうせ。
別にRailsが好きなんて書いてないんだけど。
Railsのmigrationはよく出来ていると思ったから、PHPではどうしたらいいかを聞いただけ。
なんかRailsに引け目でもあるわけ? >926
929:nobodyさん
08/07/31 15:16:19
スキーマーの変更なんて、そんなに頻繁にするもんじゃないと思うけど。
つーか、RailsってORマッパーなしじゃ使えないのかな。ORマッパーって業務でウェブアプリ作るレベルだと意味無いというか、100%害悪だと思うんだけど。
930:nobodyさん
08/07/31 18:57:07
＞それを、スキーマが変更されるたびに、手作業で、開発者全員がやらないといけないの?
スキーマ変更が多いなら、たしかに自動化できた方が良いねえ。
でもrailsのmigrationも万能じゃないって言うか、
気をつけて書かないと全ての開発者の手元で動くmigrationにならなかったりもするので
あまりコスト的には変わらない気もするが、、、どうなんだろう。
＞なんかRailsに引け目でもあるわけ? >926
なんで引け目？ 別にないけど。
＞ORマッパーって業務でウェブアプリ作るレベルだと意味無いというか、100%害悪だと思うんだけど。
スキーマ煩雑に変わるような状況だと、それなりにORマッパーは便利。
でも仕様が固まったあとSQLに置きかえないとやばい。
あと、railsだってORマッパー無視して最初から普通にSQL書いて投げられるよ。
それともそういう話ではない？
931:nobodyさん
08/08/01 23:30:29
>>930
>なんで引け目？ 別にないけど。
だったら最初から
>>つか、そもそもそんなにrailsが好きならrailsのmigration使って管理しろよ。
とか書くなよ。
単に、PHPではどうしたらいいかを聞いているのに、"そんなにrailsが好きなら" とか "Rails使え" とか、ばかじゃねーの
ほんと役立たずな926