- - PR -
JavaGUIアプリの作り方
1|2|3
次のページへ»
投稿者 | 投稿内容 | ||||||||
---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-01-17 14:49
こんにちは。
現在、勉強の為にJavaのGUIアプリケーションを「仲間と2人で」作成しています。 (そのGUIアプリケーションは多機能1画面構成です)←は仕様 ECLIPSEとCVSを使っていて、コミット時に競合が起こる事態が多くあります。 私は(例えば)Pane毎にBeans化して出来るだけ競合を 避けるような事を提案したのですが、もう1人の開発メンバーは 出来うる限りそういった事はせずに、1画面は1ファイル(*.java) で作るべき(競合の為にCVSがある・競合ありきの考え)だと言います。 どちらがいいのでしょうか? 漠然とした質問で申し訳ないのですが、ヒントとなるご意見など 頂ければと思います...。 開発環境 ----------------------- Windows2000&XP ECLIPSE3.0.1 CVS使用 VisualEditor ----------------------- | ||||||||
|
投稿日時: 2005-01-17 21:04
あなた画面(ビュー)作る人、わたし内部処理(モデル、コントローラ)作る人でどうでしょう?
インターフェイスを決めてやれば、後は平行して作業できますよね。 まさかすべて1つのjavaファイルでやるつもりじゃないでしょ? | ||||||||
|
投稿日時: 2005-01-18 12:01
レスありがとうございます。
「MVCで分割する」とご意見は私の質問からは当然だと思います。 質問の説明が不足していたかもしれません。 私が作ろうとしている画面は多機能1画面構成なのです。 どういったものかと申しますと、(簡単に言いますと) 「ボタンを押すとボタンの色が変わるPaneA」 「ボタンを押すと背景の色が変わるPaneB」 「ボタンを押すとボタンが移動するPaneC」 ・・・ が1つのFrame上にある画面で、さらに PaneAでボタンを押すと違うPaneCのボタンが 押された事になる。といった仕様もあるのです。 こういった画面にMVCを当てはめる意味は無いと思います。 (ましてやMODELなど無い) こういった画面でもMVCを実現すべきであるならば、 やり方を是非教えてください。(嫌味ではなく...) 私は、上記画面を作成するのに複数人で開発する場合には Pane毎にJavaBeans化して、独立性を高め、同じJavaファイル を修正してしまう事を避けるべきだと思ったのです。 (コンポーネント指向なのでしょうか?) この考え方が間違っているならば是非教えてほしいのです。 宜しくお願い致します。 | ||||||||
|
投稿日時: 2005-01-18 12:15
お世話になります。
私個人的には「画面.javaだけ」でなく「部品.javaがいっぱい」派です。 と、いうより「画面.javaだけ」派の人を見たことありません(^^;;; | ||||||||
|
投稿日時: 2005-01-18 12:39
私はレイアウトとイベント委譲を行うスーパークラスと実際のロジックを実装するサブクラスのふたつに分けて作成しています。(Visual Studio 2005 のスケルトンと同じような構成) また、GUI コンポーネントは アクセサを用意せずに public にしてしまっています。
メモ帳を作るならこんな感じ。
GUI が絡みの部分は VB っぽさを出したほうが、組みやすいと思っています。命名も Java コーディング標準を無視して アンスコ使ってますし。 | ||||||||
|
投稿日時: 2005-01-18 12:47
unibon です。こんにちわ。
プログラムを複数人で開発するのは、たんに人間の都合であり、そのような人間の都合によりなんらかの手段で分割されるのは、できあがるべきプログラムの理想から言えば、無駄に細分化されていることになると思います。プログラムの構造をよりよいものに追及した結果、分割したほうが良く、それがたまたま複数人開発に都合が良い、のならば分割することに無駄なコストはかかりませんが、そういう必然性がないのに人間の都合で分割するのは、やはり無駄だと思います。 よく目に(耳に)する例としては、Web アプリケーションで、登録画面と参照画面は別々のモジュールにしてそれぞれ別々の人が開発しているけど、やっていることは似ているし、両者間のメッセージ量が多く、情報のやりとりするために画面Aから画面Bに遷移するために HTTP の redirect を挟むとか、そういうのは無駄なコストの典型のような気がします。 そういう観点から言えば、私も CVS などを使ったほうが良い(分割しないほうが良い)と思います。ただ、開発のしやすさとの兼ね合いもあるでしょう。Pane ごとに分けるのならいいんじゃないでしょうか。ただ、もしも Pane 間でお互いにメッセージを頻繁にやりとりするのならば、それはやはり分割しすぎでオーバーヘッドのデメリットのほうが目立ってくるかもしれません。 | ||||||||
|
投稿日時: 2005-01-18 13:56
話がだんだん外れていってるような気がしてきましたが・・・
1.まず、何を勉強(してる/したい)のでしょうか? tosiroさん個人でなくて、お二方でという意味です。 ・Javaの文法? ・GUIアプリのコーディング? ・開発についての一連の工程を経験したい? ・競合をしないためのデザイン? 目的から外れないように些細な問題は無視することをオススメします。 現在、競合をしないための云々という話に流れていってるようですが・・・ それが聞きたかったこと?それが勉強したかったこと? まぁ競合の解消に手間がかかって本来の目的の障害になるならば、 ちゃんと説得できるんじゃないですか。 2.メンテナンス性 何を勉強してるか、わからないので無視してもいいところですが、 実際の開発ならばメンテナンス性の悪い設計は、イタイです。 私は「競合の発生しやすい設計」=「良くない設計」と考えます。
# 確かに無駄な細分化は「無駄」です(変な日本語) # 登録と参照を同じ人が開発したほうが効率が良いと思います。 # 1つのファイルに複数の人が同時に修正するっていうのはクラス分割が # 上手くいっていないからだと思います。 # # 基本的に1つのクラスって一人で担当するものだと思ってるのですが、 # 最近は、そうでもないのでしょうか? # # XPほとんど知らないので勘違いしてるかもしれませんが、 #「集団的コード所有」ってことで担当なんて概念無いんでしょうか。 | ||||||||
|
投稿日時: 2005-01-18 14:07
(1ファイル(*.java)=1クラスを前提として書きます)
適切なクラス設計(クラスの単位、機能ごとに分けるなど)と、担当者の割り当ての話は別かと思います。 どんな画面かわかりませんが、1画面=1クラスっていうのはステップ数っていうのはかなり巨大でごちゃごちゃしたソースになりませんか? 適当にクラスを分けて、適当に担当者を分ければあまり競合しなくなると思います。(多少の競合はEclipse+CVSで問題ないかと。) どうしても競合部分が多ければ開発時期をずらせばいいのではないでしょうか? |
1|2|3
次のページへ»