憂鬱なプログラマのためのオブジェクト指向設計講座
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
NGNGだれかお題をくだされ。
注意1)実装部分はスレの対象外です。
注意2)OOにすると逆に見通し悪くなろうが無理やりOOで設計します。
注意3)お題は抱えている案件でも良いけど、十分に抽象化してください。
0002デフォルトの名無しさん
NGNGよーく考えてみ
0003デフォルトの名無しさん
NGNGお題「リバーシ(オセロ)」
0004デフォルトの名無しさん
NGNGなんか...なんで括弧して オセロ とかわざわざ書くのかね?
ふー。
0005デフォルトの名無しさん
NGNGあれは本スレ? で一応ソースもあがったようですから。
0006デフォルトの名無しさん
NGNG0007デフォルトの名無しさん
NGNG0008デフォルトの名無しさん
NGNG微妙にルールが違った気がする
0009デフォルトの名無しさん
NGNGそれ知りたい。打てなくなったときの対処とかですか?
0010デフォルトの名無しさん
NGNG>リバーシとオセロの違いは何でしょう?
>実は両者は全く同じゲームなのです。
>ただ「オセロ」というのはツクダオリジナル社の登録商標なので、許可&許諾料金を支払わないと名前を使用できないのです。
>ですので、このコンピューターTVゲームのマニュアルには、一切「オセロ」という言葉は出てきません。
http://www.ne.jp/asahi/cvs/odyssey/videogames/computertv/soft/
より転記。
てーかお前たち、そんなことよりお題をください。
0011デフォルトの名無しさん
NGNGリバーシは最初四つの石の配置の種類が多い、実際ネットではオセロと
リバーシは同じルールで行われてます。 名称しか違わないと言えそうです。
http://www.angel.ne.jp/~virtue/faq.html
0012デフォルトの名無しさん
NGNG「経済シミュレーション」
お金の流れを OO で作れば面白いと思った。
こんなプロジェクト(http://www.boxed-economy.org/)もあるとのことだけど
UMLなんて書いていて、これが見たらまたダメぽ。(OO に慣れてない感じがかなりする)
ソースコードは非公開。
昔、こんなスレッドを経済板に立てたけど、やはり2ch ダメだった。
http://money.2ch.net/eco/kako/1010/10102/1010251507.html
0013はたぼうだじょー
NGNG2ちゃんで煽られてる某企業に紙が居る、
と聞いた事がるようなないような
0014
NGNG盛り上がってないな・・・
誰かオセロの設計作ってよ
0015デフォルトの名無しさん
NGNG0016デフォルトの名無しさん
NGNG設計バカにはぴったりだ!(w
0017デフォルトの名無しさん
NGNG0018デフォルトの名無しさん
NGNGさっさと作れ
0019デフォルトの名無しさん
NGNG/:;:;:;:;:;:;:;:;:;:;:;:;:;,丶
さっさと作れや… /:;:;:;:;:;:;:;:;:;:;:;:;:;:;:;:;:;:;.,ヽ
i' ' ' ' ' ' ' ' 'i;:;:;:;:;:;:;:;:;.,|
,.-‐¬ ̄-、¨¬‐、 |\,. 、/ L:;:;:;:;:;:;.;.l
////""`'""''ヽソ-‐l=・= =・= ヽ:;/¨iノヽ、
//////」 -=== } | ,ノ./lllll/、
i//ノソ,._______,.""' '".i, l `_ ./lllll/ ヽ
ヽ彡i.6 ̄ ̄i.,__ノ⌒i.,_ノ ..::ゝ.,_____,,,...- /llllllll/ ヽ
/ヽ ゝ' ,rti.l.l.l.、)ゝノlllllllllゝ.,__,ノlllllllllllllソ .}
⌒`ヽ、ヽ li ./ヽllllllllllllllllllllllllllllllllllllllliゝ / /
、 V ヽ ゝ _,......__ ノノ ヽllllllllllllllllllllllllllllllllli/ ./
丶、,.、,ヽ ミ三 ` ¬ ‐‐---‐¬ ¨ ̄
((  ̄ ̄ ¨¬‐- ..,_
l 川 |
0020デフォルトの名無しさん
NGNG0021デフォルトの名無しさん
NGNG0022デフォルトの名無しさん
NGNG[スキン情報View]−[掲示板Controller]−[掲示板データModel]
みたいになると思われ。
[掲示板データ[板[スレッド[レス]]]]
みたいな構造かな。
0023デフォルトの名無しさん
NGNG自力でモデリングした経験あんま無いんで自信ないけど
Compositeパターンを適用できないかなぁとオモタ。
そうすれば
>[掲示板データ[板[スレッド[レス]]]]
みたいに「決め打ち」しないでも済むかも。
あと
http://do.sakura.ne.jp/~junkroom/cgi-bin/megabbs/lounge/index.html
みたいにファイル添付可能なスレッドフロート型掲示板にも比較的楽に
対応できるかも。
0024デフォルトの名無しさん
NGNG使ってるフレームワークはMVCモデルに沿ってます。
でも肝心のモデル層が構造化プログラミングなんです。
SEさん、モデリングなんてしてないんです。
設計=DB設計と画面設計ぐらいな感じです。
DBはある程度正規化されいい感じなんですが、そこからJavaのオブジェクトモデルへの
マッピングがありません。
ビジネスロジックを実装するためだけのクラスではフィールドがグローバル変数のように
扱われ、メソッドはただの関数にすぎないんです。
画面設計もC/Sシステムのクライアントのようです。
MVCでオブジェクト指向の開発してるような感じではなく、結局、VBで
C/Sシステム開発してるのとあまり変わらないです。
分析、設計工程がどれだけ大事かわかりました。
0025デフォルトの名無しさん
NGNG結局、そのプロジェクトは「VBでC/Sシステム開発してるのとあまり変わらない」
状態で進んでるんでしょうか?
DBからJavaオブジェクトモデルへのマッピングあたりの事例を自分は
あまり見てないもので、その部分がちゃんと出来てるならぜひ話を聞いてみたいんですが。
002624
NGNGアクティブコンポーネントはビジネスロジックです。
今回、分析過程のモデリングの成果がすべてDBのテーブル構造としてだけ利用されてるんです。
それはまあいいのですが、関係データベースとJavaオブジェクトにはやはりギャップが
あります。そのためJavaオブジェクトとして状態コンポーネントにうまくマッピングできれば
Javaプログラム側はJDBCを用いてビジネスロジックから直接DBを操作するよりは柔軟性が
出てきますよね。
実際、状態コンポーネントはRequestやSessionのデータをラップしたものぐらいです。
理想的なモデルになるとEJBのアプローチに近くなると思いますが。
実際の工数やパフォーマンスの関係もあり必ずしも理想的な設計にすることはできない
のはわかります。それでも、モデリングの成果を生かし設計工程にもう少し力を入れておけば、
変更に強いシステムになると思うんです。(この辺りでデザインパターン考慮してみる
ものでしょう。机に置いてあるデザパタ本は何なんだ・・・)
またモデル側の設計がほとんどないのに画面側の見た目の部分だけ
きっちり決まってるんですね。
しかも、画面が通常のクライアントアプリケーションのように一画面に機能てんこ盛りなんです。
ビューはJSPなんですが、タグライブラリやVelocityのようなテンプレートエンジンも
採用されておらず、結局、スクリプトレット散乱。モデル側もビューを意識したコーディング
になってます。
自分は底辺プログラマなんで影響力ないです。
もうだめぽ。。。
0027デフォルトの名無しさん
NGNG0028デフォルトの名無しさん
NGNGどんなソースかコソーリ見せてくだちゃい。
(モデル側がビューを意識するっていうのは、別にイイんでないかな・・・。
リスト渡すのでも、GUI アプリケーションにはメモリに全て構築してドンとUIに渡すって
いうこともアリだし、Web ならメモリを少しでも節約するためにわざわざイテレータ書く
っていうこともある。必要なものだけ書けばいいんで。
24君が語るに相当酷いソースな可能性が高いけど、もしかしたら俺から見ればイイ
プログラミングしてるかもしれん。)
もちろん。少なくとも データ取得方法くらいは抽象化しておくべきだと思う。
テスト用オブジェクト作ってHTML の表示のテストやってみる、とか
そういうことすらできない、HTML とデータベースのベッタリくっ付いたコードとなると、
それはかなりやる気を無くすかもしれない。(けど、それも、1週間で作れるくらいの、
使い捨てプログラムなら、アリだとは思う)
0029デフォルトの名無しさん
NGNGRDBから、本当にOO的な(継承やら多態やら複雑な関連やらいろいろ使う)
個々のJavaのオブジェクトとのマッピングはほとんど
不可能なんじゃないかと思います。
もう少し粒度を大きくして、コンポーネントの単位でものを考えた方が良いと思います。
例えば銀行のアプリなんかだと、
口座クラスと、取引明細クラスを作って、それぞれ口座テーブルと明細テーブルに
マッピングするような作りじゃなくって、
口座管理コンポーネントとして一纏めで扱います。
コンポーネントの中は、SQLガリガリだろうと、なんでもオッケー。
その代わり、他のコンポーネントからは、絶対にインターフェースを通してしか
アクセスさせない。これで、情報隠蔽できます。
0030デフォルトの名無しさん
NGNG早い話が、ラッパーってことね。ま、普通だね。
0032デフォルトの名無しさん
NGNG0033デフォルトの名無しさん
NGNGまあ程度の問題だけど、
画面の都合などをモデルに持ち込むのは、
やっぱり「汚れた」と感じるのであまり好きではないです。
そういう場合その画面専用のモデル(とそのコントローラ)を
作るってのが自分周囲での流行です。
■ このスレッドは過去ログ倉庫に格納されています