-OOP限定-プログラム設計相談室
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2005/09/24(土) 16:35:590337デフォルトの名無しさん
2009/05/22(金) 13:42:33よくModelとViewの関係で例えられるけど
subjectからobserverにメッセージを送るシステムの骨組みだけ提供するから
あとはそれを継承してModelとViewで好き勝手やってくれってこと？
0338デフォルトの名無しさん
2009/05/22(金) 21:03:48レベルが違う話をごっちゃにしたらダメ
0339デフォルトの名無しさん
2009/05/22(金) 21:14:27管理責任はManagerにあるんだから、
Managerにジェネレータやファクトリーの機能を持たせればOKだと思われ。
0340デフォルトの名無しさん
2009/05/23(土) 01:14:21PACなんて10年前からあんだろ
RADツールで作成するときとか既成のボタンとか流用するから
VとCは不可分じゃね？それにMVCのMは大ざっぱ過ぎね？
機能毎にグループ分けしてグループ間の行き来はレイヤーわけようぜ
って感じじゃなかったかな。
Web開発ならVとCはキレイに分けられるし、今はMVCつっても
サービス層、Dao層とかわかれてるしグループ分けならnamespace
(Javaならpackage)で行ってるし、PACがMVCの次の世代っていう
考え方は今は当てはまらないと思うよ。
0341デフォルトの名無しさん
2009/05/23(土) 02:23:25１０年前は開発なんてしてなかった
0342デフォルトの名無しさん
2009/05/24(日) 02:14:28ロジック層との融合不可能な環境がでかくなった時代背景に
注目されたモデルだからね。
Delphi位に柔軟性があるRAD環境ではそれほどレイヤ間の分離を
意識しなくてよかったのはあるやね。
UIの強化、DB項目の追加、機能追加等に備えて無意識にPAC(って言うの?)的な
分けはやっていた人達も少なくはなかったけど。
VBだと何故か殆ど全部不可分だったけどw
0343デフォルトの名無しさん
2009/05/25(月) 02:14:10VB/Delphiのフォームにポトペタのコンポーネント思考には会わなかったけど
WebではしっくりくるからWebサービスの発達と共に浸透したんだよ。
まあ確かにそれまではUIとロジック一緒にしても保守できる程度の規模の
システムでしかなかったという見方は出来るけど。
Delphiが強力ったって、Delphiから入って仕事覚えた人はあんまりVBerと
変わらないっていう印象だなあ。フォームにポトペタで設計なんか考えない感じ。
クラス派生時に可視性を下げることしかできないっていうルールが
多態性とか検討するのを阻害するしね。Delphiの場合はTAbstractButtonみたいな
ベースで考え得る機能をできるだけ網羅して、具象化するときに機能制限して使う。
コンポーネントのひな形を全部Delphi側で用意して開発者は利用するだけという考えなら
確かにクラス数が少なくていいけど、柔軟性にかけるよね。
あーなんか言葉足らずでうまく伝わらない気がするな。ちゃんと書くと長いからいいや。
0344デフォルトの名無しさん
2009/06/04(木) 22:55:00GUIのためのMVCと、WebのMVCは全然別ものだよ。
一緒なのは名前だけ。
名言集 その４
『俺、100人規模の集団サイバーテロの主犯だったこともあるんだぜ』
http://yutori7.2ch.net/test/read.cgi/news4vip/1249830540/ のID:PVAf+dux0 ＝ 自動焼人 ★
> 965 ：以下、名無しにかわりましてVIPがお送りします [sage] ：2009/08/10(月) 00:02:09.35 ID:PVAf+dux0
> まぁ何だ。
> 俺の過去の経歴に比べたら、割れ厨なんて鼻くそレベルなんだけどなｗ
> 100人規模の集団サイバーテロの主犯とか、いろいろとな。
----------------------------------------------
この自動焼人 ★メールマガジンの配信停止をご希望される方は
http://qb5.2ch.net/test/read.cgi/sec2chd/1250169591/
にて自動焼人 ★までご連絡ください
0346デフォルトの名無しさん
2009/08/17(月) 20:31:450347デフォルトの名無しさん
2010/03/05(金) 10:13:16EntryとEntryManagerという二つのクラスがあって、
EntryManagerが、複数存在するEntryインスタンスを生成、管理してます。
Entryが、他のEntryにアクセスできるようにしたいのですが、
そうなると、EntryManager<->Entryというお互いに依存関係ができてしまうと思います。
これは悪い設計でしょうか？
また、このような場合のためのデザインパターンなどはありますか？
0348デフォルトの名無しさん
2010/03/05(金) 10:25:56このような場合にインスタンスが、他の兄弟インスタンスや型を知るような依存はしたくない。
多数あるインスタンスが、多対多の関係になることは避けたい。
> そうなると、EntryManager<->Entryというお互いに依存関係ができてしまうと思います。
GoFのMediatorパターンでは、相互作用はMediatorに記述され、
ColleagueはMediatorとだけやり取りして、他のColleagueへは直接関与しない。
少なくとも一対多の関係にしておくことができる。
0349デフォルトの名無しさん
2010/04/12(月) 05:36:42経験というかバックグラウンドがちゃんとあるひとなら伝わるけど
馬鹿に伝えるのは難しいよね
0350デフォルトの名無しさん
2010/04/12(月) 16:07:490351デフォルトの名無しさん
2010/04/29(木) 21:41:13http://apr.2chan.net/jun/b/src/1272544702094.jpg
画像にあるUML図のように
AとB
どちらでプログラムを組むのがいいのでしょうか？
利点などあったら提示してくれると助かります
0352デフォルトの名無しさん
2010/04/30(金) 00:25:140353デフォルトの名無しさん
2010/04/30(金) 02:56:560354351
2010/04/30(金) 18:37:48AはMFCを参考に
Bはjavaを参考に考えました
Webサイトの解析と、それを元に一定の処理を行うというものです
作っている段階でバージョンアップ（修正）もでてくると予想してます
0355デフォルトの名無しさん
2010/04/30(金) 22:44:52継承しているのは不自然に感じるけど、MFCにそんな構造あったっけ？
もしかして、継承と関連の記号を取り違えていないか？
0356デフォルトの名無しさん
2010/05/01(土) 11:33:10「構造体に毛のはえた設計」と言ってました
Cマガは現在廃刊になってます
0357デフォルトの名無しさん
2010/05/04(火) 15:50:23DBーサーバーークライアントー表示
こういうのをクラス図として提出されてどうしようかと悩んだ
私の説明が端折り過ぎたのが原因だろうがこれはあんまりだ
0358デフォルトの名無しさん
2010/05/04(火) 18:04:52べつに いいん・・・
よくねーよｗ
0359デフォルトの名無しさん
2010/05/04(火) 19:48:070360デフォルトの名無しさん
2010/05/08(土) 15:21:19オレは最初データベースと読んでいたが、
なんとアニメの欄にＤＢの文字が・・・
まさかデータベースのアニメ（！キバヤシ風）
と思ってクリックしたらドラゴンボールだよ！
0361デフォルトの名無しさん
2010/05/08(土) 16:29:010362デフォルトの名無しさん
2010/05/23(日) 04:06:32野球ってbatファイル
ピッチャーが開始するまで誰も動かないor動けない
んで、みんなピッチャーに依存してる
ヒットも守備の重箱の隅をつつくようなところに打たないとでない
でオブジェクト指向はサッカー
監督がこういうふうに試合をしてくれって指示だけだし
あとはオブジェクトがメッセージ（ボール）をつないで試合を展開する感じ
0363デフォルトの名無しさん
2010/05/23(日) 05:54:51その辺にしておかないと大変なことになってる
0364デフォルトの名無しさん
2010/05/23(日) 06:19:180365デフォルトの名無しさん
2010/06/03(木) 17:35:34ぁぅあんっぅあああああーーーーーーーーーー
かい～いぃぃいいい～～～さああああん
0366デフォルトの名無しさん
2010/06/03(木) 23:24:58もう…おかしいでしょ。どう考えても何をねつ造しても事実はこうなのですから
↓
http://www.nicovideo.jp/watch/sm10915996
キラー小里議員、赤松広隆君不信任決議案で爆弾発言！
平成22年5月31日衆議院本会議農林水産大臣赤松広隆君不信任決議案（174国会決9賛成の討論で壇上に上がった小里泰弘議員から、爆弾発言！マスコミは一切伝えてません。
http://www.nicovideo.jp/watch/sm10815799
“独裁者”小沢一郎とフジテレビ「黒い密約」疑惑を追求②＊拡散希望
0367デフォルトの名無しさん
2010/06/12(土) 19:21:140368デフォルトの名無しさん
2010/06/12(土) 19:52:160369デフォルトの名無しさん
2010/06/12(土) 21:22:47おい！
0370デフォルトの名無しさん
2010/09/05(日) 13:57:480371デフォルトの名無しさん
2010/09/28(火) 13:24:460372デフォルトの名無しさん
2010/09/28(火) 13:32:36場当たり的に逃げ道を探して回避する(根本的な問題は完治しない)のがバッドノウハウ
本質的な部分を見直して考慮された見通しの良い(とされている)考え方がデザパタ
0373デフォルトの名無しさん
2010/09/29(水) 02:57:51なるほど
ところでデザパタに対して含みを持たせてるのは、
本質的に解決できていないものも含まれていると感じているから？
だとすると、問題を解決する方法として見たとき、バットノウハウとデザパタの境界は
案外曖昧だったりするのでしょうか
違う側面からの解説もｷﾎﾞﾝﾇ
0374デフォルトの名無しさん
2010/09/29(水) 03:07:380375デフォルトの名無しさん
2010/09/29(水) 06:20:55それが急を要しない状況で使われたとき「バッドノウハウ」と呼ばれる気がする。
0376デフォルトの名無しさん
2010/09/29(水) 07:12:030377デフォルトの名無しさん
2010/09/29(水) 08:11:02スクリプト書いて対処したりとか、プログラムの美しさを損なうやつ。
0378デフォルトの名無しさん
2010/09/29(水) 08:41:110379デフォルトの名無しさん
2010/09/29(水) 13:58:19WEBプログラムのクライアントサイドこそバッドノウハウの宝庫だな。
あとはJavaのVMごとにあるバグの回避で実装変えたりとかな。
0380デフォルトの名無しさん
2010/09/29(水) 14:24:03>JavaのVMごとにあるバグの回避で実装変えたり
したことないなあ。どんなのあった？JVMにバグがある場合は
アップデートで乗り切ってるなウチは。tomcatのHttpSession#getSessionId()で
バージョンによってセッション切れの時の挙動が違って回避プログラム書いたけど
まさにバッドノウハウだよね。OOとも何の関係もない
0381デフォルトの名無しさん
2010/09/29(水) 14:39:42でも8年くらい前の話だ。
0382デフォルトの名無しさん
2010/10/10(日) 00:44:37例えば運動方程式を解いて物体の運動を視覚的に表示するプログラムを考えます。
DirectXやOpenGLのようなものは使わず、普通のウィンドウシステムの上で動かすとします。
このとき、フレームレートとか画面の大きさというような情報は誰が持つべきなのでしょうか？
Mがフレームレートの情報を持って、自分からイベントループにコールバックを登録する構造なら、
物体が自律的に運動するさまを自然に表現できますが、
反面、Mがウィンドウシステムに依存することになり、何か変な感じもします。
逆にこれをCが持つとすれば、Mは位置と運動量と時刻くらいしか持たないことになり、
ちょっとMの仕事が少なすぎる気がします。
画面の大きさに関しては、常識的にはVの領分でしょうが、現在の位置に加えて軌跡も表示したい場合、
どこかに画面と同じ大きさのビットマップを持つ必要が出てきます。これはMにあたるでしょう。
0383デフォルトの名無しさん
2010/10/10(日) 20:10:55つか、ビットマップはVだろ…
いや軌跡をビットマップにプロットするモデルと、ビットマップを表示するビューに分ける、
とか考えられなくもないけど、そこまでするほどの例題とも思えない。
0384デフォルトの名無しさん
2010/10/10(日) 23:48:35Ｍに持たせるインターフェイスのデザインをどうするか、どんなものが好ましいのかにもよりますが、
VCペアが問い合わせてくる、ある時刻での物体の正確な位置を返す仕事であれば、Ｍの責務です。
0385デフォルトの名無しさん
2010/10/11(月) 00:08:48モデル側にあるってことは、交換可能な全てのモデルに位置を画像で返す機能をつけることになるが…。
数値だけ返して、画像への描画は別の部分が担当するのではまずいの？
0386デフォルトの名無しさん
2010/10/11(月) 00:32:40ウィンドウサイズなどの情報を抽象化するMを設ける
0387デフォルトの名無しさん
2010/10/11(月) 02:16:400388デフォルトの名無しさん
2010/10/11(月) 10:22:43Model(M)からは、軌跡の集まりを返すだけにし、その表現はPresentation Model(PM)から返すようにするってのは？
V <-- PM <-- M
PMが不要なプロパティを表示する時は、単に無視するか、透過的に扱うようにする。
0389382
2010/10/12(火) 21:36:29軌跡が初等関数で書けるようなものであれば係数を求めて渡すだけですが、
そうでない場合、まさか全ての時刻での座標を覚えておくわけにもいきませんから、
ビットマップを埋めることで軌跡を「求める」ことになるでしょう。
もっと極端な例では、マンデルブロ集合のモデルは必然的に解像度の情報を持つことになります。
0390デフォルトの名無しさん
2010/10/12(火) 21:38:480391デフォルトの名無しさん
2010/10/13(水) 00:57:24> まさか全ての時刻での座標を覚えておくわけにもいきませんから、
むしろ、保持しておいた方がいいと思うけどね。
オンメモりに乗らないくらいの巨大データなら、ファイルなり、DBなりに保存（キャッシュ）する。
または、間引いて保持する。
また、適当な間隔で間引かれたサンプリングデータをもとに、
オンデマンドで表示領域分のデータを計算すれば、全領域を保持する必要はなくなると思うよ。
この辺は、OOPとは関係ない実装の泥臭い部分になるけど。
0392デフォルトの名無しさん
2010/10/13(水) 10:06:32ビットマップの方がメモり喰うのわかってないの？
MVCのVがモニタだろうがプリンタだろうがMは影響を受けないように作るべきで、
どんなサイズでどういう風に表示するかはVが決める。表示内容はMだけど
見た目はVが決める。ビットマップで持ったらVで見た目決められないし
0393デフォルトの名無しさん
2010/10/13(水) 19:39:58全ての座標とは、軌跡上の全ての座標を保持するという意味で書いたんだ。
軌跡以外の点までは保持する必要はないってことね。
例えば、放物線なら、放物線上の点の集まりのみを保持する。
うまく伝えられなくてゴメンね。
0394デフォルトの名無しさん
2010/10/13(水) 19:50:14座標とは、UI上の座標ではなく、ある時刻の計算値のことね。
運動方程式なら、パラメーターを設定すれば、(時刻, X, Y, Z)の集合が計算できるので、その値を保持。
表示する際は、範囲と倍率を考慮して、UI座標に座標変換する。
0395デフォルトの名無しさん
2010/10/14(木) 07:37:500396デフォルトの名無しさん
2010/10/14(木) 11:17:130397デフォルトの名無しさん
2010/10/14(木) 23:04:15最終的に1034x768のbmpに納めればいい情報ならshortのx,yの2点でいいし、
bmpで持つくらいなら1024x768のbooleanの配列で持った方がまだマシ。
同じだけの情報記録できてサイズが小さくてデータが利用しやすいから。
Viewの実装がなんだろうとModelのビジネスロジックは変わらない、
それがMVC。Mの時点で最終表示系を決めたらVの仕事はなんだよｗ
0398デフォルトの名無しさん
2010/10/14(木) 23:11:25扱いが面倒で記憶域の無駄遣い
0399デフォルトの名無しさん
2010/10/15(金) 13:40:38おまえは何を言っているんだ？ｗ
0400デフォルトの名無しさん
2010/10/15(金) 20:28:50要求がはっきりしないけど、例えば同じ座標を通った回数を区別する必要がある場合はどうする?
その必要がないとしても、boolean使ったからってそれほど節約にはならないよ。1バイトなんだから。
そもそも、軌跡を描画するなら普通に考えてビットマップに描いていくのが効率がいいので
内部で二重にバッファ持つ意味がない
0401デフォルトの名無しさん
2010/10/15(金) 20:59:43UＩで、スケール変更して、拡大表示するときは、どうするの？
ビットマップから切り出して、拡大表示させる？
ジャギーでるよ。
その都度、再計算させる？
再計算のコストが高かったら？
レスポンス悪くなるよ。
軌跡の計算結果をもつことは、メモリ効率を悪くしてるかもしれないけど、
最悪、拡大時は補間してレスポンスの悪化を防ぐことも一応可能よ。
ビットマップもジャギー出さずに、補間して拡大するアルゴリズムあるのかな？
0402デフォルトの名無しさん
2010/10/15(金) 21:06:28ビットマップである以上拡大すればジャギはでる。
あきらめろ。
レスポンス問題は昨今なら別スレッドを使用すれば、
そこそこ隠蔽できるだろ。
GPU使えるならそっちを使えばよいとおもうけどな。
つかぜんぜんOOPと関係ねえからやめろ。
0403デフォルトの名無しさん
2010/10/15(金) 21:16:34曲線上の点を選択して、その値を調べたいときは、どうするの？
ビットマップに落とし込んだ時点で丸められてるから、
正確な値取れないよ。
その程度なら、再計算すればいいっていわれそうだけど、
運動方程式(微分方程式)の解が漸化式になつてしまったら、単純にその値だけ再計算できないよね？
0404400
2010/10/15(金) 21:23:01軌跡を描画に使うだけならビットマップで十分な場合は多いだろうし
ちゃんとしたシミュレーションで軌跡のデータが必要ならそのまま保持しといたほうがいいだろうし
要件がわからないのに議論しても仕方ない。
0405デフォルトの名無しさん
2010/10/16(土) 01:03:29おかしいって事だよ。なんで主題と関係ないトコで広げてるんだ？
0406デフォルトの名無しさん
2010/10/18(月) 20:53:230407デフォルトの名無しさん
2010/10/19(火) 09:17:23だがMでビットマップを作ることがMVCらしくない事には変わりない。
このスレでOOPとしてあるべき姿の話をするのか、効率を含めた妥協点を
探る話をするのかと言えば前者だろ。
0408デフォルトの名無しさん
2010/10/19(火) 11:30:41VはVRAMに表示する為に決められたフォーマットのデータを。
CにはMを展開してVに適用する手続きを。
おれはこう考えたが・・・。
0409デフォルトの名無しさん
2010/10/19(火) 18:40:340410デフォルトの名無しさん
2010/10/19(火) 19:37:110411デフォルトの名無しさん
2010/10/20(水) 00:29:450412デフォルトの名無しさん
2010/10/20(水) 09:05:570413デフォルトの名無しさん
2010/12/08(水) 02:00:510414デフォルトの名無しさん
2010/12/08(水) 16:48:17経験がないとセンスがあっても難しい。
センスがなければ経験があっても応用は難しい。
0415デフォルトの名無しさん
2010/12/09(木) 19:29:05一人で悩んでも良いけど情報収集は必要。
要件の分析や、他人の解説や設計を読んだりして新しい視点が見つかることも多い。
一人で設計ばかりしていると思考の堂々巡りに陥ることがあるのが辛い。
そんなときは、実際に作ってみたり、誰かに話してみると改善点が見つかったりする。
大規模なものは知らないけど、一人で設計やってるものとしては、こんな感じ。
0416デフォルトの名無しさん
2010/12/09(木) 23:25:57とりあえず作ってみるってのはいいですね。
だぶったっていいわけだし
0417デフォルトの名無しさん
2011/01/15(土) 00:38:50保険商品ってあるカテゴリで共通してる属性があったり、
その商品単独でしか持ち得ないような属性もあったりします。
Javaではinterfaceで共通部分を定義して、abstractで一般的な値を設定、
特有の属性や例外的な処理はそれぞれ具象クラスでってパターンにしようと思っていますが、
この保険商品をDBのテーブルで表す際にどうするか悩んでいます。
１．1つの「保険商品」テーブルに入れてしまう。joken1、joken2みたいなカラムで固有属性をカバーする
→ 明らかにおかしい
２．商品ごとにテーブルを分ける。
→ 数が多くなりすぎる。保険商品一覧を取りたい時に大変。
３．共通部分のテーブルと固有部分のテーブルで分ける
→ joinが多発する（5～8テーブル位）。商品固有テーブルだけでも10テーブル位作らなきゃだめそう。
個人的には3しかないかなと思っていますが、何かいい案はありますでしょうか。
ちなみに会社の人間は1を勧めてきました。
0418デフォルトの名無しさん
2011/01/15(土) 12:17:401の派生型だけど、固有属性の多い商品が増えたからといってDDL変えることもないし
エンティティクラスのアクセッサでその属性を管理してあげればいいだけだから簡単。
固有属性が結構複雑で属性名も大事だったりするなら「固有属性テーブル」を一つだけつくって
保険商品ID、属性名、属性値の３カラム構成、PKは保険商品ID+属性名。
エンティティクラスではMap<属性名, 属性値>という型で固有属性マップを持つ。
このどちらでも属性tのget/setのために具象クラスにわける必要ないよ。
計算式とか含むなら分けた方がいいけど
0419デフォルトの名無しさん
2011/01/15(土) 14:47:27RDB？とJava(オブジェクト指向)のデータの持ち方で悩んでいる？
それなら「O/Rマッピング」の製品や書籍があるからそちらを参考にしてみては。
基本は製品を買ったほうが工数も掛からないし信用性もあるからいいと思いますけど
なかなか製品購入を許してくれる会社も少ないからな．．．
ここからは個人の意見で（何がベストなのかは環境によっても違うと思うので）
>２．商品ごとにテーブルを分ける。
これがいいと思う、データは会社の経営資源（リソース）だけどシステムは道具に過ぎない。
データは正しい構造（正規化）でもっていなければならない。道具に合わせたデータ構造は間違ってと思う。
>→ 数が多くなりすぎる。保険商品一覧を取りたい時に大変。
viewやプロシージャでも作っておけば？データに関してはDBMSに任せるのも手だと思う。
俺的にやっぱりベストなやり方は、RDBは正しく正規化で作り、システムも正しくオブジェクト指向で作り
「O/Rマッピング」の製品を買って繋ぎ合わせるのが一番だと思う。
0420417
2011/01/18(火) 00:17:36>>418
>保険商品ID、属性名、属性値の３カラム構成、PKは保険商品ID+属性名。
>エンティティクラスではMap<属性名, 属性値>という型で固有属性マップを持つ。
なるほど、こうすれば雑多な項目を格納できそうですね。
属性名（属性ID）を外部キーとして属性マスタを作れば正規化も満足できそうです。
そういえば以前に関わった案件ではこのやり方でした。
>>419
「Javaでは…」のせいで質問のポイントを不明瞭にしてしまいました。
すみません。蛇足でした。
>２．商品ごとにテーブルを分ける。
>これがいいと思う、データは会社の経営資源（リソース）だけどシステムは道具に過ぎない。
うーん、そうですね。それは正しいように思います。
テーブル数が相当数になりますが、だからといって、
それを少なく管理しようとする試みも、また合目的的ではなさそうです。
もちろん、結果的に少なくなったというのであれば、それは歓迎すべきでしょうが…。
0421デフォルトの名無しさん
2011/01/18(火) 10:37:46商品名、担当部署とか共通の項目が多いのであれば商品毎のテーブルは
OO的にも正しくないと思うよ。固有属性専用テーブルはいわゆるサマリ-詳細テーブルの
関係だからよくある形じゃないかな
0422デフォルトの名無しさん
2011/02/06(日) 00:17:07例えばWindowクラスのOS別実装するときどうしますか？
ソース互換にするためには
Window w = new Window();
ってやりたいんですが、Windowの実装はWin32Window、LinuxWindowとか
別クラスで実装するのが普通なんでしょうか
この場合Windowをインターフェースにして
Window w = new Win32Window();とかになるんでしょうか
でもこうするとソース互換なくなるしWin32Windowを後悔しちゃうとOS依存の内部実装が見えてしまうので
良くないですよね？普通はこういう場合どう設計するんでしょうか
0423デフォルトの名無しさん
2011/02/06(日) 00:47:26その中で、環境別にWin32WindowなりLinuxWindowなりをnewして返す。
0424デフォルトの名無しさん
2011/02/06(日) 01:53:38C#のGraphics.FromImageみたいなものですか・・なるほど・・
0425デフォルトの名無しさん
2011/02/06(日) 01:56:24>Window w = new Win32Window();とかになるんでしょうか
そこでDIですよ
0426デフォルトの名無しさん
2011/02/06(日) 01:57:280427デフォルトの名無しさん
2011/02/06(日) 12:52:31デザパタ本にまんまあるな。
0428デフォルトの名無しさん
2011/02/09(水) 16:24:43ヒープが少々必要な事と Cでのコーディングは少々手間が掛かるが完成後のメンテは楽チン
0429デフォルトの名無しさん
2011/02/16(水) 13:23:490430デフォルトの名無しさん
2011/02/20(日) 11:39:01.75メンテと新規機能の追加は楽です
ARMとdsPIC専門で16KB以上のSRAMがあるマイコンの場合に限定して採用していますが
ヒューマンインターフェースが入るファームウェアはPCアプリ感覚が生きてきますので
今までより開発スピードと質がワンランク上がりました
RTOSが必要無くなったのは 必然的にイベントベースになり クラス間が
スタティックカップリングからダイナミックカップリングに変わる為ですね
同時に意図的にですが かつてのウォータフォールスタイルの開発も無くなりました
小さいPICマイコンでは今までの構造化ですが ｗ
0431デフォルトの名無しさん
2011/03/02(水) 14:25:17.04既存クラスに機能追加した時に、OCPを守った上で一番良い方法は？
スーパークラスも機能追加したい場合がよくあると思いますが
OCPだと既存クラスに手を入れるのは基本NGになる。
そうなると、やっぱりメタクラスで実装するのが一番なのか？
しかし、メタクラスを実装していない言語も多い。
あとは、スーパークラスをNULLオブジェクトとして設計する。
既存クラスに手を入れるが、NULLオブジェクトだからロジックには手が入らない。
実用上問題ないと考える。
みなさんはメソッド追加を見越して、どのようなクラス設計をしていますか？
そもそもスーパークラスにメソッド追加自体を許さないとか？
0432デフォルトの名無しさん
2011/03/02(水) 14:35:13.64がまずは第一だと思うよ
0433デフォルトの名無しさん
2011/03/02(水) 14:56:45.16複数の実装クラスで同じロジックを一杯実装しなきゃならんようになったら、abstractでデフォルト動作を規定して、それを継承って感じ。
0434デフォルトの名無しさん
2011/03/02(水) 15:07:07.41既存のメンバの動作を変更しない限りは別に問題ない
0435デフォルトの名無しさん
2011/03/02(水) 15:13:48.68「メソッド追加を見越したクラス設計」って、
何かよくわからんが嫌なにおいがする。
0436デフォルトの名無しさん
2011/03/02(水) 15:18:18.33それなら妥協して普通の仮想メソッドにして既定の実装を提供しておくだけ
たぶん>>431の言葉でいえばNULLオブジェクト
■ このスレッドは過去ログ倉庫に格納されています