ふだんROMのたんげ＠堅田電機です。
> ラムはGUIを持っており，GUIはコントロールをペタペタ貼り付けるタイプの
> 開発で作ったものなのでmain()にイベントハンドラが沢山あります．
> 私は，メソッドがだらだらとたくさんあるクラスはあまり好きではありま
> せん．うまく責務分担できないものかと悩んでいます．
恐らく、Widegetの処理をダイアログに記述するスタイルのイベント
ドリブンツールに対して、不満を持っておられるのだと思うのですが、
いかがでしょうか？
皆さんがおっしゃる通り、Widegetの汎用性を考慮してダイアログで
調停処理を行うのがデザインパターンの慣わしですね。
「状況によりけり、一概に云えない」のですが、私なら。。。
・直接ダイアログにWidegetを配置しない。すなわち、ユーザビリティーを
考慮して乗せるWidegetを分類し、親を複数の配置マネージャに分ける。
配置マネージャをダイアログに配置して、Widgetの親に対するメッ
セージはその配置マネージャにて処理する。
・そもそも内部状態の変更/更新が頻繁な場合や、より高いユーザビリ
ティーを追求する場合は、既製のWidegetなど使[わ|え]ない。さっさとあき
らめて新規の開発を踏み切り、スケジュールと予定工数を組みなおす。
といったところでしょうか。。。
若干話は変わりますが
> 概念モデルから入るドメイン層のオブジェクトは，責務分担がとてもわか
> りやすいのですが，
とのことですが、「ドメイン層のオブジェクト」と「関係データベース」の
マッピングで、私はいつも苦労しています。データベースは、
Table1 v.s. Table2 ですけど。。。オブジェクトは、 Oblect1 -> Object2
なところが悩ましい（意味不明）。
----- Original Message -----
From: "Tacchang" <***********@***.*****.***>
To: <***********@***.***.*******.**.**>
Sent: Sunday, December 05, 2004 11:22 PM
Subject: [oosquare-ml:04433] GUI 操作のためにだらだら長い Main は嫌だ（求
助）
> みなさん，こんにちは
> Tacchangです。
>
> 今，昔のソースコードを眺めていて感じた疑問があるのですが，納得できる回
> 答が思い浮かばない（問題解決したことがない／できない）ので，もし，同様の
> 問題解決をしたことがある方は，アドバイスお願いします．
>
> 【私がぶつかっている壁】
>
> 手元にBorland C++ Builderで作ったプログラムがあります．そのプログ
> ラムはGUIを持っており，GUIはコントロールをペタペタ貼り付けるタイプの
> 開発で作ったものなのでmain()にイベントハンドラが沢山あります．
> 私は，メソッドがだらだらとたくさんあるクラスはあまり好きではありま
> せん．うまく責務分担できないものかと悩んでいます．
>
> 【私の問題解決過程に浮かび上がった疑問】
>
> 責務分担する必要がある，という前提で・・・
>
> １．巨大なGUIクラスの分割はどうすればよいでしょうか？
> 概念モデルから入るドメイン層のオブジェクトは，責務分担がとてもわか
> りやすいのですが，プレゼンテーション層（GUI)層は分割基準がよくわかり
> ません．OOP達人の場合はどういう風に責務分担されているのでしょうか？
> RADツールを使うことを考えると，main()が持つ責務（メソッド）をGUIク
> ラスの責務へ移せばいいかな？（コンポーネント化）と想像していますが，
> これは問題解決の方向としていかがでしょう？
>
> ２．どういう風にダイアグラムを書くの？
> プレゼンテーション層とアプリケーション層／ドメイン層はどうやってモ
> デリング上区別されるのだろう？ダイアグラムが別？パッケージが別？ステ
> レオタイプ？はたまたこれ以外？
>
> ３．GUI層のモデリングってどうやるの？
> そもそもプレゼンテーション（GUI）層のモデリングって見たことがあり
> ません．OOA達人はどうやってモデリングされているんでしょうか？
> MainForm（ベースとなるウィンドウ）にコントロール（コンポーネント）
> を集約（◇）でぶら下げるだけならば，すでに画面仕様書が存在するのでしょ
> うからUMLで記述したモデルは要らない気がします．
>
> ４．GUIのリファクタリングってパターン化されているのかな？
> GUIのリファクタリング・パターンがあれば，その文献やURLを教えていた
> だけないでしょうか．
>
> 以上
>
> --
> Tacchang
>