【PHP】フレームワークについて語るスレ9【総合】
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
2007/12/11(火) 23:37:20ID:???http://pc11.2ch.net/test/read.cgi/php/1192604501/
0210nobodyさん
2007/12/19(水) 02:52:08ID:???PHPを殺すのはPerlでもRubyでもなくPHPユーザかもな
>>200-202とか>>204-205とか
道具の使い方が判ってないだけじゃん
0211nobodyさん
2007/12/19(水) 02:53:44ID:???ZSはZF対応とかなってるけど、スケルトンコードを吐いたりしてくれるわけ?
0212nobodyさん
2007/12/19(水) 02:55:39ID:???なぜなら、「フレームワークを使わなくても
すでに自作のフレームワーク相当のものがあるから」
楽だといっている人がいることが何よりの証拠。
自作のフレームワーク相当のものを作らなくて言い分
楽になっている。
0213nobodyさん
2007/12/19(水) 02:57:41ID:???スケルトンなら、現在のフレームワークはほとんどはいてくれるけど？
それもどっかのライブラリみたいな、コード満載で
IDEで触ること前提の手がつけられないようなものじゃなく、
必要最小限に絞り込まれたわかりやすいスケルトンを生成してくれる。
0214204
2007/12/19(水) 03:10:05ID:???フレームワークとオブジェクト指向は分けて語りたい所。
極端な例で申し訳ないが、「どういう土台が必要か」と言う時に
オブジェクト指向を単なる「変数と関数を同時に保持できる枠」
として運用されちまうと意味がないじゃない。
Webアプリである以上、PHPはページ遷移が免れないからさ、
実運用上ではカプセル化が最も意味がある点だと思うのよ。
>>200を名指ししたのは（もし本人だったらごめん）、
Webアプリの実際の実装や運用でOOADとやらがナンボのもんよって
感じがつきまとうのね。
もちろん、俺の業務にまつわる色んなモンが、俺にバイアス掛けてる
訳だけど、突っ込み貰ってるうちに納得できる事は納得しときたい。
攻撃的な文章投げちまった以上、俺も他者の意見聞いて考えてみたい。
後の指摘は、我ながら反省しつつ同意。
たまたまウチで「設計上違う」の理由として「フレームワーク採用したから」
という話に置き換える奴に苦痛を感じてた折で、別問題な言及に至りました。
申し訳ない。
>>212
そりゃ、必要な物「だけ」が「そのまま」あればいいんだけど、
なかなかそういう各々の利用者全てにご都合主義なフレームワークってなくね？
ライブラリ物なら必要最小限をある程度絞れるけど、大仰な構成になると評価に困る
0215211
2007/12/19(水) 03:12:38ID:???えええっ... (´д｀;) あれ?
IDE(PDTとか)からﾎﾟﾁｯっとするとﾍﾟﾛﾝって出てくるのを期待してたんだけど?
齟齬が発生してたか、俺が無知なだけか... 両方かな?
ちょっとググってくる。
0217nobodyさん
2007/12/19(水) 03:19:25ID:???> そりゃ、必要な物「だけ」が「そのまま」あればいいんだけど、
「必要なもの」を先に定義してくれないか？
それがたとえ自作のものだったとしても、
自作物に手をつけないで作ったことがあるかい？
世の中にありえないものを、求めない。
どこまでフレームワークに夢見てんだよｗ
フレームワークは便利なものであるが、
完璧なものではない。そもそも世の中に完璧なものはない。
0218nobodyさん
2007/12/19(水) 03:23:45ID:???>>214の捕捉
「土台にフレームワークがほしい」という点だけど、PHP5でもフレームワーク
なしに十分に変更要求に耐えるOOP出来ると思う。
って自分のレス読み直したら、OOP批判が先に出てて誤解招いた。ごめん。
重ねて個人的な状況や見解としては、OOPな枠設計が必要な場合でも、
「利用者全てのご都合主義」に対応しようとしている汎用PHPフレーム
ワークを評価すると、実行オーバーヘッドとスタッフ全員への学習コストが
問題になっちまう。
この場合、プロマネ仕様な場当たり俺俺で十分なのは当然なので、完全な私的状況に乗った言及になってしまっていたと思います。重ねてごめん。
フレームワークの意義に一石投じたかっただけなので、名無しに戻ります。
他の話題の方々、失礼しました。
0219211
2007/12/19(水) 03:32:09ID:???「IDEでスケルトンコードを」って書いてたじゃんw。
出来ることなら、新規プロジェクト生成でディレクトリ構造の選択と生成。
その各ディレクトリで、例えばcontrollersディレクトリで新規phpファイルを
生成したらコントローラ用のスケルトンコードを吐いておいてくれるとか。
0220nobodyさん
2007/12/19(水) 03:32:26ID:???>「必要なもの」を先に定義してくれないか？
無茶なことを言うなw
定義できないからみんな俺俺で対応する（せざるを得ない）ケースが増える。
＞完璧なものではない。そもそも世の中に完璧なものはない。
どっかで反感買ったようだ。悪い。
仰る通り、不完全でもそのまま乗っかれる（か確実に補足できる）なら、フレームワーク採用に全く問題はないと思う。
0221209
2007/12/19(水) 03:48:23ID:???> 「土台にフレームワークがほしい」という点だけど、PHP5でもフレームワーク
> なしに十分に変更要求に耐えるOOP出来ると思う。
出来るよ。ただ土台があった方が楽が出来ると云うこと。
実行オーバーヘッドは致し方ないけど、学習コストは「コレ」と決まれば
1度で済む。じゃぁ「ドレ」ってことでこのスレにいたりするんじゃないの?
そろそろ俺俺から脱却した方がいい? っていう岐路に立っている人もいるだろうし。
0222nobodyさん
2007/12/19(水) 03:56:16ID:???うん、まさしく。そこは人それぞれだと思う。
どんどんトーン弱めてしまってるが、俺自身は「このまま俺俺で行くか」「これというフレームワークを提案すべきかどうか」という岐路だと思う。
その上で、ウチで根強い「そもそもフレームワークなんか要らねえ」って意見が、>>201の言う程度のOOADが出来てるスタッフから上がるのね。
それ以外は、悪い意味で繊細で手が付けられないコード書く作業員ばかり。
OOPやMVCの信望者。辛抱者なのかもだが、それは別として。
フレームワーク採用して書き捨てじゃ意味ないからね。
そんな「じゃぁ『ドレ』」で選ぶに値するフレームワークを、機能や設計ではない「意義」の段階から訊いて見たかった。
0223nobodyさん
2007/12/19(水) 04:04:26ID:???考え方が二つに分かれるという前提を語れてなかったので捕捉。
a:
FW採用によって簡略化でき、スタッフ相互の記述の整合性を保ちやすくなる
b:
FW採用によって簡略化できる代わりに、適用の手間と、学習コスト、サーバ要求、依存関係が発生する
a:、b;、どっちがいいかって話で、その水準は無いなと悩んで、
後者に傾いていたのが>>204,205を書き込んだ精神状態。
なんか煽り口調が反響招いてしまいました。
これもフレームワークの意義を問いたかった故なのです。ご容赦下さい。
もちろん嘘は言ってないので反論ください。
でも明日昼出社なので今は寝ます済みませんおやすみなさい。
0224209
2007/12/19(水) 06:21:18ID:???> そんな「じゃぁ『ドレ』」で選ぶに値するフレームワークを、機能や設計ではない「意義」の段階から訊いて見たかった。
今後ずーっと使い続けられるもの :-)
で、俺俺脱却「もうZFでいいやぁ」って思ってやり始めたところ。
>>223
俺は>>200じゃないし、別に反感を持ってるわけでもないよ。
0225nobodyさん
2007/12/19(水) 07:34:15ID:???結局そのできたコードをチェック＆改修しなきゃならんし、それならテキストエディタについてるテンプレ集と変わらん。
0226nobodyさん
2007/12/19(水) 07:55:31ID:???結局その出力されたHTMLをチェック&改修しなきゃならんし、それならテキストエディタでべた書きするのと変わらん。
こうですか？わかりません（＞＜）
0227nobodyさん
2007/12/19(水) 08:00:40ID:???0228nobodyさん
2007/12/19(水) 08:53:08ID:???フレーワーク使っとけよ
0229nobodyさん
2007/12/19(水) 08:56:25ID:???フレームワークの良さがわかってない
中規模以上の案件なら間違いなく必須
0230nobodyさん
2007/12/19(水) 09:37:31ID:???なんでこのPHPは呼ばれたら、
functionがいきなり実行されてるかさえ理解してなく
フレームワークを使うのです。 だれか教えてください。
0231nobodyさん
2007/12/19(水) 09:40:02ID:???0232nobodyさん
2007/12/19(水) 09:50:31ID:???0234nobodyさん
2007/12/19(水) 20:24:20ID:???今時の三歳児ってゆとり以下だな
0235nobodyさん
2007/12/20(木) 01:46:50ID:???単に役割ごとにクラスに分けてるだけで。もともとMVCはGUIのアプリを作るときに適用する概念。
PHPの場合はパッケージの仕組みがなくて、ソースが混乱しがちなので、大規模になってきたら役割をクラスで分けるというのは整理できていい方法だと思う。
が、それをオブジェクト指向と呼ぶのは強烈な違和感がある。
0236nobodyさん
2007/12/20(木) 02:00:32ID:???5.3ではサポートされるんだよね？
0237nobodyさん
2007/12/20(木) 03:56:57ID:???切り捨て過ぎじゃね？
ページ遷移伴って破棄される齟齬を埋めるために、永続化関係が語り尽くされた上で今がある訳だしさ。
WOやらStrutsやらがそれぞれのポリシーで上手くやって来た上でRoRとか出て来てるの見ると、オブジェクト指向云々って話じゃなくなってる感じもするな。
如何にlazyに手軽にサブセットDSLやれるかっていう、LL系で実行効率無視したシロモノが好評な時代だし。
結局みんなMVCやりたいのでもOOPやりたいのでもなく、DRYやりたいだけなんじゃないかな。webアプリではなおさら顕著な点だと思う。
クラスを「メソッドとデータをまとめたもの」という切り口だけで扱ってる／しばしば扱わざるを得ない、という状況になると（それが頻繁すぎるんだけど）もうOOPもOOADやらも意味なくなっちまう。
ページ遷移モデルだと、カプセル化使い回しも意義を損ねるし。ポリモルとかPHP自体がそこまで動的に設計できるモンじゃねえし。
そもそも毎ページで色々newされる動きにOOPってマッチしてないかも。
純htmlからJavaScript経由でサーバにアクセスして、永続的オブジェクトにアクセスするサーバサイドスクリプトが走るって動きならまだ納得行くかも。
MVCとか言う前に、クライアント側の設計／サーバサイドの設計をどう見つめ直すかが勝負じゃねえのかな。
0239nobodyさん
2007/12/20(木) 13:50:29ID:???オブジェクト指向と相性良くしようと思えば、RDBMSじゃなくってOODBにするとか、HTMLを全部DOMで操作するとかにしないといけない。
0240nobodyさん
2007/12/20(木) 14:31:22ID:???よっぽど複雑なスキーマならともかくテーブルの親子関係もhas_a,has_manyで表現できるし。
中の人はOOPと無縁なSQLで動いてはいるけど。
HTMLは単に整形テキスト出力と割り切るべし。
てかゲームとかもっと複雑なプログラムなんかと比べたら全然楽だってウェブなんか。
0241nobodyさん
2007/12/20(木) 16:35:58ID:???0242nobodyさん
2007/12/20(木) 16:52:19ID:???アルゴリズム考える必要皆無なのがWebのいいところではあるが。
何が怠いってWebはブラウザの挙動がマチマチだったりクライアントの状態がわからないからな。
ゲームなら全部こっちの思い通りにいけるし、OSとかで限定すれば環境も固定だし。
プログラムの深さって意味じゃゲームのが深いかもしれないが、
Webは神経使うんだよな、特にクリティカルなところだと。
ゲームとかちょっと変な動きしてもまあいいっかで済ませられたりするしｗ
ゲームのプレイ自体には金が絡まないしな。
Webだと課金関係とかクレジットとかショップとかだと金が絡むからそこでバグると大変な事になるんで神経使う。
0243nobodyさん
2007/12/20(木) 17:03:46ID:???ゲームやソフトウェアの開発ってオフラインのイメージが強くてどうも関心が持てない。
誰かのためというよりは、自分のためにシコシコ組んでる感じ。どうでもいいけどさ。
0244nobodyさん
2007/12/20(木) 17:46:49ID:???> ウェブアプリって、データの保存がRDBMS、出力先がHTML。この2つともまったくオブジェクト指向じゃないんだよな。
出力先がオブジェクト指向なものってなに？
（CUIを含めた）ユーザーインターフェースを持たないプログラム？
0245nobodyさん
2007/12/20(木) 17:49:57ID:???> オブジェクト指向と相性良くしようと思えば、RDBMSじゃなくってOODBにするとか、HTMLを全部DOMで操作するとかにしないといけない。
うん。だから今のモダンなウェブアプリ開発では、
オブジェクト指向でデータを読み書きできるO/Rマッパーと
HTMLを作成してくれるオブジェクト指向ライブラリを使うのが当たり前。
0246nobodyさん
2007/12/20(木) 18:57:15ID:???ってのがどういうものか今ひとつイメージできない俺。
当たり前、なのか？
まさか全部DOMでノードノードで組み立てるようなもんじゃ無かろうな。
XMLの悪夢再び？
0247nobodyさん
2007/12/20(木) 18:59:50ID:???その利便性が評価されてるだけで
オブジェクト指向でデータ読み書きって意味不明
OODBって昔から言葉だけ一人歩きしてるしな
実用性あるOODB作るのが難しいとか聞くし
HTML生成も、直書きなテンプレートエンジンばかりだよな
一からDOM組み上げる物view設計って見た事無いぞ
0248nobodyさん
2007/12/20(木) 19:07:21ID:???でもXML/XSLTも構造に対するテンプレートに過ぎないよな。
DOM中のイベントに対してもOO言語側のメソッドとブリッジするくらいじゃないと怪しいかも。
0249nobodyさん
2007/12/20(木) 19:17:32ID:???そのイベントのブリッジ？は全ての場面で気軽に使うのは現実的でない、ていうAjaxの教訓もあってだな。
一回マウスが「オブジェクト」の上をかすめるだけで何十Kmもパケットが行き来してApacheがアクセスログ
吐いてPHPのオブジェクトを一からnewしてDB接続を作成してって・・・どれだけリッチなんだｗ
UI全部JavaScriptもしくはFlashで作るような形になってしまえってことなのか。結局は
0250nobodyさん
2007/12/20(木) 19:33:23ID:???規模によるよ。プレステとかコンシューマー系で1年以上かかって作るゲームのがよっぽど大変。
そっちからウェブに来たけどはっきりって楽勝。ママゴトプログラミング。
0251nobodyさん
2007/12/20(木) 19:34:03ID:???OODBだとかDOMだとか、もうね、極論過ぎだろ
webプログラミングしたことないアホしかいないのかここは
最低限OOPの理解とFW使ってwebプログラムしてる奴か
これからしようとしてる奴くらいにしてくれよ
正直読むに耐えない
0252nobodyさん
2007/12/20(木) 19:41:05ID:???確かにUI層はJS/Flash(+flex|air類)/silverlightの進化に期待できそう。
別のアプローチだと、FastCGIやapache module酷使して画面遷移による切断を回避していく動きもあるな。そういう局面ではもっとOOとして意義ある実装が検討できそうだけどね。
でもどんどん複雑化するな。
結局当面の妥協点としては、フレームワークやO/Rマッパー、テンプレートエンジンを使ってOO関係ない世界に適用していく事になるんだろうなぁ。
0253nobodyさん
2007/12/20(木) 19:43:28ID:???そういえばあんまり書き込みないな。がんばってくれ>>251
0254nobodyさん
2007/12/20(木) 19:44:36ID:???極論しすぎなのとwebprogしたことないのがどう繋がるのかw
無理して何か言おうとしなくていい。
みんな極論通して突っ込みあって遊んでるだけだw
0255nobodyさん
2007/12/20(木) 19:45:55ID:???0256nobodyさん
2007/12/20(木) 19:51:36ID:???他の言語環境渡り歩いた結果、貸鯖案件増えてPHPに落ち着いた奴も多いだろうしな
相互理解が進んで欲しいもんだ
PHPの適用範囲が絞られてるせいか、Javaだけの奴とかRubyだけの奴に比べるとこのスレの空気はマシな気もする。
0257nobodyさん
2007/12/20(木) 19:54:59ID:???コンシューマー系って時代によるだろうけど、俺俺FW作るところから始めてるような時代かしら
そういう視点から見るとPHP系のFWに不満ない？
そういう経緯の方が何使ってるか興味大。設計面や実行効率含めて面白い話が聞けそうな。
0258nobodyさん
2007/12/20(木) 20:11:00ID:???いや、環境問わずローカルで試しまくれる時代なんだから、言語はある程度触った方がいいだろ。
言語問わず、一つしか知らないってのはプログラマとして問題。
0259nobodyさん
2007/12/20(木) 20:45:29ID:???0260nobodyさん
2007/12/20(木) 20:57:22ID:???一つの見識だと思うがな。
PHPはXML（ｗ）でも吐いておけよ、てな感じか。
それをただHTML文字列を出力するライブラリをむりやりOOにしようとして苦しんでるのが
現状、っていう流れじゃないのか？ここ数レスは。
0261nobodyさん
2007/12/20(木) 20:58:32ID:???0262nobodyさん
2007/12/20(木) 21:08:42ID:???アプレットwww
オブジェクト志向なんちゃらの前に、HTMLのタグ打ちからやり直したらどうよwww
0263nobodyさん
2007/12/20(木) 21:15:47ID:???0264nobodyさん
2007/12/20(木) 21:19:07ID:???その辺を判ってない事を馬鹿にしてるんだがw
しかもアプレットは単体で噴けるw 何年前の知識www
0266nobodyさん
2007/12/20(木) 21:25:12ID:???フラッシュのアクションエディッタでオブジェクト志向とかありえないんだから
0267nobodyさん
2007/12/20(木) 21:26:02ID:???テンプレートを否定しているのか？ｗ
オブジェクト指向 = DOMで操作しないとだめとかアフォだろｗ
0268nobodyさん
2007/12/20(木) 21:28:31ID:???一つ勉強したいんだが、Flashはサーバからデータを取得するとき、どういう形式で取得するの？
Flashのオブジェクトで取得できれば一番いいんだろうが、それはサーバが限定されるだろうし。
0271nobodyさん
2007/12/20(木) 21:36:42ID:???つまり俺フォーマットか。それだけじゃ無かろうがなｗ
確かにスレ違いかも
PHPのViewの話だっけ。
ぶっちゃけテンプレートエンジンでいいんじゃね？ OOであろうが無かろうが
所詮 require の延長で、string取得してごにょごにょして echo もしくは eval なんだから
0272nobodyさん
2007/12/20(木) 21:39:12ID:???FWを使うこと自体が目的化しちゃってるやつ。
0273250
2007/12/20(木) 21:48:54ID:???もちろん俺俺フレームワークｗ
ライブラリは使いまくるけど、FWいらんかな。
でもRailsに触れてからは、これが一つのウェブプログラミングの答えだと思った。
symphonyとか使ってみようかな。
MVCとかOOPとかの議論もいいけど、一番大事なのは開発効率。
Javaの人ら見てると、どうだこれはすごい設計技術だろーみたいな
作り手の自己満足ばっかが先行してて開発効率にフォーカスしてない。
Railsはその辺はいい。
ウェブなんかほとんどオママゴトなんだから、これでええやん、みたいな。
0274nobodyさん
2007/12/20(木) 21:51:01ID:???重くなるだけな部分までクラス化してnewしまくるコードに書き換える、オブジェクト指向してるつもりなだけの論外な奴
MVCって概念だけに溺れて自分で作りにくくしてる奴もいるし
0275nobodyさん
2007/12/20(木) 21:55:14ID:???基本的には同意だが、少し間違うとコピペでいいじゃんコピペが一番速いんだから
いらんことするなってなっちゃう人も多いんだろうなと想像する
何より社長（自分の雇い主）がそれを言い出したときすごく切なくなる
たしかにそれが一番いい局面もあるんだろうけど自分にはまだそのバランスがわからんし
0276250
2007/12/20(木) 22:22:47ID:???いかに似たコードを2度書かないようにするかは永遠の課題。
最近、その辺はコードの自動生成ツールを作ることで回避してたり。
PHPはともかく、JavaやC++みたいに型あると、
型は違うけどコードのフローは同じようなのって、
クラス設計頑張ったり、テンプレート駆使したり、
上にあるDIとか使ったりするんだろうけど、
そうするとどうしても複雑になってくるよね。
何か問題起きたときソース追うのが大変。
そういうとこはコード自動生成ツール作って、そいつに重複コード吐かせちゃう。
コードのフローは素直なのにできる。デバッグも楽になれる。
重複コード書くべきでないってのは、同じコードが点在するのが問題じゃなく、
修正が一箇所で済まなくなるから。
自動生成ツールなら同じコードが散らばってても、直すのはツールだけで済む。
とか自分は思うわけですよ。
OOPで頑張るのもいいけど、こういう逃げ道もありとおもうけどな。
まぁコード自動生成を嫌がる人は多いんだけど。
0277nobodyさん
2007/12/20(木) 22:43:32ID:???ローカルでツール共有するのも手間だし
俺もサーバサイドでrubyにphp吐かせるとか狂った事やったけど、人とサーバ増やされるというので慌てて組み直したw
その辺railsって手際よくまとめてるよな
railsにPHP吐かせられないもんかなw
OOPやMVCしたいんじゃなく、一元化や効率化を徹底したいだけなんだよな、結局。
OOPやMVC、DIなんかに手法的価値がある局面はあるけど、OOPが目的になっちまうと沈む
0278nobodyさん
2007/12/20(木) 23:11:11ID:???生成されたコードをいじるなとｗ
それが出来るのなら、>>276もありかと思う
逆に、ただのソーステンプレートとしてコードジェネレータを使う
（いじること前提）なら、ポイントは生成されるソースの行数になりそう
結局railsよくできてるよなってなるんだけどｗ
0279250
2007/12/20(木) 23:17:16ID:???結局人が増えると、各々やり方の差があるからね。
その辺は、フリーになって1人でやる道に逃げて解決w
OOPやるためにOOPやってる人っているよね。
Javaの現場での話だけど、O/RマッパーはあくまでDTOであって、
Modelじゃないって考えの人がいた。
DTOって結局はテーブルと同じ構造だからDBよりの産物で、
ModelでDB的都合は隠蔽すべきって考え。
Table -> DTO(運び屋) -> Model
なわけでDTOではテーブルのカラムのgetter/setter以外の実装は一切許されず。
でも、テーブルとModelの構造は、ほとんどの場合1対1になるわけで。
やることと言えば、ModelのコンストラクタにDTOを渡してModelのメンバに格納。
ModelにDTOと同じgetter/setterを作って中でDTOのgetter/setterを呼び出し。
そして、初めてModelに実装が書ける。
結局、同じ構造のクラス2回作って手間2倍、重さ2倍、メモリ浪費2倍にさせられただけ。
テーブルにカラムが変更したときテーブルが増えたときの作業に萎え萎え。
0280250
2007/12/20(木) 23:20:22ID:???もちろんいじるのは禁止。自動生成ツールはリポジトリで管理。
さらにコミットしたときに自動的にサーバーで自動生成ツールが走る。
なんで勝手に上書きした糞野郎のコードは消えるw
0281nobodyさん
2007/12/20(木) 23:58:14ID:???それもう自動生成ツールじゃなくね？ライブラリと変わらんじゃないか
すでに生成されたものは面倒でも手動で再生成してマージさせるべきだとおもう
0282nobodyさん
2007/12/21(金) 00:02:54ID:???それはオブジェクト指向にしないといけないような複雑な機能を持ったウェブアプリはほとんどない。
例えばgmailだったら、メールをクラスで表現した方がいい。というか、クラスにするしかない。
が、世の中のほとんどのウェブアプリはDBの結果を連想配列に入れて後はそれをHTMLの中に埋め込むだけ。
オブジェクト指向の出番はない。
0284nobodyさん
2007/12/21(金) 00:10:53ID:???0285250
2007/12/21(金) 00:16:54ID:???自動生成ツールだけど2パターンあって、
1つは作ったのは手で絶対触らない＞これは出力されたコードはライブラリみたいなもんかもね
もう1つはコードのテンプレート自動作成＞Railsでモデルやテストクラスのひな形が自動でできるみたいな
俺が上で言ったのは前者ね。
>>282
ホントその程度で済む内容の開発ばっかなんだよね。
ビューにコード書くなってのは徹底すべきだが。
それをなぜJavaはてんこ盛りにしちゃうんだか・・・
とはいえ、やっぱ言語的にはOOPベースなのがいいなー
文字列とか配列とか基本的なのが、ちゃんとクラス化されてる方が好みだ。
0286250
2007/12/21(金) 00:22:40ID:???ああ、一点補足させてちょ。
この絶対いじらない自動生成部分はクラス丸ごととは限らず関数単位だったりもする。
class Hoge {
// @auto generate start
〜〜〜この中に自動生成コードを吐く〜〜〜
// @auto generate end
}
みたいに、あくまで特殊コメントの中身にだけ吐く。なんで他は好きにコード書ける。
クラス丸ごと吐くと、結局継承しないと機能拡張できないんでやめた、という経緯。
まぁこういうの激しく嫌がる人も多々いるだろうけど。
0287nobodyさん
2007/12/21(金) 00:26:37ID:???それは自動生成の運用で最低のやり方だと思う。
それなら、自分でも言ってる通り、ライブラリにするべきじゃないかな
自動生成は、あくまでも出来たコードはそのまま触らない、また、
修正があれば自動的に「全て」更新されるっていう前提が無いとただ
コードの行数を増やすだけのものになる、んじゃないかな
0290250
2007/12/21(金) 00:38:15ID:???なんか荒らしみたいなんで、そろそろ消えますね。
来年はこの手の自動生成ツールをオプソで配布したいな。
ちなみに>>286みたいなの嫌がる人、天下のMSもC#で同じことやってたお。
今はpartial使って別ファイルに吐いてるけど。
0291nobodyさん
2007/12/21(金) 00:45:39ID:???>>283
案件のレベルを引き合いに出すのは辞めにしね？
てのはなんか流れ読んでて思った事書き連ねるので長くなるけど、
人数規模での協調やデプロイ効率とかで言うと、OOPやらFW云々より、
例えば言語が静的型付けで堅いかどうかとか、
フローが定石化している環境がいいという話になってくると思うんだ。
そういう点が満たされていれば誰もが幸せかって問うと、Java案件関わった人ならあればみんな首を横に振るでしょw
クリティカルな界隈で人数規模が増えると、出来る奴の柔軟性なんて
どうでもよくて、馬鹿に間違った事をさせない仕組みが重要になっちまう。
PHPのFWの意義を語るスレにおいて、「案件のレベル」ってものすご
暴力的で寂しくなっちまう視点だと思うんだ。
ZendやCake触ってて半端な所あっても「そうそう、こういうので
いいの。こういう程度ので。ありがとZend|Cake」とかない？w
PHPに限らずLL全般だろうけど。
>>290
天下のMSはシステムハンガリアンで血吐いて以降嫌いだw
間違った理屈でも力技で平然と大規模やらかせる好例だよな
いや、個人的に嫌いながらあそこの成果物には感服しきり。
0292nobodyさん
2007/12/21(金) 00:59:39ID:???荒らしてたDOM厨のテンプレート否定派ともども詫びて吊れよ
0293nobodyさん
2007/12/21(金) 01:09:57ID:???コードジェネレータを自作するための機能まであってすごいな。
もうフレームワークを使わない理由なんてないと思う。
0294nobodyさん
2007/12/21(金) 01:15:32ID:???> 自動生成は、あくまでも出来たコードはそのまま触らない、また、
> 修正があれば自動的に「全て」更新されるっていう前提が無いとただ
自動生成でできたコードを触らないというのなら、
それはscaffoldを使うってことと同意なんだよ。
でもscaffoldだけで作れるものなんてないだろ？
だから、自動生成したものを触る ということは避けられない運命なんだよ。
0295nobodyさん
2007/12/21(金) 01:18:53ID:???あんたも消えてもいいけどなｗ
FlashもJavaScriptもOO言語ですよ PHPなんかより遙かにｗ
後は使い方だけで(ry
0296nobodyさん
2007/12/21(金) 01:21:16ID:???また、294が正しいなら、自動生成はデメリットの方が強くなる様に思う
0297nobodyさん
2007/12/21(金) 01:24:49ID:???フレームワークにライブラリってのはすでにあるんだよ。
自動生成ってのはライブラリではなく、ライブラリにすることができない
”ライブラリを使うコード”を生成しているの。
ライブラリだけあればアプリが動くかい？
どんなアプリにもありがちなCRUDの動作程度でさえ
ライブラリだけで動くものはない。
フレームワークレベルになるとscaffoldという
ライブラリを使って動作する、土台のコードが用意されるが
scaffold程度の”ライブラリを使うコード”では実用的にはならない。
0298nobodyさん
2007/12/21(金) 01:34:35ID:???それを前提に話をされてもなぁ。
あれで自動生成されてうれしいのは正直Viewおよびページ遷移部分であって、
まちがっても
$param = $request->getParam();
$db->insert($param);
// 以上、俺の妄想フレームワーク
とかいう部分ではない、と思ってるんだがな
そういったところを「自動生成」したいのか？
また、Javaみたいにsetter/getter うるさいところでは、
public function setA($a)
{
$this->_a = $a;
}
みたいなものは自動生成されるとうれしいのかもしれないけど
>>297 は違うみたいだし。
（また、出来ればこういうのはクラスの最後尾に３０行くらい改行してつけてくれ、な）
0299nobodyさん
2007/12/21(金) 01:44:31ID:???フレームワークって言葉を特別視し過ぎじゃないか？
フレームワークなんて結局んところ、特定の設計思想上に
規約や規範をセットにしてライブラリ群を提供しているだけだろ
その観点では齟齬ない話題だと思うんだけど。
>>295
現状のJavaScriptをOOPLって言うと誤解招くんじゃないの。
プロトタイプベース言語はOOPLとして認知されてるけど、
「PHPなんかより遥かに」ってのはいただけない。
実装善し悪しを語ろうにも、クラスベースと単純比較
できるもんじゃないだろう。
：そんなJSもクラスベースになろうとしてるけど、それは別の話
ActionScriptのVMはOOだけど、Flashっていうと製作環境が
混同されて不適切だと思う。
Flex/Airだって環境の名前で余計なもん含むし、現状のFlash
ランタイムはOO化する前のVMも内包してる（上に扱える）しで、混乱招く。
あの界隈、詰まらんところの説明に困るんだよな。mxmlcはjavaだしw
0300nobodyさん
2007/12/21(金) 04:08:06ID:???0301nobodyさん
2007/12/21(金) 04:26:42ID:???それ以外は馬鹿
0302nobodyさん
2007/12/21(金) 04:44:58ID:???アホどもがスレチな話題をいくらふりまこうが、
結局そこに戻る。
0303nobodyさん
2007/12/21(金) 10:05:36ID:???0304nobodyさん
2007/12/21(金) 12:01:00ID:???全ては結果が良ければなんでもいい。
理屈で間違っていても結果が良ければ問題ない。
実行結果だけじゃなくてメンテナンスや開発効率その他諸々の結果な。
オブジェクト指向だろうとなかろうと、望む要件を満たすならどっちでもいい。
満たせないのにオブジェクト指向のしがらみに囚われて実装しようとしてグダグダとかが一番最低。
んなもん全てツールの一つであって使わないといけないなんて義務もない。
それを使って結果を出せるなら使えばいいし、出せないなら使わなければいいだけの事。
0305nobodyさん
2007/12/21(金) 12:19:12ID:???こういう発想のやつって、自分の頭で開発効率あげる便利ツールとか作ったこともないんだろうな。
自動生成 = scaffoldしか頭に浮かばない。
それかレスの流れ読んでないか。
0307nobodyさん
2007/12/21(金) 21:13:22ID:???だから次に、saffoldで吐いたコードに一切手を入れず動かさなきゃいけないような事は、
現実的じゃないとか言ってる。
0308nobodyさん
2007/12/22(土) 11:38:25ID:???scaffoldで吐いたコードに手を入れないで
使えることなんてあるのか？
普通無いだろ。
お前の仕事はscaffold生成で終わりかよｗ
0309nobodyさん
2007/12/22(土) 12:01:32ID:???こんなんとFWやらOOPで仕事すんのいやだ
■ このスレッドは過去ログ倉庫に格納されています