ぼうメモ帳

2007-01-06

netbeans

| netbeans - ぼうメモ帳 を含むブックマーク

いま、netbeansプログラムを書いているんだけど、2kぐらい書いた感想だけど、ソースコード編集機能は断然eclipseの方が上だ。PCの性能の問題もあるのかもしれないが、まず第一に、コード補完で選択していないようなものが勝手に補完されて、コード保管になっていなかったり、次に、そもそもコード保管していないのに、勝手コード保管してローカル変数brをbreakに勝手に書き換えたり、デフォルトコメントテンプレートが弱かったり、とイライラすることだらけ。

でも、eclipseに戻ると負け組みな気分が…

nowokaynowokay 2007/01/08 07:53 省略記法は、オプションの「エディタ > コードテンプレート」のところで編集できますよ。

susumususumu 2007/01/10 22:41 ありがとうございます。br + スペースでbreakになるって、省略記法の機能だったんですね。てっきり、コード補完の誤補完だと思ってました。

2007-01-03

GUIアプリケーションの開発スタイルに関して思いついたこと

| GUIアプリケーションの開発スタイルに関して思いついたこと - ぼうメモ帳 を含むブックマーク

GUIアプリデザインパターンとして、MVCパターン存在する*1GUI自動生成について色々考えたときに、思いついたことを適当メモしてみた。

Modelから設計するか、Viewから設計するか

MVCパターンの観点からGUIアプリの設計を見てみると、大きくViewから設計に入る方法と、Modelから設計に入る方法の二つがありそう。

正直、どちらも完全に分けられるものじゃない。

Viewから設計する方法は、Viewを作りながらModelの片鱗を少しずつ構築していく方法。まず画面を作成し、ボタンに対するアクションを少しずつ作りこんでいくというもの。開発のイメージとしては、ViewGUIビルダでサクッと作成し、Viewに表示するデータの操作ロジックの作成が開発の中心となる。

メリットは以下のとおり。

  1. 開発が早いこと
  2. 規模が小さい場合、コード量が少なくできること
  3. GUIライブラリの機能をそれほど知らなくても開発できること
  4. GUIビルダ的なものでの開発が容易なこと

デメリットは以下のとおり。

  1. 規模が大きくなると、スパゲティコードに陥りやすいこと
  2. 規模が大きくなると、開発規模が極端に増え始めること
  3. 画面数が多くなると、Viewに表示している値の統一性を維持するのが大変になること
  4. View内に、データビジネスロジックUIコントローラの機能が集まりやすく、画面クラスが肥大化しやすいこと

Modelから設計する方法は、Modelを作りながらViewの片鱗を少しずつ構築していく方法。まず、Modelとしてデータデータに対する操作を決定し、各Modelに対してViewを作りこんでいくというもの。基本的には、Modelをサクッと作成し、Modelの状態を表示するView更新ロジックを作成するのが開発の中心になる。

メリットは以下のとおり。

  1. 開発が遅い
  2. 規模が大きくなっても、開発規模がそれほど大きくならない
  3. 画面数が多くても、値の統一性、操作の統一性を維持するのが容易
  4. Model/View/Controllerの分離が容易(もともと分離されやすいため)

デメリットは以下のとおり。

  1. GUIライブラリの機能を把握しておく必要がある
  2. 規模が大きくなると、スパゲティ参照に陥りやすい
  3. 規模が小さくても、コード量が一定以下に減らない
  4. GUIビルダとの相性があまり良くない

GUIアプリの自動生成を考えたとき、View先行型よりも、Model先行型の方が自動化が容易。これは、ビジネスロジック開発者が決定するものだが、業務APにおいて、多くのViewは、DBCRUD操作が主体であり、その部分のView定型であり、自動化が容易であるため。ただし、自動化する以上、似たような画面になることは防げない。

2006-11-26

目覚まし時計 開発記(1)

| 目覚まし時計 開発記(1) - ぼうメモ帳 を含むブックマーク

とりあえず、昨日、今日、がんばって作った設計書(作成中:2006年11月26日版)をアップ。

まだ作成中だし、詳細はPDF勝手に読めってことで、内容としては、こんな感じ。

他のはまだ空っぽのテーブル。

以上、業務連絡完了。

270563