＞「分散しましょう！サバ増やしましょう！お任せ下さい！」ってな感じで対応。
「しんどい」仕事をふやさんでも・・・。
リファクタリングとチューンナップを一緒こたんにしてないか？
ロジックを変更すればそれに影響するすべての部分に再試験が必要になるわけで
それって非常に効率が悪いわけで。
それをやらずにごにょごにょ言ってるなら非常に危険なソフトウェアがちまたにあふれることになるかと。
パターンランゲージってそういった経験を文書化するものじゃなかったっけ？
>PHP/DesignPattern
horde の人とかデザインパターンを結構意識して使っている様だよ。
PEARだったらLog関連のクラスがGoF適用例として参考になると思う。
いやもっとあるよ。オレは詳しくはないけどね。
もちろんリファクタリングするにはテストファーストが重要だから。
それがなけりゃダメ。
？→？→？
↓ ↑ ↑
？→？←？
ttp://http://objectclub.esm.co.jp/UnderstandingRefactoringByChart/ リファクタリング＋デザインパターンもの？
Java言語で学ぶデザインパターン入門
『こりゃいいや！』ってWebプログラムで使おうとして
かえってごちゃごちゃになった。
Compositeパターンはツリー型掲示板なんかにうってつけじゃないの？
そうですか？
なんかただの木構造と混同してないか？
ん？……あ、そうか。
スレッド(トピック？)の下にスレッドがあるような再起構造じゃないや。
でも、子記事を持つものをComposite、持たないものをLeafと見立てて
使えないかな？
それとも俺何か勘違いしてるかな？
木構造を表現するのに適切なデザインパターンだと思うけど？> Composite pattern
,81
パターン言語には、その(solution)解法を適用する場合のコンテキスト
（背景・解決する問題の状況）や、force（制約・制限）等が書かれているはず。
更に言えば、具体的な事例や、そのパターンを適用した際に起こる副作用とかトレードオフ等、
こういった一連の状況を指してパターンと呼んでいるんじゃなかった？
solutionの部分だけを指してパターンと呼んでいる人が多い様に見受けられる。
FAQにもパターンという表現は誤解を招きやすい言葉だったって書かれているけどね。
だからと言って誤解されたままでは有益な議論は出来ないよ。
一言で説明するのは難しいかも知れないけど、設計と言い切ってしまうのはどうかな？と思う。
デザインパターン => オブジェクト指向での設計上の問題に対する解決策とそれに関する知見。
かえってごちゃごちゃになったのなら、どうしてそうなったのか考えてみよう？何か原因あるはずだよね？
ここで、パターン使ってこうなったからパターンは使えない、なんて短絡的な発想はせずに。
どうすれば、その問題をスマートに解決出来るんだろうと考えてみる。
例えば、Observerパターンで知られている問題点は、
Subjectが複数になった場合に保守や拡張が困難になる、その場合はSubjectに中間層を設けるなど。
パターンの説明には必ず関連するパターンへの参照や、例外／制限事項等が書かれているはずです。
クラス図だけ見真似てデザインパターンを使ったつもりに浸っていると、
パターン使った=>更に悪化 という*パターン(繰返しの意味で)*に陥りやすいです。
めんどいから要約してくれ。3行位に。大体それくらいの情報量だろ？
ジャンプ＆フローで要約性がないパターン。
を要約すると「お前らもっと勉強しろ、俺はこれだけ物知りだ」になります
ああ、ごめん、言葉が足りなかった。
は
Observerを使ったMVCはGUIなソフトとかには使えるけど
Webアプリケーションなんかには向かないぞ、気をつけろー。
Webアプリケーション用のMVCはJ2EEとかを参考にしろー。
って意味だったんです。
オブジェクト生成して一回で捨てちゃうもんな
結局を改善することはできないんですか？
再利用できる要素はいっぱいあるんだけどな。
ファイル操作とか毎回組んでも面倒くさいしバグの入り込む余地があるしろくな事がないと思うよ。
みたいなのが良いとは思ってないが、
の代行になる優れたコードがあったとしても
結局レベルくらいで求められる規模のwebAPPの場合
実際のところが一番速く書けて一番シンプルで
一番速く動くコードだったりしちゃわないか
再利用生が抜けてるよ。
ファイル周りで、こういう処理にはこういうパターンがいいよ、みたいのある？
趣味でCGIスクリプト作ってるけど結局ファイル入出力が処理の中心で、
ここをシンプルに書ければだいぶ綺麗になるんだけどなぁ。
後、今、RubyとXML使って汎用的なCGI向きなファイルシステム書いてます。
＞ファイルとかDBとかを同じメソッドで
＞アクセスできるようにするためのラッパクラス。
これ作ってください。
> ＞ファイルとかDBとかを同じメソッドで
> ＞アクセスできるようにするためのラッパクラス。
> これ作ってください。
Perl の DBI に当たるクラスって Ruby には無いの？
アルみたいですな。知らなんだ。
ちょっと興味があるんですが、データをCSVとかXMLに落としてくれるドライバって存在するんですか？
ttp://http://ruby-dbi.sourceforge.net/ ttp://http://www.lyricfathom.com/pukiwiki/pukiwiki.php?Web%A5%A2%A5%D7%A5%EA%A5%B1%A1%BC%A5%B7%A5%E7%A5%F3%A4%C7%A4%CEBridge%A5%D1%A5%BF%A1%BC%A5%F3 ttp://http://www.phppatterns.com/ 典型的な例が Singleton。
$a = NULL;
function GetSameObject(){
global $a;
if($a == NULL){
$a = new SameObject();
}
return $a;
}
だから、そういう小汚いコード書かなきゃイカンから言語として機能が足りてないんだろ。
PHP5 だと static あるから Singleton は書けるようになるが…それでもどうかと思う。
PEAR パッケージでよく使われてますが、 PHP4 でも普通に書けますよ。
class Hoge
{
function &singleton()
{
static $instance;
if (!isset($instance)) {
$instance = new Hoge;
// $instance = HogeHoge::factory;
}
return $instance;
}
$instance = &Hoge::singleton();
の言う「小汚い」部類じゃないかね、そのコードは。
クラス内唯一のインスタンスなんだから、論理的に言えばクラスが static 変数として持つべきだろう。
> PHP5 だと static あるから Singleton は書けるようになるが
と言っている時点で の言いたい事は自明だと思うんだが…。あんた大丈夫か？
PEAR のコードや Do You PHP にあるデザインパターンのサンプルでも良く見掛けるが、
PHP4 自体の機能が足りずに他の言語ではしなくていいような事をしている点がいくつもある。
少くとも俺は PHP はオススメしない。
デザパタの本の「はじめに」とか「概要」を読み直すことを推奨。
てことはCはダメ言語でerronoなんて使ってるunixは目も当てられないって事になるのだろうか。
そんなことだからいつまでもプログラマ + Web特化なんだな。
クラス・メソッドを使わずnewすると普通に別のインスタンス作成出来るよね？
できますよ。
言語特性や制限はありますが PHP や Perl では Private メソッドも含めてそういう
ものは書く側が慣習的に守るというだけのことです。 111 さんがいうようなことも
当然ありますけど、だからといってその言語の利点があるわけですから使い分けるの
が良いというだけの話でしょう。
コンストラクタの実装とクラス変数に大きく依存するパターンは、
PHP の言語仕様とインピーダンスミスマッチが大きい、ということは言えそうに思う。
ただ、GoFパターン全部がそういうわけではなく、
むしろ singleton が例外的だとも言える。
つか、そもそも singleton ってウェブプログラミングで使う?
まあ、singleton 以外のパターンも今のところウェブプログラミングでの使い道が
あまり見つかってないようではあるが。
しかし、ぱっとすぐ思いつかないが、
singleton 以外でも PHP が向かないパターンはありそうな感じではある。
への宿題として、
singleton 以外で PHP が向いていないと思われるパターンを提出せよ。
「ウェブプログラミングで使える」というスレの趣旨を満たすとモアベターだが、
さすがにそこまでは難しいか。
一応、慣習や暗黙の了解みたいなのは理解しています。が、
言語としての機能が足りていない部分という論点に関して言えば、コードの奇麗汚いではなくて
singletonパターンの条件を完全に満たす事が出来ない点じゃないかな。と思った。
例：データベースへ接続するクラスをSingletonにする。
ウェブプログラミングでもアプリケーションサーバ等フレームワークにはよく使われてるよ。
宿題も糞も、PHP のデザインパターンのサンプルコード読めよ。
その辺の問題点も全部書いてるわ。
気を付けてグローバル変数を使用するのと早々大差はない。
// |:!
//,. -/r‐- ､| !
/,/ ./ | _」 ﾄ､
/.＼`/ |二...-┘ ヽ
. i ,.>､;／ｰ- ､ l
! ∠..＿;'＿＿＿_＼ |
,!ｲ く二>,.、 <二＞｀＼.､ヽ.
／'´レ--‐'ﾉ. `ｰ---- ､ |＼ ヽ、
＼ `l (!" Jfヽ! `''-;ゝ 大佐ではない
`‐､jヽ ヾﾆﾆ> ﾞｲ" }_,,. ‐''´
`´＼ ｰ ／ ,ィ_}
. |_ `ー ''´ ＿｣'
, ー‐-‐‐‐--''.‐''゛,,;,,...: ゛''-､､,;,,
,ｨ'゛ ゛゛""' ゛"'''-､
/ ヽ
/ '、
l l
. l i. l
l :i. ヽ.:.:...:.:: "'
. l .:l ヽ.:.::... "''､
. l. .:l ヽ.:..:. `'､
l ::l: ';.:.:..... ヽ
l .:l.:.. .:ｨ.):.:. l.:.:.: .:.ヽ、
. l .:l..: ''ー.: .:.:l.:.:..:..:: .:i'゛
フレームワーク内で使われるのはわかるが
DBのコネクションプールはそうやってフレームワークが管理してくれるはずだから
ユーザがコード書く段階では気にしなくていいぢゃん。
Perl ですら mod_perl + Apache::DBI 使えばいいし。
と思ったが、よくよく考えてみたら、PHP にはコネクションプールが無いのか。
それは確かに問題だな。
私の知る限りでは Apache::DBI はコネクションプールをしているわけではな
くて PHP の持続的接続と同等の機能を提供するはずです。
つまり DSN 毎にコネクションを維持するだけ (さらにプロセス毎に) だと理
解していますが。
さらにコネクションプールは SQL Relay 等で実現できますよ。
どうしればいいでしょうか。
早くオブジェクト脳になりたいんです！
オブジェクト指向を学ぶ
変更なしに機能を追加したりするときにアダプタっていう
デザインパターンを使うのかな？使い方間違ってる？
ttp://pc8.2ch.net/test/read.cgi/tech/1095388499/ 実は仕事で既に動いているPHPプログラム改修作業をすることに
なったのですが、
・非常に見づらいソース。開発者は既に退社＆ドキュメントは無し。
・納期は短いのでリコーディングすることはできない。
・動作自体には問題はなく、現在正常に稼動中。
・機能拡張もあり。
という状況です。ソースが非常に見づらく保守性が著しく低いのと
機能拡張は大幅な仕様変更になるので、できればリコーディングしたい
ところなのですが、納期も無いことですし、何より現在問題なく
稼動中なのでそれはできません。
そこでなるべく既存のクラスに手を加えずに、機能拡張をしたい
という感じです。
このような場合、既存のクラスを継承させた新しいクラスを作り、
動いている部分は利用しつつ、新規の仕様に合わせた設計に作り変える
というやりかたを考えているのですが、これは別にデザインパターンという
わけではなくて、ただのOOPの継承を使ってるだけということですかね。
ちなみに、上記のような場合皆さんならどのような手法を取りますか？
識者のご意見をお聞かせいただけたらと思います。
漏れなら先ず上司に現状を報告し、指示を仰ぐな
1.現状のプログラムが如何に問題点の多い物であるか
2.前任者の無能さを叩き、リコーディングの必要性の訴え
3.リコーディングすれば納期に間に合わせる事は難しい。
しかし前任者のプログラムに手を入れた場合、（極端に保守性が悪いので）変更によって障害が起きる可能性が高く、納期が大幅に遅れる危険がある。
以上を伝えて今後の方針を決め、増援を求めるなり何なり対策を協議して･･
（要は、「責任逃れの道はちゃんと作っておけよ」と）
遅レスですが・・・
非常に勉強になりました。
ttp://http://www002.upp.so-net.ne.jp/ys_oota/mdp/Adapter/index.htm のかわりってこれでいいんじゃね？
みんなデザインパターンってあまり知らないのか？
後者の場合、Webは選択肢の一つに過ぎないけど参考になる。
これらをPHPに適用するとどうなるか考えるのも面白い。
ttp://http://www.phparch.com/shop_product.php?itemid=96 とりあえずPHP向けの本が出てるから皆買おう。
そうでなきゃ話しも出来ん。
ペーパーバッグなのにやたら高いね
> ペーパーバッグ
紙袋？
「ペーパーバック」なら表紙が紙でできた安もんくさい本のことかな。
ペーパーバッグとペーパーバック間違えてた
ビートルズの曲もペーパーバッグライターと思ってた…
よかった他にもたくさんいた…
Strategy、あたりを使うねぇ。
class array_formatter{
function format_array(&$array){
if(!count($array)) return $this->format_empty();
$html = $this->format_header($array);
foreach($array as $key => $value){
$html .= $this->format_item($key, $value);
}
$html .= $this->format_footer($array);
return $html;
}
function format_empty(){
}
function format_header(&$array){
}
function format_footer(&$array){
}
function format_item($key, $value){
}
}
こんな感じのクラスを継承して使いまくってる。
それがデザインパターンと何の関係があるの？
ttp://http://www.amazon.co.jp/gp/product/4798013188 はじめてのPHP5プログラミング エキスパート編
ワイズノット (著)
価格： ￥ 2,730 （税込）
単行本: 378ページ
出版社: 秀和システム (2006/05)
ASIN: 4798013188
目次
オブジェクト指向プログラミング
クラスの作成とオブジェクトの操作
PHPのオブジェクト指向のその他の話題
PEAR
Smarty
ユーザ認証とアクセス制御
セキュリティ
エラーと例外処理
Mojavi
PDO
オークションシステムの作成
データベースアクセスの実装
プログラムの実装
システムの問題点と、改良、拡張方法
Chapter03「PHPのオブジェクト指向のその他の話題」（P60〜76）で、デザインパターンの説明があります。
PHPでデザインパターンを勉強する人は参考になるかな？
Command パターン、Observer パターン（イベントリスナ）のような、デザインパターン、あ
るいは、MVC モデルを利用した、独自のプログラムを設計する。GoF の 23 パターンであれば、どのようなパ
ターンを用いてもよい。レポート中には、適用したパターン名、および、適用箇所を明記すること。なお、最低
でも４つ以上の独自のプロトタイプ・オブジェクトを用いてプログラムを設計するものとする。設計内容として、
次の３項目を記述する。
1. デザインパターンによって生みだす特徴を参考に、ソフトウェアのテーマを詳細に記述する。
例： Facebook のようなアドレス帳
例： Twitter のような掲示板
デザインパターンとソフトウェアの機能との関連性を考察し、なぜそのソフトウェが必要で、なぜデザイン
パターンを適用したのかを説明する。
2. 設計したソフトウェアについて、プロトタイプ・オブジェクトの一覧と、各プロトタイプ・オブジェクトが
実現する機能、および、各プロトタイプ・オブジェクト間の関係を記述する。なお、全プロトタイプ・オブ
ジェクトについて、下記のように、クラスの属性とメソッドがわかるように、ソースコードを添付すること。
命令形態、観察者形態（出来事聴取者）のような、設計形態、あ
るいは、模表制 模型を利用した、独自の計画を設計する。四の団 の 弐拾参 形態であれば、どのような形
態を用いてもよい。論文中には、適用した形態名、および、適用箇所を明記すること。なお、最低
でも四つ以上の独自の原型・物体を用いて計画を設計するものとする。設計内容として、
次の参項目を記述する。
一. 設計形態によって生みだす特徴を参考に、柔軟製品の思想を詳細に記述する。
例： 顔本のような住所帳
例： さえずり のような掲示板
設計形態と柔軟製品の機能との関連性を考察し、なぜその柔軟製が必要で、なぜ設計
形態を適用したのかを説明する。
二. 設計した柔軟製品について、原型・物体の一覧と、各原型・物体が
実現する機能、および、各原型・物体間の関係を記述する。なお、全原型・物
体について、下記のように、部門の属性と手法がわかるように、源符号を添付すること。
回答ありがとうございます。
「四の団 の 弐拾参 形態」とは何でしょうか？
足立区に住んでいるそうだ
ttp://http://inumenken.blog.jp/archives/7002197.html お世話になります。
私、責任者の加茂と申します。以後、宜しくお願い致します。
ttp://www.apamanshop.com/membersite/27009206/images/kamo.jpg 浪速建設様の見解と致しましては、メールによる対応に関しましては
受付しないということで、当初より返信を行っていないようで、今後につい
てもメールや書面での対応は致しかねるというお答えでした。
このように現在まで６通のメールを送られたとのことですが、結果一度も
返信がないとう状況になっています。
私どものほうでも現在までのメール履歴は随時削除を致しております
ので実際に１１通のメールを頂戴しているか不明なところであります。
弊社としましても今後メールでのやり取りを差し控えたく、浪速建設様
と同行の上でお会いさせていただきたい所存です。
・ブラックロックシューター
ttp://http://s-at-e.net/scurl/BRS.html ・ベヨネッタ
ttp://http://s-at-e.net/scurl/BAYONETTA.html ・風ノ旅ビト
ttp://http://s-at-e.net/scurl/JOURNEY.html ttp://http://s-at-e.net/scurl/kabetokyojinto.html ・2012
ttp://http://s-at-e.net/scurl/2012.html ・プロメテウス
ttp://http://s-at-e.net/scurl/Prometheus.html ・アバター
ttp://http://s-at-e.net/scurl/Avatar.html 下記の条件が全て当てはまる会社にご注意下さい。
・IT系 in Tokyo
・転職会議で2.5点
・転職会議の「その他>2ch情報」の欄で過去の2chスレが表示される
参考までに、
⇒ 『半藤のブブイウイウレレ』 というサイトで見ることができます。
グーグル検索⇒『半藤のブブイウイウレレ』
V6XHOPNRFF
