- - PR -
JavaGUIアプリの作り方
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-01-18 15:15
「私ならこうするかなぁ」程度の意見。適当に聞き流していただいてかまいません。
# ほかの人の設計も聞いてみたいので「まずは私から」という意味もあります(^_^; 「1画面(1フレーム ?)中に複数の pane がある」「pane にはいろいろな GUI パーツが載っている」「それぞれの pane 内で完結する操作、連携する操作が混在する」のでしたら、 View ・親フレームクラス ・各 pane クラス (必要に応じてさらに内部パネルクラス) Controller ・各パーツ類のアクションリスナ(*) Model ・(言及されてないけど)何らかの保持データ類。テキストエリアの内容とか必要に応じて管理するクラス。 とかにしますかねぇ。 *:「PaneA のボタンが押されたら PaneB の状態を変更する」ときは、ボタンのリスナが PaneB 関連の Model クラスにアクセス。その Model クラスから PaneB に変更を通知するようにする。 | ||||||||
|
投稿日時: 2005-01-18 20:52
皆さん、ご意見頂きありがとうございます。
tak3 よりまとめて頂いたので流用させていただきます。
１に関してはすべてです。 Webアプリは仕事で何度か開発しているのですが、 GUIアプリはまったく触ったことがなかったので、 上で書かれているものすべて、もしくは未知の部分 も含めてそれ以上学べるだけ学べればと考えています。 ２に関しては特に気にしていません。 unibon よりご意見
おっしゃる通りだと思います。 ただ、私どもは（CVSの使用を前提としているように）チーム開発の勉強も 視野に入れています。当然、チーム開発に分割は必然と思っています。 未記入さんとびしばしさんのご意見の 「VIEWだけのクラスを作成して、それを継承するCONTROLクラスを用意する」 ような考え方は非常に参考になりました。 （既に実践しています） びしばしさんの書かれた方法を参考に、Pane毎に 分けていこうかと思います。 質問して皆さんからご意見を頂いて気付いたのですが、 結局のところ、私は皆さんのGUI作成（チーム開発での）の 「ノウハウ」を聞いていたのだと思います。 貴重なご意見（ノウハウ）を聞けてありがたく思います。 また贅沢を言うなら、他にGUI開発で実現している手法などが 他にあるのでしたら、お教えいただければと思います。 | ||||||||
|
投稿日時: 2005-01-18 21:28
unibon です。こんにちわ。
私は Java で多少は GUI を持ったアプリケーションを作ったことはあるのですが、どんなものでも MVC が根底にないと、ひとりでも作りにくいし、チーム開発では一層そうだと思います。またできあがったアプリケーションの操作性も統一がなく使いづらいものになります。(なお、ここで言う MVC とは、特定のフレームワークにおける MVC ではなく、プログラム一般における広い意味での MVC を指します。) とは言え、
のような機能をもったものはさすがに作ったことがなく、想像がつかないので、こういうアプリケーションには当てはまらないかもしれませんが。 | ||||||||
|
投稿日時: 2005-01-18 22:37
お世話様です。tosiroです。
unibon さんより
知識が足りなくて申し訳ないのですが、狭義のMVC 広義のMVCとは何が違うのでしょうか？ 私が知っているのは、よくWeb上で解説サイトで見かける WebアプリのM(マスタなど)V(JSP)C(Servlet)です。 | ||||||||
|
投稿日時: 2005-01-18 23:03
tosiroです。
余談ですが... 私の考えですが、近いうちにJavaGUIが本格的に 利用されてくると思っています。 現時点では動作が遅く、書籍・Webサイトでの解説も 多いとは言えず、Javaで作られたアプリ・ソフトを 自分が利用する場面はほとんどありません。 （ORACLEインストーラくらいですかね？） ですが... 「2008年までにPCの性能を10倍にするとIntelが公約！」 などPCの性能は上がりJavaGUIアプリが日の目を浴びる ようになると思っています。 さらに、私は基幹システムなどをWebアプリで作ることが いいことだとは思っていません。いずれ衰退すると考えています。 なんて勝手な事を考えていて今回のJavaGUIのお勉強に踏み切りました。 以上、余談でした。 | ||||||||
|
投稿日時: 2005-01-19 01:22
程度の低い話になりますが、、、ｗ
私の経験上、プライベートな開発（と呼べるほどのものでもないですが）の場合、 「二人で開発」って結構難儀な事になるんですよね。。。 ぶっちゃければ「同一ソースを共同で書き上げる」「分割して個々でソースを書く」 のどちらかになるわけです。 前者の場合、重要になるのは二人の能力差でして、差が大きいと「破壊作業」「修復作業」 の応酬がコミット毎に起り得るわけです。 そうなると、実作業よりも相手に「理解してもらう様、説き伏せる」という作業の方に 労力の大半が注がれます。上下関係が明確なら命令直下で済みますが、そうでない場合 相手のプライドを傷つけない配慮も必要になります。要するに「疲れるプロジェクト」。 後者の場合、上手く分割できれば良いのですが（これまた互いのプライド上、片方だけ が主幹部分を一手にとは行き辛い）結局は突合せの作業が時折必要になるわけで、 その都度相手の進捗度合いが問題になったりします。 「さあ、自分の担当は大凡書き上げテストも通過したぞ！」と勇んで結合をしようにも、 CVSリポジトリを覗いてみると相手のパートの進捗はクラス宣言のみだったり、、、ｗ ここでも相手の心証を配慮しながら催促かけるといった作業が必要になってきます。 この場合は「イライラするプロジェクト」という事になるのでしょうかね。 説明、催促、共に存在し得ないプロジェクトなど存在はしないのでしょうが、下手に 相手が「自分に自信がある（と思い込んでいる）」タイプとの共同作業は難しいです。 （そしてプログラマの大半は多かれ少なかれ、その要素を含んでいます） 一番の解決策は「もう一人入れる事」ではないかと思います。 どのような方法論で進めても意見の衝突は避けられませんが、最終的な決定を下す段に 多数決を求められない（二人じゃ無理）プロジェクトってのは最悪です。 今回の投稿にしても、もう一人いれば多数決で「決定」できていたのではないでしょうか。 恐らく、ここで得た情報を元に相手に理解を求めるのでしょうが果たして上手く行くもの かどうか、、、技術者三人なら理が通っている方が勝つものですが、二人ではねぇ。。。 どんな手法よりも私なら「もう一人入れる事」をお奨めします。 | ||||||||
|
投稿日時: 2005-01-19 09:07
takamaroさん こんにちわ
確かに...。 しかし幸いなことに私ともう一人は「なんで？こーじゃねぇの？ちげぇの？」 なんて言い合っても5分後には納得しあっているか、互いに調べなおす 努力をし始めるタイプです。 でも、少数でさらに偶数人数で開発していると意見が半分になって 多数決で決定しない（民主主義的解決出来ない）事があったとき 困りますよね。 | ||||||||
|
投稿日時: 2005-01-19 10:10
「余談」にちょっとコメントを。これも「余談」として適当に聞き流してください(こればっかりだな ^^ 。
私、3年半ほど前からお客様に JavaGUI アプリを提供してまして、「Windows、Linux、Mac(OS X以降) など、どの OS でも動いて便利」と評判を頂いてます。動作速度はその当時(Celeron 700MHz なノートPC)からあまり問題ではないですよ。 また、「.exe で起動するけれど大部分は Java」というアプリケーションも(一部方面では)多いです。 | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。