ネタと雑記と時々プログラミング
Halo3 にハマり中。アービターかわいいよ。あーびたん。
VB2005 では Form をインスタンス化しなくても、参照できるってホントですか... orz VB6 のように勝手にインスタンス化されて、参照できるみたいです。
VB6 からの互換性 (ユーザも含めた) とか、かなり意識しているようです。 VB2003 に C# オンリーだった機能を足す程度を待ち望んでいたので残念です。(^-^;)
C# と VB は完全に分かれちゃったんですね。 それはそれで良いですけど、これによって、Form をクラスだと意識しない方々が増えることを危惧しています。
投稿日時 : 2005年6月13日 10:54
つまり、 フォームに何でもかんでも詰め込むぞー... フォームのコントロール直接アクセスじゃー... と、"VB6 みたいに" されてしまいがちにならないか危惧しています。 VB6、今まで火消ししたのは、そんなソースばっかりだったもので... VB2002 が発売されて以来 (といっても、VB2003 からしかやっていませんが) VB すごく良くなってる! って思っていたのでちょっと残念です。
>つまり、 > フォームに何でもかんでも詰め込むぞー... > フォームのコントロール直接アクセスじゃー... >と、"VB6 みたいに" されてしまいがちにならないか危惧し>ています。 私は、ちゃんと啓蒙しないと間違いなくそうなると思ってます。 私も、現状そのようなプロジェクト（VB6）に携わっています。 見るも涙な状態です。 モジュールから、フォームのコントロールを直に操作したり、 フォームからＤＢと直接やり取りを行ったり。（まあ、プロジェクト規模を考えればそれでもいいかとは思ってます。） 社内のVB6のプロジェクトではもうそういう風にぎちぎちに固まっているのでしょうがないかと、諦めています。（郷に入れば・・・・） とはいえ、.NETになるのを機会に、コードを全体的に改善して保守しやすいようにしたいと考えていました。 しかーーし、今回のVB2005の独自化は、ますます一般的VBプログラマーにクラスなりの オブジェクト指向の概念を学習する機会を奪い取り、いろいろと勘違いさせそうな気がして心配してます。 ということもあって、社内的には、VB2005ではなくC#2.0にしようかなと、個人的に思っています。
まず、変化を嫌う人が多いのが主な理由だと思われます。 VB みたいに組もうとしてできないから、VB.NET はダメだとか、 Windows アプリケーションなのに、仕様が未だに COBOL っぽいとか。 新しいことをやるんですから、今まで通りにはいかんでしょ? って思うんですよね。 現状に拘るのならば、ずっと VB6 でもやっていれば良いと思います。
まさにその通りです・・・・(×_×;）
暗黙のインスタンス復活ですか。 ちょっと痛いなぁ。 いや、かなり痛いなぁ。 VB6時代から、暗黙のインスタンスは利用しないようにしていましたが・・・。
> VB6時代から、暗黙のインスタンスは利用しないようにしていましたが・・・。 同じくです。(^^) 柔軟すぎるのは良いことですが、業務ではちょっと... 自社だったら、私がきっちり誘導するので済む話ですが、 常駐先に行くとなると、かなり怖いですね。 今、まさしくそういったコードを修正しているわけですが。
VB6.0を体験してなかったからなんとも言えないけど、やっぱりクラスの概念とか覚えておかないとコーディングする上でホントぐちゃぐちゃになって言っちゃいそうですねぇ。 (´・ω・)最近WindowsFormの開発触ってなくて殆どWebやVSとは関係ない独自言語のIDE評価ですが。。。
> やっぱりクラスの概念とか覚えておかないと > コーディングする上でホントぐちゃぐちゃになって言っちゃいそうですねぇ。 さて、そんなナオキ君に問題です。 何故が理由で、ぐちゃぐちゃになると思いますか?
∑(゜△゜;)そう言う返しがあるとは… 勘違いしてたらすいません。 私的には単純にSystem.Windows.Formsからフォームが生成されたりボタンが生成されたりするからそう言うsystem構成覚えておかないと継承とかの概念を理解できないのかなって捕らえてましたよ。 (;´ρ｀)やっぱりズレテル？
えー、別に VB2005 で継承ができなくなったとか、 System.Windows.Forms.Form の派生クラスでないとか、 そういった話はしてませんよー。
(´Д｀;)ヾMSDNめくってきます。
ナオキ先生。 ぐちゃぐちゃになるといった点で問うてるのです。 では、テレビのリモコンがあったとします。 リモコンは必要な機能だけがボタンとして公開されてますよね? もし、内部だけで意識するものが直接触れたり、 利用者が見ることができたらどうなりますか?
じゃんぬ先生。 ｜ω・｀)またトンチンカンな事言ったらすいません。 VB6.0じゃインスタンスしなくても暗黙的にインスタンスされていたからImportsされてるかのように使用が可能で『メソッド名だけ書けばよかった。』階層等の考えもなしに呼び出し出来る結果としてどこの部分から呼び出しているかが良くわからない状況になる。 違うかなぁ？(；´ρ｀)
じゃんぬ先生！！！ つまり、 ＞フォームに何でもかんでも詰め込むぞー... ＞フォームのコントロール直接アクセスじゃー... ってやった結果他の動作に影響を与えるような可能性があるコードが出てきて、コードを辿るうちにスパゲッティ化してると言う事なのですね！？ クラスを意識する事によって利用する側から隠蔽化させて使う事が出来るようにってのがそう言う危なっかしいコードが無くなるってことでしょーか？
フォームはクラスという考えをすると、 フォーム内にある、TextBox などのコントロールはメンバです。 そのメンバが、勝手に触られたりしたら、ちょっと困る。 また、触る必要があるのであれば、プロパティやメソッドで公開した方が、「公開していることを明示化」できます。 これが大切だと思います。まずは (w つまり必要最小限のものを公開することによって、外から眺めた時に判りやすいのです。 ちなみに、このお話は暗黙のインスタンス化とは、ちょっと外れた話です。 ただ、VB6 ではそういうノリで触る人が多いのです。 VB.NET ではコントロールのアクセス修飾子の初期値が Friend のため、同じノリでやる人も多いですし... 暗黙のインスタンス化が復活するとなると、VB6 と全く同じ状態になるため、 より一層、そういうノリの人が増えてしまわないかということです。 次に、インスタンス化が何故必要なのか、 あるいは、暗黙ではなく明示化する必要があるのは何故か、考えてみましょう。(^^)
なるほど…今までフォームに貼り付けたTextBoxとかは独自の物、フォームは台紙ってイメージだったけど、確かにフォームからしたらメンバになりますよね。 ＞「公開していることを明示化」できます。 まさになるほどって感じで腑に落ちました(*'-') ＞ちなみに、このお話は暗黙のインスタンス化とは、ちょっと外れた話です。 ＞ただ、VB6 ではそういうノリで触る人が多いのです。 ＞VB.NET ではコントロールのアクセス修飾子の初期値が Friend のため、同じノリでやる人も多いですし... ＞暗黙のインスタンス化が復活するとなると、VB6 と全く同じ状態になるため、 ＞より一層、そういうノリの人が増えてしまわないかということです。 内緒な話会社の方々大量にVB6.0使ってるので.NETもしくは2005を使う時に是非其の所を注意して説明したいと思います('◇')ゞ ＞次に、インスタンス化が何故必要なのか、 ＞あるいは、暗黙ではなく明示化する必要があるのは何故か、考えてみましょう。(^^) インスタンス化が何故必要なのか… ClassをNewした時にコンストラクタを通る事で安全に使えるとか ですかね？？？初期値を設定してあげる為に必要とか…
わりこみ。 >インスタンス化が何故必要なのか… >ClassをNewした時にコンストラクタを通る事で安全に >使えるとかですかね？？？ >初期値を設定してあげる為に必要とか… ここでの場合コンストラクタはあまり関係ありません。（と思う） クラスとオブジェクトの違い。 計算機の中でのインスタンス化するとはどういう事か。 クラスによるカプセル化。 カプセル化と変数スコープの関係。 このあたりを考えてみましょう。 ただ確かにFormの場合クラスとオブジェクトの違いってつけにくいよね。ほぼ確実に1:1の関係になるし。
うーん。あくまで私が捉えてたイメージとしてですが、 クラスは設計図。オブジェクトは設計図から作られたもの。 コンストラクタが設計図を肉付けするために必要な素材と言うような感じで捉えてました。コンストラクタ無しでももちろん使えるクラスもありますが、中にはコンストラクタを通す事によって具体的な設定がされたりするものもありますよね？？？ #自分にとって誤った知識を修正して頂けるととても勉強になりますね。
> ただ確かにFormの場合クラスとオブジェクトの違いってつけにくいよね。 > ほぼ確実に1:1の関係になるし。 現実的にはそうですね。 "再利用可能な" 検索フォームなんかくらいですかね。 意味はなくても、必ず明示的にインスタンス化をするという意識をもたせることで、 クラスという概念を植え付け、コードの可読性、保守性に寄与すると考えています。 VB2003 をしっかりできている人間は C# もできるでしょうけど、 VB2005 でこうなった場合、どうなのかなと思います。
私もわりこみ。 > うーん。あくまで私が捉えてたイメージとしてですが、 > クラスは設計図。オブジェクトは設計図から作られたもの。 > コンストラクタが設計図を肉付けするために必要な素材と言うような感じで捉えてました。コンストラクタ無しでももちろん使えるクラスもありますが、中にはコンストラクタを通す事によって具体的な設定がされたりするものもありますよね？？？ コンストラクタって設計図の一部だと思うんですけど、どうでしょう？ というか、「コンストラクタが」ではなく、「コンストラクタで行われる初期化や具体的な設定」が設計図の一部かなと。 石坂さんの > ここでの場合コンストラクタはあまり関係ありません。（と思う） という言葉は、最初のじゃんぬさんの > 次に、インスタンス化が何故必要なのか、 > あるいは、暗黙ではなく明示化する必要があるのは何故か、考えてみましょう。(^^) この質問の主題を、「暗黙ではなく明示化する必要があるのは何故か」の部分だと捉えたから出てきた言葉だと思います。 そして、じゃんぬさんが用意していた答えは > 意味はなくても、必ず明示的にインスタンス化をするという意識をもたせることで、 > クラスという概念を植え付け、コードの可読性、保守性に寄与すると考えています。 この部分になるのではないかと。 以下は記事に対するコメント。 "暗黙のXXX"って、それが暗黙的に行われていることをよく知っている人でないと使ってほしくないですよね。 # RPG/400の暗黙のOPEN/CLOSEとか…ってだれも知らんて
ただ、暗黙的に行われていることを知っている方は、 多分、明示的にやっちゃうと思います。 なぜなら、 誤 解 さ れ た く な い か ら !! も、理由のひとつ (w
まさしくおっしゃる通りｗ
そうですね。 明示的な実装は重要ですね。 "暗黙のXXX"を知らずにそれに頼っている人って 結局、動作原理無視で動けばいいやなコードを 量産してそうですね・・・ あと、VB6ユーザーでVS2003を通過してない人って 経験上、ｲﾝｽﾀﾝｽ化って何、ヒープって何 な人が多いですね・・・ やっぱ、動作原理って大事だということで、 こんな人には、Essential .NET や プログラミング .NET Framework などの書籍を 紹介してます。
> やっぱ、動作原理って大事だということで、 > こんな人には、Essential .NET や そういった方では、Essentialはとても読めませんよｗ 多分、読み始めて5分で寝ちゃうんじゃないかな？ 構造化言語すらできないまま、ここまで来てる人（いわゆる悪い意味でのコボラー）が多いと思うんですよ。 まずは構造化言語から理解して頂かないとｗ 言い過ぎかなーとは思うんですが、実際問題そうだと思うんですよ。
構造化だけ出来ればええよ。 OOなんてしなくても。。。orz (^^;;;
厳密な意味で言ってますよね? > 中さん もし完全否定であれば、そういうわけにもいかんでしょー。 C# や Java は、最低限の OO しなきゃ組めないんだからー。
いや、OOより構造体を見つめなおせって意味
構造体? struct? (w
構造体って・・・orz 構造化ね (^^;
インスタンス萌え～ Dim a As Integer = New Integer Dim s As String = New String("Hello") ＃さすがに、こんな書き方してる人はみたことない(^^;
あー、そっかぁ。 データ型については、おとがめなしになってるわね。 だーけど、ちょっとデータ型は例外な気がする。
>いや、OOより構造体を見つめなおせって意味 賛成ですね。 構造化をしっかりやっていくと案外OOPになってたりしますしね。 逆に構造化をすっ飛ばしてOOPなんてありえないですしね。 >> やっぱ、動作原理って大事だということで、 >> こんな人には、Essential .NET や >そういった方では、Essentialはとても読めませんよｗ >多分、読み始めて5分で寝ちゃうんじゃないかな？ 確かにそうですね。ハードル高かったかな（反省） 今後は、「なぜオブジェクト指向で作るのか」あたりを薦めるほうがいいですかね。
いや、構造化ですよ(^^ 進化の歴史を理解させないと、COBOLでいいという考えのもと、COBOL風のソースができます。
>いや、構造化ですよ(^^ >進化の歴史を理解させないと、COBOLでいいという考えのも>と、COBOL風のソースができます。 そうですね(^^ OOPを毛嫌いする人って構造化自体ができてない人が多いような気がします。 あと、COBOL風のクラスってある意味恐怖ですね・・・これでもかってくらい１メソッド に処理詰め込んだり、いろんなものに連番を振りたがります。 社内のVBのプロジェクトもそうなっててかなりイヤーな感じです。
＞kara虎さん (´Д｀;)ヾ日本語理解できてませんでした。 質問に対する答えの導きありがとうございます。 とりあえず構造化プログラミングもっと勉強しなきゃ！！！
レスの伸びが凄くてビックリしました（午前中自分が投稿した時20以下だったから。）
>進化の歴史を理解させないと、COBOLでいいという考えのも>と、COBOL風のソースができます。 ソフトウェア史、あるいはシステム開発史的な感覚とか理解はとにかく必要だと思います。新しい技術の登場には必然性があるわけで、その必然性を理解するためにも歴史は学ばないといけませんし、なにやら新しい技術として登場したものも、別の形でいつか通ってきた道だと言うことも発見でき、バズワードに惑わされなくなると思います。 専門学校での先生は専門教職では無く、元々技術者だった方（第1次オンライン世代!）が多く、学生時代にこういう視点を持たせてくれたと事については今でも大変感謝しています。
VC++がDeveloperをターゲットとしたのに対して、VBは、Professionalをターゲットにした製品と聞いています。このProfessionalは、開発のプロではなく、医者や弁護士等の専門職です。 開発のプロをターゲットにしたのはなく、医者や弁護士といった本業は他にある人が、本業の助けとして何かを作るときに作りやすいこと。これが目的であれば、オブジェクト指向はかえって“ジャマ”でしょう。VBが本来あるべき姿に戻った、とも言えるかもしれません。 開発のプロは、C#、C++を使いましょう(^-^;
その VB が (自称) Developer の仕事にこんなにも流れ込んでるのは何故? もはや、VB は本来の目的とは違う使われ方をしているのではないでしょうか?
Beginners’ All-purpose Symbolic Instruction Code まんせー ＥＵＣ（えんど・ゆーざ・こんぴゅーてぃんぐ） って死語になってしまいました？(w ノーツアプリケーションが典型的だったよーな。 VBAはＥＵＣにあたるのかな たしかになぜＶＢなんだ＞業務アプリ Ｃ，Ｃ＋＋の敷居が高かったからかな。
>ソフトウェア史、あるいはシステム開発史的な感覚とか理 >解はとにかく必要だと思います。新しい技術の登場には必 >然性があるわけで、その必然性を理解するためにも歴史は >学ばないといけませんし、なにやら新しい技術として登場 >したものも、別の形でいつか通ってきた道だと言うことも >発見でき、バズワードに惑わされなくなると思います。 まさにそのとおりですね。 でも、こういったとこを理解しましょうよなんて、「プログラムは動け後OKな人」に提案すると、細かいことは気にするなよ的なことをいわれます・・・・orz 技術の啓蒙ってむずかしいですな
学習用途にもまた、VBAの存在などもありVBの人口が広いから。 そして、C++との隔絶があまりにも^99広いから。 裾野が広いということは、人口も多く・・・ C#は今後は尖がる方向、VBは円くなる方向のようですので、VBの方向性については生暖かい目で見ることにしています。 #My嫌い(^^
> 細かいことは気にするなよ的なことをいわれます VB を広く柔軟に使えるように、Option Strict のようなオプションがあっても、 そういう方って絶対「Off」なんですよね!! (w 暗黙のインスタンス禁止のオプションをつけたとしても同じことが言えそうです。 せめて初期値が「On」なら良いと思うんですけどね。。。 # 私も My は嫌いです。 # せめてエイリアスの集まりだったら良いにしても、妙なもの使ってますし... # 詳しくは中の技術日誌参照 (ヲイ)
僕もMyは嫌いです。 Option Strict Offも動的バインドが必要な局面では有効ですが、それ以外は害でしかないので、やはり初期値「ON」にしたいですね。
フォームをインスタンス化しなくてもいいって・・・ My が追加されると聞いたとき以上の衝撃（泣） ますます VB.NET が嫌いになっていきます。 C# 推進せねば、とおもう今日この頃。
と言っても、VB6 よりは遥かに良いとは思います。(業務の立場で) とりあえず、VB2003 を継続マンセーしときましょう (ぇ まあ、VB2005 でも自分は今までのスタイルでやる。 というのであれば、問題ないとは思います。 XML コメントや Using などのサポートはありがたいですし。 問題は、他人のソースの修正ですね。 いや、ホントそれだけが心配です。 VB を 2 バージョンに分けて欲しいという話がありましたが、 私も今、同じ気持ちです... # やっぱり My は評判悪いんですね。
My って、値を格納しておく HashTable か何かを持つ 単なるシングルトンクラスですよね。きっと。 こんなのを「売り」するなんて・・・と思いました、当時。 必要なら簡単に自作できるのに。 便利だなーとは思いますけど、 見た目の便利さだけしか触れられてないですからねえ。 ＠ITにもそんな主旨の記事があったような。 まあ、「安易なグローバル変数反対！」ですね。
気になったので＠ITの記事読み返してみました。 「単純な」じゃなかったですね。上の投稿は間違いでした。 拒否反応がでて、記憶から消されていたのかも。
＞My って、値を格納しておく HashTable か何かを持つ 単なるシングルトンクラスですよね。きっと。 そういうレベルの知識しかないんだったら批判しちゃだめ。 まったく見当違い http://blogs.wankuma.com/naka/archive/2005/05/14/11369.aspx http://blogs.wankuma.com/naka/archive/2005/06/15/12584.aspx
批判するためには、批判に対して反応してくるだろう人より詳しくならなきゃ足元すくわれるよって意味(^^ ちょっときつかったね。
初歩的な質問ですが VB2005でフォームにSingletonパターンの実装ってできるのでしょうか？ VB2003では2重起動の制御でよく使ってます。
プロジェクトのプロパティから、2 重起動を防げるようなオプションがあったと記憶しています。 また変わってるかもしれませんけど。 # シングルトンと 2 重起動の話は、ちょっとイコールとは言えないですよね?
Singletonは結局staticのことです。 VB7ではSharedだったっけ？
># シングルトンと 2 重起動の話は、ちょっとイコールとは言えないですよね? 説明が足りなかったようでなので。 あるフォームから他のフォームを開く時、同じ画面が2回以上開かないよう制御するためSingletonを実装しました。 ShowDialogで開けばいいのですが、ユーザーの要望もあってできませんでした。 暗黙のインスタンス化ができちゃうとその辺どうなってしまうのかな？ と思ったしだいです。
> その VB が (自称) Developer の仕事にこんなにも流れ込んでるのは何故? “技術情報共有を目的にした”掲示板に書き込まれる“情報のない”質問の多さを考慮し、考える（－＿－； 開発者の、開発者としてのレベルが落ちているから。 "Developer"ではなく、"Professional of Development"になってきているから。 # ２日遅れ
> 開発者の、開発者としてのレベルが落ちているから。 > "Developer"ではなく、"Professional of Development"に>なってきているから。 道具側（この場合開発環境だったり言語だったり）の視点から見ると低レベルな人でも使えるように進化していく宿命があると思っています。 で、今はその進化の途中なのかなと思っています。 昔に比べたらレベルの閾値は、随分下がってきたし。 中途であるが故に、使える事に対するセーフティが追いついていないという弊害もあるのですが・・・。
コンストラクタを Private で隠蔽化することで、 暗黙のインスタンス化が防げるのであれば、 従来通りの手法でシングルトン パターンが実装できると思います。 VB2005 ではどうなんでしょ? シングルトンはフォームに対して実装することがないので、 あんまり考えていません。(^^)
> 道具側（この場合開発環境だったり言語だったり）の視点から見ると > 低レベルな人でも使えるように進化していく宿命があると思っています。 それは、新しい道具のコマーシャルに必ずと言っていいほどくっついている『簡単に』ということでしょうか？ そういう意味での「簡単」であれば、私は反対です。 # 私が反対したところで、そういう流れで進んでいくのですが。。。 開発者の負担が少なくなるという意味では、簡単になって欲しい。しかし、「開発者のレベルを下げる」…もとい、低いレベルでも開発作業が行えるようにするというのは、どうなんだろう？ 開発作業というのは、設計から始まります（いや、要望を引き出すところもあるけど）。その"設計"ができていない、または中途半端な質問が多い。宣伝文句が、"設計"を端折っているだけかもしれませんが、"設計"のレベルは下がっていませんから、結局低レベルな人は使えない、と思うのです。
>開発者の負担が少なくなるという意味では、簡単になって欲しい。しかし、「開発者のレベルを下げる」…もとい、低いレベルでも開発作業が行えるようにするというのは、どうなんだろう？ > 開発作業というのは、設計から始まります（いや、要望を引き出すところもあるけど）。その"設計"ができていない、または中途半端な質問が多い。宣伝文句が、"設計"を端折っているだけかもしれませんが、"設計"のレベルは下がっていませんから、結局低レベルな人は使えない、と思うのです。 その点（設計者のレベルが下がったら困る。） については同意ですし、「簡単に」というだけなら危険なので反対です。 でも、実装するために必要な閾値は下がり続けるだろうし（勿論High-Low２分化して）、それが正当な進化なんだろうなとも思っています。 「簡単になる。」ではなく、「安全に簡単になる。」といった方向に進んで行くと思います。 （.NETだって昔に比べたら随分「安全で簡単」ですよね。） だから、実装の部分に関しての既得権益は少なくなっていくんでしょうね。（一部で残りますが）
Re: VB2005 ではフォームをインスタンス化しなくて良い どういう仕組みで Form1.Show() のようなコードが動くのかを見てみました。
Powered by: Copyright © じゃんぬ