2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

1 :デフォルトの名無しさん:02/10/07 19:06
OO的な設計をみんなで勉強するために、適当なお題から実際に設計をやってみるスレッドです。
だれかお題をくだされ。

注意1)実装部分はスレの対象外です。
注意2)OOにすると逆に見通し悪くなろうが無理やりOOで設計します。
注意3)お題は抱えている案件でも良いけど、十分に抽象化してください。

2 :デフォルトの名無しさん:02/10/07 19:07
たぶんクソスレだと思う。>>1
よーく考えてみ

3 :デフォルトの名無しさん:02/10/07 19:15
>>1
お題「リバーシ(オセロ)」


4 :デフォルトの名無しさん:02/10/07 19:18
>(オセロ)
なんか...なんで括弧して オセロ とかわざわざ書くのかね?

ふー。

5 :デフォルトの名無しさん:02/10/07 19:19
>>3
あれは本スレ? で一応ソースもあがったようですから。


6 :デフォルトの名無しさん:02/10/07 19:32
>>4 正確にはリバーシとオセロが違うからだろ。

7 :デフォルトの名無しさん:02/10/07 20:18
>>6何が違うの?

8 :デフォルトの名無しさん:02/10/07 20:22
>>7
微妙にルールが違った気がする

9 :デフォルトの名無しさん:02/10/08 12:39
>>8
それ知りたい。打てなくなったときの対処とかですか?

10 :デフォルトの名無しさん:02/10/08 19:21
>>9

>リバーシとオセロの違いは何でしょう?
>実は両者は全く同じゲームなのです。
>ただ「オセロ」というのはツクダオリジナル社の登録商標なので、許可&許諾料金を支払わないと名前を使用できないのです。
>ですので、このコンピューターTVゲームのマニュアルには、一切「オセロ」という言葉は出てきません。

http://www.ne.jp/asahi/cvs/odyssey/videogames/computertv/soft/

より転記。

てーかお前たち、そんなことよりお題をください。

11 :デフォルトの名無しさん:02/10/08 19:32
オセロとリバーシって何が違うのですか

リバーシは最初四つの石の配置の種類が多い、実際ネットではオセロと
リバーシは同じルールで行われてます。 名称しか違わないと言えそうです。

http://www.angel.ne.jp/~virtue/faq.html

12 :デフォルトの名無しさん:02/10/08 19:42
お題ならいいのがあるよ。

「経済シミュレーション」
お金の流れを OO で作れば面白いと思った。

こんなプロジェクト(http://www.boxed-economy.org/)もあるとのことだけど
UMLなんて書いていて、これが見たらまたダメぽ。(OO に慣れてない感じがかなりする)
ソースコードは非公開。

昔、こんなスレッドを経済板に立てたけど、やはり2ch ダメだった。
http://money.2ch.net/eco/kako/1010/10102/1010251507.html

13 :はたぼうだじょー:02/10/08 20:36
今度は数理経済学ネタかよ。
2ちゃんで煽られてる某企業に紙が居る、
と聞いた事がるようなないような

14 : :02/11/10 12:30
とても興味深いスレなんだけど
盛り上がってないな・・・

誰かオセロの設計作ってよ

15 :デフォルトの名無しさん:02/11/10 12:55
dumpプログラムをOOで設計してみてくれ

16 :デフォルトの名無しさん:02/11/10 12:57
良スレ見つけた!

設計バカにはぴったりだ!(w

17 :デフォルトの名無しさん:02/11/10 13:01
スレッドフロート型掲示板システム(ぼそ

18 :デフォルトの名無しさん:02/11/10 13:13
おい、お題出たぞ
さっさと作れ

19 :デフォルトの名無しさん:02/11/10 14:00
                   _,,,,,.........,,,,__
                 /:;:;:;:;:;:;:;:;:;:;:;:;:;,丶
    さっさと作れや…  /:;:;:;:;:;:;:;:;:;:;:;:;:;:;:;:;:;:;.,ヽ
                 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 川 |

20 :デフォルトの名無しさん:02/11/12 12:28
まだかクズども

21 :デフォルトの名無しさん:02/11/12 12:42
↑今日中にお前が作れ

22 :デフォルトの名無しさん:02/11/12 13:14
MVCでいうと、
[スキン情報View]−[掲示板Controller]−[掲示板データModel]
みたいになると思われ。

[掲示板データ[板[スレッド[レス]]]]
みたいな構造かな。

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

あと
http://do.sakura.ne.jp/~junkroom/cgi-bin/megabbs/lounge/index.html
みたいにファイル添付可能なスレッドフロート型掲示板にも比較的楽に
対応できるかも。

24 :デフォルトの名無しさん:02/11/21 21:52
Javaでサーバサイドの開発してるんですが、
使ってるフレームワークはMVCモデルに沿ってます。
でも肝心のモデル層が構造化プログラミングなんです。
SEさん、モデリングなんてしてないんです。
設計=DB設計と画面設計ぐらいな感じです。
DBはある程度正規化されいい感じなんですが、そこからJavaのオブジェクトモデルへの
マッピングがありません。
ビジネスロジックを実装するためだけのクラスではフィールドがグローバル変数のように
扱われ、メソッドはただの関数にすぎないんです。
画面設計もC/Sシステムのクライアントのようです。

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

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



25 :デフォルトの名無しさん:02/11/22 11:51
>>24
結局、そのプロジェクトは「VBでC/Sシステム開発してるのとあまり変わらない」
状態で進んでるんでしょうか?
DBからJavaオブジェクトモデルへのマッピングあたりの事例を自分は
あまり見てないもので、その部分がちゃんと出来てるならぜひ話を聞いてみたいんですが。

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

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

自分は底辺プログラマなんで影響力ないです。
もうだめぽ。。。


27 :デフォルトの名無しさん:02/11/29 15:06
通報しますた

28 :デフォルトの名無しさん:02/11/29 15:36
>>26

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

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

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


もちろん。少なくとも データ取得方法くらいは抽象化しておくべきだと思う。
テスト用オブジェクト作ってHTML の表示のテストやってみる、とか
そういうことすらできない、HTML とデータベースのベッタリくっ付いたコードとなると、
それはかなりやる気を無くすかもしれない。(けど、それも、1週間で作れるくらいの、
使い捨てプログラムなら、アリだとは思う)


29 :デフォルトの名無しさん:02/12/01 18:41
俺の経験から言わせてもらうと、
RDBから、本当にOO的な(継承やら多態やら複雑な関連やらいろいろ使う)
個々のJavaのオブジェクトとのマッピングはほとんど
不可能なんじゃないかと思います。
もう少し粒度を大きくして、コンポーネントの単位でものを考えた方が良いと思います。

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



30 :デフォルトの名無しさん:02/12/02 02:35
>>29
早い話が、ラッパーってことね。ま、普通だね。

31 :29:02/12/02 03:57
>>30
ラッパーって、どういう意味で言っている?

32 :デフォルトの名無しさん:02/12/02 08:50
Facadeパターン?

33 :デフォルトの名無しさん:02/12/03 03:00
>>28
まあ程度の問題だけど、
画面の都合などをモデルに持ち込むのは、
やっぱり「汚れた」と感じるのであまり好きではないです。

そういう場合その画面専用のモデル(とそのコントローラ)を
作るってのが自分周囲での流行です。

11 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)