- - PR -
フォーム間の値渡し（DataSet）
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2006-09-11 15:30
Open - Closed Principle
でGoogle検索してみて、ひっかかる記事を見てみるといいかもしれません | ||||||||
|
投稿日時: 2006-09-11 17:34
objectです。
>koaraさん(※追加) >自分のソースがまったくその通りで行儀の悪いプログラムだと気付きました。 確認しますが、この場合、何故 「行儀の悪い＝良くない」プログラム と考えたのでしょうか？ #まさか「甕星さんがそう書いているから」という事は無いですよね？ >標準モジュールは汎用処理を書く以外は使ったことが無く、 >ほぼWindowsFormsに処理を書いています。 「標準モジュール」は、 「.NET」に於いて、どの様な「位置付け」になる と考えておられるのでしょうか？ また、その説明が自分の言葉で出来ますか？ >どのように設計したら良いか一度基礎から勉強したいと思います、 >・どういう設計をしたら良いかが分かる良書（サンプルが載っているもの) >・良いサンプルで意図を読み取れというものでも結構です。 >勉強するのに良い書籍などありましたら紹介して頂けませんか。 「どういう設計をしたら良いか」は、基本的には、「対象依存」です。 「何処か」に「正解」が「存在している」訳ではありません。 ある意味で、 「どのように設計したら良いか」 は、設計対象を別にすると 「koaraさんの考え方そのもの」 だとも言えるのではないでしょうか？ それを 「他の何かに全的に依存しよう」 とするのは、 「少し問題がある」 様な気が若干します。 それに、例え 「何かを真似て、基礎が出来た」 としても、新しいもの(概念)が出て来ると、当然の事として、 「全てに変化と影響を及ぼす」 と思います。 「その変化に独力で適切に対応出来るかどうか」も問題 だと私は思いますよ？ >具体的に自分の分かっていない点は >・どこに何を書くべきか曖昧です。 >(WindowsForms,モジュール,モジュールの切り分け、モジュールの名前の付け方) >・プログラムをどう組み立てたらよいかセオリーを知りません。 >(なぜそうしなければいけないか、又はそうした方がいいのかを知りたいです。) ここでも、 「書き方・組み立て方」 が一意に決まるものではありません。 「変更を最も考慮した設計」、「分かり易さに最も焦点を当てた設計」等の 「設計方針」 また、 「プラットフォームの構造」等 に依存して、かなりの違いが生じる筈です。 以上の観点から、私は 先ず、一番に 「VB」を止める(忘れる)事 そして、変わりに、 「C#」 の使用を開始する。 #「.NET」の意味的な理解をC#をベースにシッカリやる。 #同時に、もしC系の言語をご存知なければ、 #C系の歴史と「C++」をベースとした勉強を気長に始める。 蛇足ですが、 「自分自身で自分が向上しようとするプロセス」 は 「自分自身で自分が書いたソフトを向上させようとするプロセス」 と密接な関係がある様に私には思えます。 #参考になれば幸いです。 [ メッセージ編集済み 編集者: object 編集日時 2006-09-11 17:36 ] | ||||||||
|
投稿日時: 2006-09-11 18:37
koaraです。
kazukiさん、ありがとうございます。 教えていたサイト、参考にさせていただきます。 | ||||||||
|
投稿日時: 2006-11-30 18:44
やっとobject様の仰られていることがわかりました。
遅くなり申し訳ありません。 要するに、 『設計がどうの言っているけど、そもそも設計方針が明確でないのではないか？』 という指摘をして下さっていたのですね。 私は、設計思想にマッチしているのが良いソースだと思います。 裏を返せば、ソースから設計意図がはっきり読み取れるということでしょう。 設計に『正解』がないことは分かりますが、 良い設計ができるひとが見て一様に『完成度が高いな』と思うソース というのは存在すると思います。 それを、なぜこれを良い設計だと言うのだろうと 考えることは設計方針とソースが噛み合わない私にとって この上ない勉強になりそうです。 具体的には ・どういった設計思想で書いたのか？ ・設計思想に対してどう設計しているか？ ・モジュールの結びつきの強さのさじ加減 などです。 その上でデザインパターンやテクニックを知っていれば、 『なるほど、こういう風に落とし込むんだな。』 となると思います。 ある程度、C++, C#知識の部分は補強したつもりです。 ソースも試行錯誤しながら書いてきました。 復習という意味で、 良いソースを見て自分とどこが違うかを見たいです。 『分かり易さを一番に考慮している』 で、変更が容易に想像できるような場合は 『変更に強い』 というのが設計方針です。 前提とする知識は、 そこそこ高くても構いません。 なにか、勉強になるお手本はないでしょうか？ .Netにおいて、 標準モジュールの位置付けは すべてのメンバが暗黙的にSharedキーワード付きで宣言されているため、 インスタンス化したオブジェクトはプロパティ、メソッドを共有する。 だが、コンストラクタを持たないという性質も持つため実体はひとつである。 クラス〃で成り立っている.Net上でクラスらしい部分を無くした モジュールが作れるということでしょうか？ | ||||||||
|
投稿日時: 2006-11-30 22:32
こういうときは、オープンソース。 _________________ | ||||||||
|
投稿日時: 2006-12-01 06:03
Jittaさん
アドバイスありがとうございます。
よく知られたものがいいだろうと考えたら、 Firefoxを思いつきました。 『mozilla - 開発センター』というサイトがあり、 設計方針(コーディングルール)などが事細かに書かれていました。
オープンソースというのは、選ばれたひとで書かれており もう少し泥臭いものをイメージしていました。 これもいろいろだとは思いますが。 このように明確にルールがあってその上で成り立っているとは 驚きました。 これだけしっかり設計方針が決まっているからこそ、 誰でも参加できるんですね。 『Mozilla のコードを書くには』というリンクを見つけたときに そういうことか。、と感じました。 まずはこのサイトを良く見て、その後でソースを読んでみます。 参考になりました、ありがとうございます。 | ||||||||
|
投稿日時: 2006-12-01 09:23
誤解して頂きたくないので反応しますが、普通は逆でしょう。 きょうび、「トリッキーな実装をする人 == 有能」 だなんて式は成り立ちませんから。 _________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 | ||||||||
|
投稿日時: 2006-12-01 12:41
objectです。
>koaraさん >やっとobject様の仰られていることがわかりました。 >遅くなり申し訳ありません。 いいえ、今迄努力されてんですね。 感心しました。 そして、私が前のレスを付けたのは、少しでも共感・実践して頂く事でしたから、 書いて良かったと思っています。 >要するに、 >『設計がどうの言っているけど、そもそも設計方針が明確でないのではないか？』 >という指摘をして下さっていたのですね。 >………………………………………………………………… >その上でデザインパターンやテクニックを知っていれば、 >『なるほど、こういう風に落とし込むんだな。』 >となると思います。 そうですね。 設計には必ず対象があります。 設計をするからには、その対象に対する、自分の設計スタンスが大切だと思います。 「対象が、抽象化とその観点に応じてどの様な関係を持っているのか」 これが一番重要だと私は思います。 #それは、「分析とその過程」によって支えられている部分もあると私は思いますが。 #koaraさんの場合、設計(手段)が全面に出過ぎて、対象に対する意識が薄い様に感じました。 >ある程度、C++, C#知識の部分は補強したつもりです。 >ソースも試行錯誤しながら書いてきました。 行間に少しkoaraさんの努力と自信が垣間見える気がします。 >前提とする知識は、 >そこそこ高くても構いません。 > >なにか、勉強になるお手本はないでしょうか？ 一般的な話ですが、 設計は、ソフトウエア空間上でのプロセスです。 従って、設計によって、本来の対象が持っている構造(関係)が損なわれるのは避けなければいけません。 それでも、デザインパターンは、設計経験を整理する指針としても、とても良いものだと思います。 そういう意味で、ソースでは無いですが、私が先ず思い浮かぶのは、 「デザインパターン」(ソフトバンク) 第２章の事例：ドキュメントエディタの設計 http://www.amazon.co.jp/exec/obidos/ASIN/4797311126/ でしょうか？ #ドメイン自体が「ドキュメントエディタ」というソフトウエア空間の対象ですが、 #デザインの勉強には良いと思います。 #私は、初版を読んだのですが、初めて読んだ時は少し衝撃を受けた事を思い出します。 #個々のデザインパターンを覚えて「当てはめ主義」に陥るよりは遙かに良いと思います。 #もう既に、ご存じだったら、ご免なさい。 それから、ソースレベルでのコンポーネントその他が見られるという意味で 「The Code Project」 http://www.codeproject.com/ はどうでしょうか？ #色んなソースを見るのは、良いソースだけを見るより、勉強になる事は多いと思います。 >.Netにおいて、 >標準モジュールの位置付けは >すべてのメンバが暗黙的にSharedキーワード付きで宣言されているため、 >インスタンス化したオブジェクトはプロパティ、メソッドを共有する。 >だが、コンストラクタを持たないという性質も持つため実体はひとつである。 >クラス〃で成り立っている.Net上でクラスらしい部分を無くした >モジュールが作れるということでしょうか？ ん〜、「標準モジュール」も結局は「クラスを特殊化」して作っている訳です。 もし問題とするなら、上記の様な「標準モジュール」の持つ特性を、 VBの利用者が「何所まで理解して使っているか」ではないでしょうか？ 私は、「標準モジュール」を VB6からの流れで押し付けられた「正体不明の実体」としてでは無く、 クラスが持つ「可能性」と、 それによって実現された「その正体」を明確に理解しておく事 が大切なんだと思います。 そうすれば、最早「標準モジュール」に囚われる事は無くなるのでは無いでしょうか？ それから、最後に 発言の内容を見る限り、 koaraさんは自分を客観的に見ようとする人 だと思いました。 それで、敢えて書きますが、自分が進歩する上で大切な事は、 「シッカリ間違える事」 だと思います。 自分の考えをハッキリさせ(間違いをあやふやにせず)、その上で シッカリとした試行錯誤をし、経験を積んで下さい。 最初から完全なソースを書こうとすると大変です。 考え方(ポリシー)がベースにしっかりあれば、 それに応じて自然に「自分の書き方」は生まれて来るのではないでしょうか？ 私はそう思います。 koaraさんの健闘を祈ります。 ※健闘に修正 [ メッセージ編集済み 編集者: object 編集日時 2006-12-01 12:53 ] | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。