- 1 名前：デフォルトの名無しさん mailto:sage [2009/11/18(水) 23:56:27 ]
- このスレッドは
「どんなにくだらないC#プログラミングに関する発言でも誰かが優しくレスをしてくれるスレッド」です。
ほかのスレッドでは恐ろしくて書き込めないような低レベル、もしくは質問者自身なんだか意味がよく分からない質問など、
勇気をもって書き込んでください。
内容に応じて、他スレ・他板へ行くことを勧められる、あるいは誘導される場合がありますがご了承下さい。
>>980を踏んだ人は新スレを建てて下さい。
>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。
前スレ
ふらっとC#,C♯,C＃（初心者用） Part47
pc12.2ch.net/test/read.cgi/tech/1257067411/
- 324 名前：デフォルトの名無しさん mailto:sage [2009/11/23(月) 17:04:46 ]
- それが一般的な機能なら、クラス側に機能（インターフェイス）を持たせちゃうな。
で。Twitter 用のクラスでは何もしない、と。
特殊な機能なら、UI 側での判定もありじゃない？
- 325 名前：デフォルトの名無しさん mailto:sage [2009/11/23(月) 17:07:56 ]
- >>320
同期処理かつメインスレッドが所有するListViewを処理するのに
わざわざ非同期のBeginInvokeはねえよｗ
EndUpdateまで待つためにlockかWaitHandleまで必要になるぞ
- 326 名前：デフォルトの名無しさん mailto:sage [2009/11/23(月) 17:09:30 ]
- >>321
Decorator パターンで考える。
Decorate する必要がない時は空の ConcreteDacorator で代用。
- 327 名前：デフォルトの名無しさん mailto:sage [2009/11/23(月) 17:09:39 ]
- >>322
なるほど、各メッセージ自身が自分自身の描画方法を知っている形にするってわけですね。
そういった場合でモデルと画面描画を分離させたい場合は間にもう1クラスぐらいかませるようなやり方で
良いでしょうか？
[データモデル]
MessageModel
+ Name : string
+ Message : string
TwitterMessageModel → MessageModel
+ HashCode : string
HatenaHaikuMessageModel → MessageModel
+ Keyword : string
[画面表示用のコンポーネント]
MessageComponent
+ Draw() : bool
TwitterMessageComponent → MessageComponent
- model : TwitterMessageComponent
HatenaHaikuComponent → MessageComponent
- model : HatenaHaikuMessageComponent
- 328 名前：デフォルトの名無しさん mailto:sage [2009/11/23(月) 17:13:32 ]
- そういうクラスを考えるのは楽しいんだけどさ。
あんまり役に立たないよね。
- 329 名前：307 mailto:sage [2009/11/23(月) 17:13:43 ]
- とりあえずＣ＃をボチボチ勉強します。
- 330 名前：デフォルトの名無しさん mailto:sage [2009/11/23(月) 17:15:23 ]
- >>326
すまん、空の ConcreteDacorator で代用する必要はないか。
ConcreteComponent をそのまま使えばいいんだ。
・・・ってもう解決しそうだから、どうでもいいか
- 331 名前：デフォルトの名無しさん mailto:sage [2009/11/23(月) 17:15:31 ]
- >>323
各システム固有の何かをする、ってメソッドを追加する、みたいな解釈でしょうか？
なるほど・・・
>>324
抽象クラスにメソッドを持たせるということですよね。
この場合、特殊な機能が少ないうちは良さそうなんですが、
増えていくと抽象クラスが煩雑になりそうで・・・
＃そもそもそんなに特殊機能がばらばらなのを抽象化して良いのか？って問題もあるけど。
>>326
Decoratorパターンを良く理解していないので調べてみます。
デザインパターンちゃんと勉強しないといけないなぁ・・・
- 332 名前：デフォルトの名無しさん mailto:sage [2009/11/23(月) 17:16:36 ]
- interface IExtraMessageField
{
public ExtraMessageField Type { get; } // {Name,Message,Date,System}
public string Message { get; }
}
class TwitterMessage{
}
class HatenaHaikuMessage: IExtraMessageField
{
public ExtraMessageField { get{ return ExtraMessageField.Message; } }
public string Message { get{ return ''[' +Keyword+ ']; } }
}
- 333 名前：デフォルトの名無しさん mailto:sage [2009/11/23(月) 17:16:53 ]
- >>328
switch とか if 連打の方がわかりやすかったり工数少なかったりするよなw
- 334 名前：デフォルトの名無しさん mailto:sage [2009/11/23(月) 17:19:50 ]
- 初心者程抽象化したがるからなぁ
- 335 名前：デフォルトの名無しさん mailto:sage [2009/11/23(月) 17:19:58 ]
- そこまで拡張する必要性に迫られたことないし
- 336 名前：デフォルトの名無しさん mailto:sage [2009/11/23(月) 17:21:09 ]
- この場合の正しい解は、画面側で"is"使ってインスタンス判定、固有の処理をするだよ。
- 337 名前：デフォルトの名無しさん mailto:sage [2009/11/23(月) 17:21:59 ]
- 仕事がありません
誰か下さい
- 338 名前：デフォルトの名無しさん mailto:sage [2009/11/23(月) 17:24:22 ]
- 俺の仕事をあげようか
給料は俺がもらっとくけど
- 339 名前：デフォルトの名無しさん mailto:sage [2009/11/23(月) 17:26:25 ]
- うーん、何が正しいんだかよくわからなくなってきました・・・
設計難しいなぁ。
泥臭く書くだけならいくらでもできるんだけど
綺麗に書くとなるとさーっぱりだ・・・
こういう場合に >>336 みたいに「こういう場合はこれが正しい」って断言出来るようになるには
どんだけ経験つめばいいんでしょうね。
- 340 名前：デフォルトの名無しさん mailto:sage [2009/11/23(月) 17:27:58 ]
- 断言したいだけなら、今すぐにもできるだろｗ
- 341 名前：デフォルトの名無しさん mailto:sage [2009/11/23(月) 17:32:01 ]
- >>336 は馬鹿すぎだろいくらなんでも。
オブジェクト指向言語使ってる意味ないよ。
Twitterがverupして機能増えた・・・なんて時に改修場所がいたるところにちらばるでしょ、それじゃ。
ちゅーことで断言するやつは疑ってかかった方がいいんじゃないかと思う。
|
 |
