トップページ⇒tech
33コメント14KB

憂鬱なプログラマのためのオブジェクト指向設計講座

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさんNGNG
OO的な設計をみんなで勉強するために、適当なお題から実際に設計をやってみるスレッドです。
だれかお題をくだされ。

注意1)実装部分はスレの対象外です。
注意2)OOにすると逆に見通し悪くなろうが無理やりOOで設計します。
注意3)お題は抱えている案件でも良いけど、十分に抽象化してください。
0002デフォルトの名無しさんNGNG
たぶんクソスレだと思う。>>1
よーく考えてみ
0003デフォルトの名無しさんNGNG
>>1
お題「リバーシ(オセロ)」
0004デフォルトの名無しさんNGNG
>(オセロ)
なんか...なんで括弧して オセロ とかわざわざ書くのかね?

ふー。
0005デフォルトの名無しさんNGNG
>>3
あれは本スレ? で一応ソースもあがったようですから。
0006デフォルトの名無しさんNGNG
>>4 正確にはリバーシとオセロが違うからだろ。
0007デフォルトの名無しさんNGNG
>>6何が違うの?
0008デフォルトの名無しさんNGNG
>>7
微妙にルールが違った気がする
0009デフォルトの名無しさんNGNG
>>8
それ知りたい。打てなくなったときの対処とかですか?
0010デフォルトの名無しさんNGNG
>>9

>リバーシとオセロの違いは何でしょう?
>実は両者は全く同じゲームなのです。
>ただ「オセロ」というのはツクダオリジナル社の登録商標なので、許可&許諾料金を支払わないと名前を使用できないのです。
>ですので、このコンピューター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はたぼうだじょーNGNG
今度は数理経済学ネタかよ。
2ちゃんで煽られてる某企業に紙が居る、
と聞いた事がるようなないような
0014 NGNG
とても興味深いスレなんだけど
盛り上がってないな・・・

誰かオセロの設計作ってよ
0015デフォルトの名無しさんNGNG
dumpプログラムをOOで設計してみてくれ
0016デフォルトの名無しさんNGNG
良スレ見つけた!

設計バカにはぴったりだ!(w
0017デフォルトの名無しさんNGNG
スレッドフロート型掲示板システム(ぼそ
0018デフォルトの名無しさん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デフォルトの名無しさんNGNG
まだかクズども
0021デフォルトの名無しさんNGNG
↑今日中にお前が作れ
0022デフォルトの名無しさんNGNG
MVCでいうと、
[スキン情報View]−[掲示板Controller]−[掲示板データModel]
みたいになると思われ。

[掲示板データ[板[スレッド[レス]]]]
みたいな構造かな。
0023デフォルトの名無しさんNGNG
>>22
自力でモデリングした経験あんま無いんで自信ないけど
Compositeパターンを適用できないかなぁとオモタ。
そうすれば
>[掲示板データ[板[スレッド[レス]]]]
みたいに「決め打ち」しないでも済むかも。

あと
http://do.sakura.ne.jp/~junkroom/cgi-bin/megabbs/lounge/index.html
みたいにファイル添付可能なスレッドフロート型掲示板にも比較的楽に
対応できるかも。
0024デフォルトの名無しさんNGNG
Javaでサーバサイドの開発してるんですが、
使ってるフレームワークはMVCモデルに沿ってます。
でも肝心のモデル層が構造化プログラミングなんです。
SEさん、モデリングなんてしてないんです。
設計=DB設計と画面設計ぐらいな感じです。
DBはある程度正規化されいい感じなんですが、そこからJavaのオブジェクトモデルへの
マッピングがありません。
ビジネスロジックを実装するためだけのクラスではフィールドがグローバル変数のように
扱われ、メソッドはただの関数にすぎないんです。
画面設計もC/Sシステムのクライアントのようです。

MVCでオブジェクト指向の開発してるような感じではなく、結局、VBで
C/Sシステム開発してるのとあまり変わらないです。

分析、設計工程がどれだけ大事かわかりました。

0025デフォルトの名無しさんNGNG
>>24
結局、そのプロジェクトは「VBでC/Sシステム開発してるのとあまり変わらない」
状態で進んでるんでしょうか?
DBからJavaオブジェクトモデルへのマッピングあたりの事例を自分は
あまり見てないもので、その部分がちゃんと出来てるならぜひ話を聞いてみたいんですが。
002624NGNG
モデル層には状態コンポーネントとアクティブコンポーネントがあると思います。
アクティブコンポーネントはビジネスロジックです。
今回、分析過程のモデリングの成果がすべてDBのテーブル構造としてだけ利用されてるんです。
それはまあいいのですが、関係データベースとJavaオブジェクトにはやはりギャップが
あります。そのためJavaオブジェクトとして状態コンポーネントにうまくマッピングできれば
Javaプログラム側はJDBCを用いてビジネスロジックから直接DBを操作するよりは柔軟性が
出てきますよね。
実際、状態コンポーネントはRequestやSessionのデータをラップしたものぐらいです。
理想的なモデルになるとEJBのアプローチに近くなると思いますが。
実際の工数やパフォーマンスの関係もあり必ずしも理想的な設計にすることはできない
のはわかります。それでも、モデリングの成果を生かし設計工程にもう少し力を入れておけば、
変更に強いシステムになると思うんです。(この辺りでデザインパターン考慮してみる
ものでしょう。机に置いてあるデザパタ本は何なんだ・・・)

またモデル側の設計がほとんどないのに画面側の見た目の部分だけ
きっちり決まってるんですね。
しかも、画面が通常のクライアントアプリケーションのように一画面に機能てんこ盛りなんです。
ビューはJSPなんですが、タグライブラリやVelocityのようなテンプレートエンジンも
採用されておらず、結局、スクリプトレット散乱。モデル側もビューを意識したコーディング
になってます。

自分は底辺プログラマなんで影響力ないです。
もうだめぽ。。。
0027デフォルトの名無しさんNGNG
通報しますた
0028デフォルトの名無しさんNGNG
>>26

どんなソースかコソーリ見せてくだちゃい。

(モデル側がビューを意識するっていうのは、別にイイんでないかな・・・。
リスト渡すのでも、GUI アプリケーションにはメモリに全て構築してドンとUIに渡すって
いうこともアリだし、Web ならメモリを少しでも節約するためにわざわざイテレータ書く
っていうこともある。必要なものだけ書けばいいんで。

24君が語るに相当酷いソースな可能性が高いけど、もしかしたら俺から見ればイイ
プログラミングしてるかもしれん。)


もちろん。少なくとも データ取得方法くらいは抽象化しておくべきだと思う。
テスト用オブジェクト作ってHTML の表示のテストやってみる、とか
そういうことすらできない、HTML とデータベースのベッタリくっ付いたコードとなると、
それはかなりやる気を無くすかもしれない。(けど、それも、1週間で作れるくらいの、
使い捨てプログラムなら、アリだとは思う)
0029デフォルトの名無しさんNGNG
俺の経験から言わせてもらうと、
RDBから、本当にOO的な(継承やら多態やら複雑な関連やらいろいろ使う)
個々のJavaのオブジェクトとのマッピングはほとんど
不可能なんじゃないかと思います。
もう少し粒度を大きくして、コンポーネントの単位でものを考えた方が良いと思います。

例えば銀行のアプリなんかだと、
口座クラスと、取引明細クラスを作って、それぞれ口座テーブルと明細テーブルに
マッピングするような作りじゃなくって、
口座管理コンポーネントとして一纏めで扱います。
コンポーネントの中は、SQLガリガリだろうと、なんでもオッケー。
その代わり、他のコンポーネントからは、絶対にインターフェースを通してしか
アクセスさせない。これで、情報隠蔽できます。

0030デフォルトの名無しさんNGNG
>>29
早い話が、ラッパーってことね。ま、普通だね。
003129NGNG
>>30
ラッパーって、どういう意味で言っている?
0032デフォルトの名無しさんNGNG
Facadeパターン?
0033デフォルトの名無しさんNGNG
>>28
まあ程度の問題だけど、
画面の都合などをモデルに持ち込むのは、
やっぱり「汚れた」と感じるのであまり好きではないです。

そういう場合その画面専用のモデル(とそのコントローラ)を
作るってのが自分周囲での流行です。
■ このスレッドは過去ログ倉庫に格納されています