【衝撃】なんと旧VBはOOP可能だった！【発覚】

なんと旧VBにはクラスがあった！
なんと旧VBにはメソッド・プロパティがあった！
なんと旧VBにはインタフェースがあった！
なんと旧VBにはリフレクションがあった！
なんと旧VBはインタフェースの多重継承ができる！
なんと旧VBはインスタンスを作成できる！
なんと旧VBはカプセル化が実現できる！
なんと旧VBは抽象クラスを作れる！
なんと旧VBは多態を実装できる！
なんと旧VBはデザインパターンを実装できる！
なんと旧VBはメソッドの呼び出しを動的束縛にも静的束縛にもできる！
なんと旧VBは委任により実装継承に近いことができる！

※ここで旧VBとはVB5、VB6のことを意味する。
残念なことに完全な実装継承は出来ないが
OOPに詳しい人達によると実装継承はOOPに必須の機能ではないらしい。

少しは懲りろ！　　　.／　＼ ＼　　／￣￣￣￣￣￣
　 　　　　　∧＿∧／　　　　￣ 　＜　また貴様か！
　　　　　　（；´Д｀）　　　　 i i i　　　 ＼＿＿＿＿＿＿
　　　　　 /　　　 ヽ ＿　　　i i i--､
　　　　 ./|　|　　 | |　　￣￣￣ |:::::|.
　　　　/　＼ヽ／| | 　　　　　　ﾉ__ﾉ..
　　　/　　　＼＼| |
　　 /　/⌒＼ し(メ　　　　.i i i　.　.
　／ ／　　　 >　）　＼　　ﾉﾉﾉ
/　/ 　　　　/ ／　 　 .＼＿　　ｻﾞｯｸｻﾞｯｸ
し'　　　　　（＿つ　　　/:::::/::...　　 /ヽ
　　　　　　　　　　； "ノ・ ./∴: ／ ）i　iヽ-､＿へ　　　　,ﾍ
　　　　　　　　　　'',, : ：―― /　/　i　i　i iヽ .￣ ﾞ― ノ　/
　 　　n_　　　　＿／；　　　 i　　.ノ / /ノ-'￣ ﾞ ― ､__ノ
　　_ノ　二二二､_（ _Д_　;）-ヽ＿ノ-'>>1
　　ﾞー ''~　　　 　　∨￣∨

VBのクラスのコンストラクタは引数がとれない。
VBのクラスではStaticなメンバが作れない。
VBのクラスではメソッドの多態性が実現できない。

VBのOOP対応は中途半端すぎ。
かなり使いにくい。

>>1
Oops!

衝撃！

>>3
> VBのOOP対応は中途半端すぎ。
ひさびさにまともな答えを見た！気がする。

>>3 = >>6

　∧||∧
（　6⌒ ヽ>>3とまちがえられちゃったよ。
　∪　。ノ
　　∪∪

VBのクラスのコンストラクタ？？？？

>>1よ。ほんと衝撃的だな。
で、抽象クラスってどうやって作るの？（恥

>>3
気にするな！は　げ　る　ぞ!

>>10
俺も知らん！！（恥じか？ｗ）

>>1
そんなの VB やってりゃ誰だって知ってるよ。
それより、Template Method パターンとか実装できないよ。
やりにくいったらありゃしない。あれは OO 対応とはいえない。
亜 OO 言語だ。

共通メソッドの引き上げのリファクタリングもできん。

>>1
> OOPに詳しい人達によると実装継承はOOPに必須の機能ではないらしい。

どの人たちだよ。
デザイン・パターンの本読んでみろよ。
OO にクラスの継承は必須ではないけど、事実上必要だよ。
関数型プログラミング言語に、ファイルのオープンは必須なオペレーションじゃないけど、
ファイルが開けないのと同じぐらい不便なんだよ。

>>13 バカァッ！
>>14 論理的に変だけど、まとも！

>>10
DLLにしてInstancing=Privateとか？

>>12
>1も>13も抽象クラス作れるようだ。
　　　　　　　　　　　 ∧＿∧
　　　　　∧＿∧ 　（´<_｀ 　）　ほんと不勉強だよな俺ら。
　　　　 （　´_ゝ｀）　/　　 ⌒i 　
　　　　／　　　＼　 　　　|　|
　　　 /　　 　/￣￣￣￣/　|
　 ＿_(__ﾆつ/　 VB!　 ./ .| .|＿＿＿＿
　 　　　 ＼/ 　　　　　 /　（u　⊃　
　　　　 　 ￣￣￣￣￣

でもTemplate Method パターンとかは実装できないらしい。
　　　　　　　　　　　 ∧＿∧
　　　　　∧＿∧ 　（´<_｀ 　）　デザインパターンなんて全く知らないよな俺ら。
　　　　 （　´_ゝ｀）　/　　 ⌒i 　
　　　　／　　　＼　 　　　|　|
　　　 /　　 　/￣￣￣￣/　|
　 ＿_(__ﾆつ/　 VB!　 ./ .| .|＿＿＿＿
　 　　　 ＼/ 　　　　　 /　（u　⊃　
　　　　 　 ￣￣￣￣￣

>>15
理論的にどーこーとかどーでもいいけど、
Java や C++ や Ruby や Delphi でふつうに OO やっている感覚で組むと、
あれもできない、これもできない、ってなる。

Template Methodってようするに継承じゃないのか？
>>1はちゃんと継承できないって書いてるぞ。

>>16
それで抽象クラスになるの？

>>21
さぁ？ 他の言語じゃこうすれば抽象クラスって書いてあるから
分かりやすいけど「抽象クラスってなに？」と聞かれたときの答えは･･･。
Instancing=Privateの効果と一致しないかな？

抽象クラス兼インターフェースは、何も処理のないメソッドを定義したクラスを作ればいい。

詳しくは、VBUnit のソースを見れば、インターフェース（VB ではイコール抽象クラス）の継承のコードが書いてあるよん。

試せる環境がないのな（泣
調べる気力もないのな（大粒涙

>>25
お前ほんと最凶だな。

「OOは戦場では必要なし」かなんかのスレで見たんだけど
委譲による継承をする言語もある(たぶんVB以外)って書いてあった
気がするんだけどその言語ってなに？
つーか委譲による継承も継承って言っていいの？

今までバカにしててすまんかった > VB
でももう、仕事でも個人的にも使うことは無いだろうなぁ。

>>28 漏れはＶＢの親戚なら仕事で使うなぁ。仕事が進めば良いので
特別な感慨はないが。

VBのインタフェースってJavaやC++のインタフェースより便利だね。
二つの別のインタフェースにそれぞれ同じ名前のメソッドがあっても
ちゃんと継承できるんだもん。

>>27
> 委譲による継承をする言語もある(たぶんVB以外)って書いてあった
なんかおかしいな...

> 気がするんだけどその言語ってなに？
JavaかC++だと思う。というか、それってAdaptorパターンのこと?

> つーか委譲による継承も継承って言っていいの？
"委譲による継承" ってものがあるのか?
とりあえず継承と委譲は別物。
Adapterパターンには継承する場合と委譲する場合との2つのパターンがある。

VB で OOP は可能だ。
N-BASIC で手続き型プログラミングができるのと同じぐらい便利だ。

>>1
そんなこと、今に分かったことじゃない。

総檜タンスよりも
インスタンスのほうが売れるから
そうしたまでのこと

コンストラクタで引数取れないのはイヤすぎる・・・っつーか使えんぞ実際。

>>1
VB でクラスの継承ができてしまうと、VC++ が売れんようになってまうからやろ。

>>36 VB.NETではできるみたいだぞ。
M$はVC++捨ててC#に移行させたがっているから、
そろそろVC++の売れ行きも気にしなくなるのかな。

VB.NETでなくとも、VBは型をいい加減に扱えるから
C++のようにはいかんだろうね

発覚って・・・

というか、その程度のことも知らなかったのか>>1よ。

その事が発覚した事が一番の衝撃だな。

>>35
標準モジュールに
Public Function ClassNew(引数) As クラス
Set ClassNew = New クラス
ClassNew.Init 引数
End Function
なんてのを作るとか。

ｶﾞｰﾝ

http://lounge.dip.jp/~christmas/upb/file/cipaint.lzh
旧VBでOOPが可能であることを証明するプログラムらしき物を見つけました。

VBのOOPはどーでもいーのでエラーメッセージで続行を選べるようにしろ。
なんでSetFocusぐらいで強制終了しなきゃならんのだ。

>>20
＞Template Methodってようするに継承じゃないのか？

違います。
メソッドを細分化して、その一部を変更する事を言います。（"一部"って所でストラテジとも別）
具体的には.....（一番下に続く）

>>16 , >>21
＞DLLにしてInstancing=Privateとか？

話、端折り過ぎ。
結果的にそうやってコンポジットに実装をカプセル化したものを、継承して具体的な（固有な）実装を行った場合、
逆説的に、その元の「ロジックは何にも無いけど、用のあるものコンポジションしといたよ」側のクラスは、
抽象的なクラスであると、（強引だけど）言えます。それだけ。

>>31
プロトタイプ型OO言語の中には、委譲による継承（みたいなもの）を行う物があるそうです。
要するにこれもコンポジションとして内部のメンバを、「さも自分の機能のように見せかけて」実装を継承する
ような形になると思われます。なので、正確には「継承」では無いんですが、アダプタパターンと
言い切ってしまうのも、ちょっと違うような。ていうか、コンポジットパターンなんですが...。

なので、最初のテンプレートメソッドと継承の関係で言うと、その「差し込まれるロジック」を包含したオブジェクトを
メンバとして内部に保持している場合において、上記委譲（コンポジション）の関係を結んだ場合、
「継承してるように見えるんじゃないの？」って感じになるように思われますが、
正直、強引すぎる話だと思われます。ぬるぽ。

念のため。

オブジェクト・コンポジション ＝
例えば「車オブジェクト」には、「エンジンオブジェクト」や「タイヤオブジェクト」が包含されているが、
「車オブジェクト」は「エンジンオブジェクト」を継承しているとは言わない。（"is-a","a-kind-of"関係では無い）

しかし、それを使うクライアントは、「車オブジェクト」の提供するインタフェースを使用し、「エンジンオブジェクト」を利用する。
これをOOでは、「車オブジェクト」は「エンジンオブジェクト」の機能を委譲されている状態("has-a"関係)、と言い、
あたかも「車オブジェクト」がもともとその機能を持っているかのように、振舞われている。

この（構成されている）状態を、コンポジション（Composition=構成）という。
ちなみに、コンポジションの構成物側（前述の例の「エンジンオブジェクト」「タイヤオブジェクト」など）から「車オブジェクト」を
見た場合、これを"a-part-of"関係にあるオブジェクト、と言う。

VBは基本的にモジュール指向言語。

なので、糸冬　了。

ほしゅ

つまり、継承先でメンバ関数のオーバーロードができひん言語やと、
Template Method パターンは使われへんのやゆーことやな。

>>48
google結果
モジュール指向言語 1件
モジュール指向 36件

たかがTemplate Methodパターン一個できないだけで
デザインパターンが出来ないなんって言っている奴はドアホ

>>52
かなり重要だぞ。
クラスの継承ができないっていうことは、メソッドの引き上げもできない。
そうじゃないと、全部 Abstract パターンでやるしかない。
リファクタリングもくそもありゃしない。
亜 OO だよ。

> そうじゃないと、全部 Abstract パターンでやるしかない。
デザインパターンはできると認めた発言でした（ｗ

ほしゅ

VBはSelect Case文にstring使えるのだけは良かった
これはCもJavaも無理

>>54
1 個だけできてもほとんど意味はないんですよ。
やったことがあれば分かってると思うけど、よく使う、シンプルで、分かりやすく、
意義のあるパターンをほとんど使えないことが亜 OO 言語 VB の問題点なのね。

だから、Template Method パターンやメソッドの引き上げのような、ほとんど
OO のイディオム的に使われる記述ができないと、OO 言語というには言えないわけ。

クラス SomeClass があって、その子クラス ChildA と ChildB とで共通の
メソッドがあった場合、普通の OO 言語ならそれらを子から削除して親の
SomeClass に実装すれば、リファクタリング「ただひとつだけ」ルールが
守れて、同じ処理が複数出て来ないようにできるでしょ。
子クラスがもっとあったら、VB だと子クラスで全部実装しなきゃならない。
これはバグバグの温床。

なぜ、ある特定のパターンだけ実装できても OO として意味がないか、まあ、あんたも
わかってるよな。初心者じゃないし。

>>56
マクロを駆使すれば可能

>>58
C じゃ仕方ないが、C++ ではマクロは駆使しないのがいいスタイル。
マクロは可読性からして煩雑な上に、コード上であるコードがマクロかそうでないか
区別しにくいことも多い。
マクロは駆使しない。必要最低限にする。

> 1 個だけできてもほとんど意味はないんですよ。
あなただけですよ。一個だけしか出来ないなんてアフォなこと言ってるのは（ｗ

>>60
マジ何個できるか教えてくだしゃい

ま、いくつ出来たとしても、
使えるの？VBerに。

まあ、「出来ない」って事自体は間違いである点だけは確かな訳で。

>>57
メソッドの引き上げがいつからOOのイディオムになったんだ？
リファクタリングの話だろ。

継承が出来ないVBでメソッドの引き上げの話をだすのもなんかずれてるんだが、
お前はClassAとClassBで同じメソッドなのに両方のクラスに別々に作るのか？
お前初心者だろ。コンポジションにして委譲させるとか考えつかんのか？

明らかに手段と目的を勘違いしているな。
> なぜ、ある特定のパターンだけ実装できても OO として意味がないか、まあ、あんたも
> わかってるよな。初心者じゃないし。
その証拠がこの文だ。実際の開発では必要なものを使えるか代替方法があれば十分。
もともとデザインパターンは問題の解決法としてよく使われる設計を
パターンとして集めただけに過ぎないんだから。
VBでTemplate Methodを実装できなければ他の方法でやるまでだ。

反論したいなら、まず「ある特定のパターンだけ実装できても OO として意味がない」理由をちゃんと書け。
「あんたもわかるよな」って言葉でごまかすことが許されるなら、
「ある特定のパターンだけ実装できれば OO として意味がある、まあ、あんたも
わかってるよな。初心者じゃないし。」という言葉も十分通用するわけだ。

>>61
継承することが条件となっているTemplate Methodパターン以外全部。
言語に依存しないパターンをどのように実装するかは言語しだいだからね。

>>47
そいつは集約(Aggregation)のことだろ。
UMLで白塗りのひし形で描く奴。

で、黒塗りのひし形が集約よりも強く、
コンポジション集約という。

>>66
両方合わせてオブジェクト・コンポジションと言へり。

VBでOOが出来るのは違いないんだが
コンストラクタに引数が取れない段階でどうかと思う。

Init プロシージャ作って必ず呼ぶようにしてもいいんだけど、
面倒だし危険だし。

やっぱり中途半端。

>>68
OOの主な目的のひとつに再利用性の向上があげられる。その意味では、
使い捨てプロトタイプ構築用のVBでOOを目指すのは、本末転倒じゃねぇか？

>>69
標準モジュールしかまともに使えなかったころに比べれば、
再利用性は高まっているかと。

最初からOO言語として設計された言語に比べると
見劣りするのは仕方がない。
所詮はVB。

OOPできてメリットがあるんかいな。
なんか新しい流行に媚びるが、無理があるんで、周りからは
醒めた目で見られてるオヤジの行動みたいだ。

OOを前提としたルールを元に、適切な制限が言語仕様になってて、
コンパイラがエラーを吐いたりするところにこそ、OO言語を使う
メリットがあると思うんだけどなぁ。

コードの外で、みんなでこうしましょうとか示し合わせないと使えないものは、
Javaの乱立フレームワークと変わらん。

>>71
釣られませんよ。（´∀｀　）

>>71 オマエは単にJavaを妬んでいるだけだろ

で、75 は釣りなんですか、どうなんですか。

>>71
やってみ。
OO をやってみれば、その楽ちんさに VB なんてかったるくなる。

>>71 オブジェクト指向の時代は終わりつつある。
これからはアスペクト指向だ。
だがオブジェクト指向の知識が前提だ。
早くしないと時代に乗り遅れるぞ!!!

エージェント指向?
あまり関係ないな。

データ指向、コンポーネント指向?
M$の好きそうなしょうもない指向(志向(思考))さ

71 は立派な釣り師ですた

>>77 頭が悪いというんだな

>>78
77 は釣り

こんだけ釣りが多いと、魚も逃げちゃうね！（汗拭きながら、笑顔の親父）

昔、VB互換文法のLotusScriptでクラスと継承をやりくりしてた。
周りには「分からん」といわれたが、こっちにすれば楽に実装できるのになあと思ってた

Actuate Basic は、VB ライクでありながら、完璧な OOPL だった。

>>82
そうそう。なんで OO で書くとみんなわからんって言うんだろうね。
分かりやすいのに。保守しやすいのに。コードもバグも減るのにね。

>>76
データ指向、コンポーネント指向がM$の考えたものだと思っているのなら
勉強しなおした方が良い。

>>85 どこにM$が考えたものと書いてあるんだ?

ちょっと質問。

インターフェース継承をした場合、

-----Class.cls-----

Implements Interface

' メソッドの実装
Private Sub Interface_Method()
　.........
　.........
End Sub

としてやるわけだけど、この場合、

Private foo As Class
Set foo = New Class
foo.Method

なんてやるとエラーになっちゃいますよね。
どうしても上のように書きたければ、

-----Class.cls-----

Public Sub Method()
　Interface_Method
End Sub

なんてやるんだろうけど、これって面倒じゃない？
それともこういう使い方はしないものなの？

>>87
OOを勉強しなおして来い。

上の例だと普通は

Private foo As Interface
Set foo = New Class
foo.Method

とするんであって、わざわざ具象クラスに応じた型の変数宣言してたら
インターフェースの意味ねぇぞ、てことですよね。

ただ、COM にして ASP でも使おうとすると、上の例で VBS だと Class を
CreateObject するだけじゃ Method は呼べないんで、どうするのが
いいんかなーなんて。

何がしたいのかわからん。
インタフェース継承の意味をわかってないと見たが・・・

VBSはVBと違って型が無いからな。

型がないけど、内部で何型で保持しているか気をつけないとうまく書けないので、
結局形無しの意味がない。

１は馬鹿なのか？何をいまさら。

そういえばインタフェースの「継承」って、「実装」とは違うものなのかな。
...って、ただの言葉の定義の話なんだけどね。

Javaだとインタフェースは「実装する」と言い、C#とかだと「継承する」という。

俺の感覚だと、インタフェースはやり取りの「規約のようなもの」だと認識しているので、
つまり実装が無い所に実装するんだから、「実装する」と言いたい。

インタフェースを継承って言っちゃうと、まんま

「インタフェース自体を別のインタフェースが継承する（実装を伴わない）」

って、聴こえる。そこんとこ、どうよ。

実装と継承は全然別物。
勉強しなおしたほうがいいかと。

>>95
いや、だから「言葉の定義」の話なんだよね。（わかりづらくてスマソ

なんかC#の説明をしていた雑誌で、インタフェースの実装を「継承」と言っていたのですよ。
「インタフェースを継承」している事をそう言うのじゃなく、実装している事を「継承」と言っていたのです。
そこでは。

なので、俺の感覚だと「それって実装だろ？」と言いたい、と。

>96
手元のC#エッセンシャルズを見たら、「インターフェースの実装」って
書いてあるぞ。

C#：
class ClassName : BaseClass , Interface { }

継承と実装が併記されてるから、記事書いてる人が、
意味を混同してるか、文法を理解しやすいように書いてるか。

>>97
なんだ、そうなのか。良かった。

こういう言葉の定義の違いが横行すると、
ミーティングの時とかでいつも苦労してしまう。（笑

Thanx!

あ、ちなみにミーティングって、
「新人が混じってる時の、クラス設計レビューミーティング」ね。

念のため。

まあ、「実装継承」って言葉もある訳ですし。

よけい混乱するかｗ

>53
あおおー

要はだな、>1が証明するソースをうｐしてくれればいいわけだ。

あげとくか

唐突だけど、interfaceって、VB.NETにはあるけど、VB6には無いよね。

>>105
C++にもないよ。って言えば少しは頭を働かせてくれるかな？

>>106
いや、宣言の事なんだけど。

>>107

「>>106
　いや、宣言の事なんだけど。少しは頭を働かせてくれるかな？ 」

って、言わなきゃ。

>>107
つまり>>105のinterfaceというのはキーワードの話であって
インターフェースという考え方の話ではないということか？
紛らわしい書き方するなよ。

>>109
そうです。紛らわしい書き方して、スマソ。

>>108
煽り口調は嫌いでつ。

>>109
考え方も何も、キーワード自体無い（機構として備わって無い）ってのは、
無いのと同じでは？

// ま、無理矢理それっぽく書けばできない事も無いけど、それじゃ有るっていう証明にはならんね。

>>111
Implements ステートメント

クラス モジュール内にインプリメントされるインターフェイスまたはクラスを指定します。

構文
Implements [InterfaceName | Class]

必ず指定する引数 InterfaceName または Class には、タイプ ライブラリ内のインターフェイスまたはクラスの名前を指定します。このインターフェイスまたはクラスのメソッドは、Visual Basic クラスの対応するメソッドにインプリメントされます。

解説

インターフェイスとは、そのインターフェイスがカプセル化するメンバ
(メソッドとプロパティ) のプロトタイプの集合です。
つまり、インターフェイスには、メンバ プロシージャの定義だけが含まれています。
一方、クラスには、インターフェイスが定義するメソッドやプロパティを実際に
インプリメントするためのコードが記述されています。クラスには既定のインターフェイスが
含まれているので、すべてのクラスは少なくとも 1 つ以上のインターフェイスを
インプリメントします。特に明示的な指定がない場合、クラスに記述されたコードは、
そのクラスの既定のインターフェイス メンバとして解釈されます。

Implements ステートメントは、そのクラスが既定のインターフェイス以外の
インターフェイスをインプリメントすることを宣言します。
Implements ステートメントで宣言することにより、指定したインターフェイスの
メンバを Visual Basic クラスでインプリメントすることができます。
また、クラスの QueryInterface は、Implements ステートメントで指定された
インターフェイス ID を許諾し、クラス内にインプリメントされたメンバを
マッピングした VTable を返します。

>>112
今、MSDNを確認。...失礼しました。

// 要するに無いのは interfaceキーワードだけなのね。

衝撃の事実あげ

つかVBやってる現場の人間で Implements 知ってる奴皆無だった。
別にVBに特別不満は無かったんだけど、java に転向した理由がそれ。

projectは標準EXE。ソースファイルは frm と bas。
非常に硬派しかもVBの本質に近い人たちばかりでついて行けませんでした。

for each 使ってるの見た瞬間、コーラ瓶見つけたブッシュマン見たいになってた。

>115
・・・それはVB以前の問題のような気が・・・
VB使ってる人間にそういうﾔｼが多いのは確かだけどね・・・

>>1
動的束縛とか静的束縛ってなんですか？

>119
具体的には、亀甲縛り等のことですよん♪

いえ、宣伝アゲではありません。信じてください。

>>112
すばらしい。言語仕様の把握(勉強)ってとても大事だと思ったよ。

定期アゲ

最近疑問に思ふ
効率的なVBを使うVBプログラマに、非効率的なプログラムする香具師が多いのは何故？

>124
オートマチック車にしか乗れない人は運転ヘタな奴ばかりってのと一緒だと思われ

中途半端に有能な召使いは主を白痴にするって奴だね

「AT車」が悪いのではなく、「AT車にしか乗れない」ﾔｼが悪い・・・
いつもの結論ですな。

運転上手い奴がAT車に乗るのは問題ないし、AT車に利点もある。
当たり前の結論ですな。

で、AT車にすら乗れない俺は神と。

AT車でMT並のシフトチェンジに挑戦すると普通にMT乗った方が楽だよな〜

MTは渋滞に引っかかったら左足がつったりしない？

それ以前に維持費やらなんやら

もっとセミオートマが普及してもよさそうなモンだけどね。

つか実際にプロジェクトでImplements使った奴いるの？

つーか、最初に 「オートマ」 って言い出した香具師は誰よ？

>>134
使っているけど、何か？

>134
サーバサイドのDLL作る時は普通に使うじゃん。

Implements 使ってプログラム書いたら、
納入先に「理解できんから書き直せ」っていわれた。

ちゃんと使っている人いるんだね。
なんか安心したｗ
うちは>138と同じく、他の人間に「理解できない」って言われたｗ

>>115
Excel VBA とかでも普通に使っていたけど。うちは、コード・レビューもないので
きっと誰も知らないでしょう。

>>119
Early Binding と Late Binding のことじゃない？

あの　ちょっとおしえて
ｖｃで作ったｄｌｌをｖｂで使いたいんだけど
Declare宣言で　ｄｌｌのファイル名指定しても
デバッグしたら　ファイルが見つからないって怒られる。
環境変数のパス登録とかいるんだっけ
動作環境はシステムフォルダ内じゃねーんす
だれかおしえて

>>141
%System root%Systemか
%System root%System32に放り込んでいないなら
dllのパスを環境変数に追加しないと駄目だったと思う。

>>142
アリガトゴザイマス

他の奴らが理解できるのを待ってたら、いつまでたってもVB厨からは
抜け出せんぞ。

ちょっとヘルプ引いて解説読めば理解できる事にいちいち気にするな。

(・∀・)

ばなな

なますて

Implementsアゲ

>>1

なんと旧VBにはシリアライズがあった！

が抜けてる。

age

>>150
えええっ！！！
知らなかった。

>>152
Persistable プロパティを調べよう。

ていきあげ

> Persistable プロパティは、パブリックおよび作成可能なクラスに対して
> のみ使用できます。Persistable が vbPersistable に設定されている
> 場合、InitProperties、ReadProperties、および WriteProperties イベント
> がクラスに追加されます。また、PropertyChanged メソッドもクラスに
> 追加されます。

VB ﾏｿｾｰ

おどろいた。
こんな話しVB使ってる奴から聞いたことがなかったよ。

俺も知らずにVBバカにしてたけど
俺の周りのVB使いがバカだったのね。

はなしし?

最近はやっているのかなぁ。はなしし。

ＶＢでクラスを使ってみるテスト
ttp://www.ncfreak.com/magazine/No.003/vb_class.html

テストあげ！

配列の操作なんとかなんねぇか・・・
この実装はキチガイだ・・・

ＶＢにクラス実装させていました。
それも、ＶＢＡに。

>162
継承できないのが激しく痛い。

なんと旧VBはOOP可能だった！

>>10
抽象クラスなら、よく見掛けるよ。
Formイベントハンドラの宣言部だけ残して全部コメントアウ(以下、略)

Private Sub Form1_Load()
Call Err.Raise()
End Sub

On Error Gotoはtry-catchと同じようなものです。
Err.Raiseはthrowと同じようなものです。

ていきあげ

VBではすべてのクラスはObjectを継承しています。
すべのコントロールはControlを継承しています。
もちろんControlもObjectを継承しています。

勘違いしている奴が多過ぎ

なんと、旧VBはOOP可能だった！


・・・ただ、それを使おうとする者はいなかった。

使ってみたけど、インターフェースの継承はできるけど、
クラスの継承ができないくて、オブジェクト・コンポジション
ばっかりの設計になって、使えんなと思た。

まぁ、Cなんてクラスすらないから
もっと使えんのだが。

>>173
でも、だからといってオブジェクト指向しないことは無いよね。
たとえばAbstractFactory使いたい局面ではVBでもAbstractFactory
使うし、Strategy使う場合でもやっぱりStrategy使う。

デザパタってのは何かしたいことがあってそれをどう実装するかって考え方なんだから、
VBでも同じことはしたくなる。それをデザパタ本にのっているJavaなんかの例どおりに
実装できるならそう実装して、実装できないなら違う方法で実装するだけなんだよね。
なんかこう、Javaと同じように完璧に実装できなきゃダメって考え方している人多いね。
重要なのはどう実装するかではなくてどのような考え・設計で実装するかなのに。

VBではOOPはおろか構造化設計すらあやしい実装が多い。
何にも考えずにコピペで済ましている奴が何と多いことか・・・
たまにクラス使ったかと思えば1つのメソッドがだらだらと1000行超えてる・・・

やっつけ指向言語かいな。なんかVS.NETのコードの折りたたみがこの傾向を
助長しそう。

>>174
構造体メンバに関数ポインタをつっこめ

>>177
構造体メンバに(C++の関数オブジェクトみたいな)オブジェクトつっこめの間違いだろ

>>176
> VBではOOPはおろか構造化設計すらあやしい実装が多い。
理由が書いてないよ。


自分の技術不足を言語のせいにするのはやめようね。

￣￣|￣￣|￣|
￣|￣￣|￣￣|ヽ＿∧
￣￣|￣￣|￣|´･ω･`） まあ、黒酢でも飲めや。
￣|￣￣|￣￣| /U
￣￣|￣￣|￣| |
￣|￣￣|￣￣| ∪
＾^＾^＾^＾^＾^＾^＾^＾^＾^＾

￣￣|￣￣|￣|
￣|￣￣|￣￣|
￣￣|￣￣|￣|彡
￣|￣￣|￣￣| ｼｮﾎﾞﾝ
￣￣|￣￣|￣|
￣|￣￣|￣￣|
＾^＾^＾^＾^＾^＾^＾^＾^＾^＾

>>175
> 実装できないなら違う方法で実装するだけなんだよね。

だから、オブジェクト・コンポジション多用になった。

おい！おまえら！

VBでオブジェクト指向設計−開発を行うなら、これがおすすめ。
もちろん、この本のすべてを薦めるわけではありません。使えるところだけ使いましょ。
ttp://www.amazon.co.jp/exec/obidos/ASIN/4881356844/ref=sr_aps_b_3/249-6286723-7638748

VBでデザインパターンならここに(一応)23パターン全部ある。
ただ、強引な実装なので全部はおすすめできない。それに馬鹿高いです。
ttp://www.amazon.co.jp/exec/obidos/ASIN/0201702657/ref=sr_aps_eb_2/249-6286723-7638748

知ってた？

注意書きしとく。2冊目のVBデザインパターンの本は買わない方がいい。
読んでがっかりするはず。理由は>>175さんの言うとおり。それでもな
お、23パターンのVBでの実装に興味があれば買って読んで下さい。

個人的には、VBのオブジェクト指向はこんなんでもいいやと思ってます。
なぜかというと、実装継承とか、Staticなメンバ、メソッドの存在を知っ
たVB厨が、「これは便利！」と思いもよらぬアクロバティックなコード
を書く姿が目に浮かぶ。

グローバル変数の変わりに、Staticメンバを使ってあちこちで変更した
り、グローバルモジュールのかわりに大量の関数を突っ込んだオールマ
イティクラス(名前はｃlsMainLibrary)を作って、すべてのクラスに継
承させたりするんだろう。さらに多重定義とかあった日には、、、
恐ろしや。

> グローバル変数の変わりに、Staticメンバを使ってあちこちで変更した
> り、グローバルモジュールのかわりに大量の関数を突っ込んだオールマ
> イティクラス(名前はｃlsMainLibrary)を作って、すべてのクラスに継
> 承させたりするんだろう。さらに多重定義とかあった日には、、、
なんかJavaの現実と同じだな。

そりゃおまえの会社の現実だ
もしくはおまえの現実

>>185は>>183にも当てはまってしまうんだが･･･。

VBはOOP可能だということが分かっていただけましたね？

>>183
2冊目の本はVB.NETも乗っているわけだし無駄にはならないのでは？
それにStrategyとかはJavaの実装と対して変わらないし。

CでもアセンブラでもOOP可能だよ

VB のメソッドにおける Private が
“クラスに対して”ではなく“インスタンスに対して”なのは
間抜けじゃないか？

>>188
おそらく俺がこの本に期待していたことが、「もしかしてすっごいト
リックで実装継承の問題を解決してたりして！」なんていうファンタ
ジーだったから、現実を知って無駄金払ったと思ったのかも。なお、
VB.NETのデザインパターンなら、Javaのでも大体代用できるので、
結城さんの本がより良いかと。さらに言えば、誰かのwebページの
デザインパターンのサンプルソースコードを使えばフリーかと。

ふと気になって、
VB.NETでデザインパターンを記述する本を探したら、こんなのがあった。
http://www.amazon.co.jp/exec/obidos/ASIN/1861006985/qid%3D1050335021/249-3910424-9035502
目次をみたら、リファクタリングとかアンチパターンにも触れている模様。
amazon.comでは、（レビュアー二人ではあるが）5つ星の評価。

>>192
英語読めねーよ！

>>193
それぐらいでガタガタ言うな。

>さらに言えば、誰かのwebページの
>デザインパターンのサンプルソースコードを使えばフリーかと。

　その本の著者の結城さんのサイトである程度解説されているという罠。

>>193
おい、おまえ！ 英文読まずにソースコードだけ読むのは如何でしょうか。
>>195
結城さんのサイトは参考にしてます。日本語の書き方講座も併せて読んでます。

 以下VB6の開発でStrategy、似非Composite、似非Visitorを使った時の感想です。
まず設計にすごく時間がかかった。なにしろ素直にOOできないので悩んだ。しかし
その後のメンテナンスは非常に楽になった。GoFのパターンは適用しづらいので、
GoFではないまったく別のVB専用のデザインパターンが欲しいところ。

>>196
結城さんのサイトを参考というのは、正しくなかった。実際にはたまに
読み物的に読んでいる、程度。

（＾＾）

ずいぶん下がったな。

Mastering OO Development with VB6
http://www.vbug.co.uk/vbug2002VB6/slides/OODev.pdf
ご苦労さまです．

なんだかんだいっても、VB6でOOをする試みってあるんだな。
CよりかははるかにOOしやすいし。

>>201
しかし言語仕様そのものがｱﾚだからなぁ…
レイトバインディングせざるを得ない場合が少なくなかったり
ターゲットプログラムが CPU 喰い始めると IDE が制御不能に陥ったりと
開発効率が殊の外悪い。

>>202
せざるを得ないって、OO なんだからレイト・バインディングに決まってるじゃん。

…

>>203
>>202 は、C++ から OO もどきを始めちゃって、アーリー・バインディングが
OO のデフォルトだと思っちゃってるんだよ。

レイトバインディングせざるを得ない場合ってどんなときだろ？

環境の違いを吸収したいときとか。

>>207
互換性が保証されないライブラリを同じコードで使うってことか？

いんや。

「せざるを得ない」って言葉は、したくないのにしなくちゃならないときに使う
言葉なんだけどなぁ。
環境の違いを吸収するためにレイトバインディングにするのは当たり前だよ。
つーか、アーリーバインディングで環境の違いを吸収するときには
Abstract Factoryパターンとかを使えばいいよ。

>>210
Abstract Factory パターン、レイト・バインディングなんですけど。

言語的にアーリー・バインディングができるのって、C++ の非 virtual メンバ関数
だけじゃん？

Abstract Factory パターンは、親のメソッドを子でオーバーライドするから、C++ で
実装するなら当然 virtual だから、レイト・バインディング。
Java なら言語仕様的に C++ でいう仮想関数しかできないから（static 関数は別
にして）、どうやったってレイト・バインディング。

>>210
実行時に切り替えたい場合にはどうすんのさ。

　　 ∧＿∧
　　（　　＾＾ ）＜ ぬるぽ（＾＾）

この中で一番変なことを言っている奴。

それはこいつだ。
> レイトバインディングせざるを得ない場合が少なくなかったり
レイトバインディング(virtual)なんて普通にやることだよ。
なにを毛嫌いしているのだろう？

>>211-213
うん。あきらかに勘違いしてるね。
残念ながら有効な反論になってないよ。

http://software.nikkeibp.co.jp/software/yougo/yougo4.html
> 　Visual Basicの場合，タイプ・ライブラリを参照設定し，
> オブジェクト変数の型を明示的に宣言して利用するときは
> アーリー・バインディングに，変数をObject型と宣言したときは
> レイト・バインディングになる。
> C++の場合，普通の関数はアーリー・バインディングに，
> 仮想関数はレイト・バインディングになる。

>>217
OO するならレイト・バインディングに決まってる。
だから C++ で面倒でも、コンストラクタ以外、いちいち virtual とタイプする。

>>217
VB でもなんでも、言語は関係ない。メソッドはすべてレイト・バインディングにする。
せざるを得ないなんてんじゃなくて、しなくちゃだめ。
static 以外は。

>>217
Abstract Factory パターンがアーリー・バインディングだったら、
AbstractProduct のメソッドが直接呼ばれるが、こいつは純抽象メソッドなので、
実体がなく、エラー。

>>217
コードでは AbstractProduct のメソッドを呼んでいるのに、実際は ConcreteProduct の
メソッドが呼ばれるようにしないと、このパターンの意味がない。つまり、レイト・
バインディング。

>>220
VB は純抽象メソッド（C++ でいう純仮想関数）は作れないんじゃん？

>>222
そうか。AbstractProduct の空メソッドを呼び出せば、アーリー・バインディングだな。
VB で OO するひとは、それで Abstract Factory パターンでアーリー・バインディングで
実装できるって思っちゃったんだ。

ｱｹﾞﾙぞ、ｺﾞﾙｧ！

VBでレイトバインディングというと、Object型で宣言した変数に
CreateObject、もしくは、Newキーワードでオブジェクトを割り当
てることを意味する。オブジェクトのメソッドを呼ぶ事に焦点を
当てると、C++,Javaの実行時結合と似てる。(コンパイルの時点で
は呼ばれるメソッドはわからず、実行される時に初めて分かる）

しかしVBをやっている人にとっては、レイトバインディングは 
 --> IntelliSenceが使えない。
 --> するとメソッド、プロパティでスペルミス
 --> Compile時にスペルミスがチェックされない 
結果的に、
 --> Runtime Error
ということになるので、嫌がるのです。

それを防ぐために、Interfaceを作ってImplementsしてるが、なん
かやり辛い。行き難さを感じる。実装側のメソッド名が
Interface_doSomethingのように、長くなるからかな。

>>224
長いか？ どっかの言語はInterface::doSomethingなんて
平気で出てくるのだが。

>>223
つーか、VBスレでVB以外を基準にすること自体おかしい。

げっ。あげてしまった。

http://homepage.mac.com/ayaya16/

>>225

C++では、
純粋仮想関数doSomethingメソッドを持った抽象クラスInterface

class Interface {
　　virtual void doSomething() = 0;
};

を継承したConcreteClassでdoSomethingをover-rideするときに

class ConcreteClass : public Interface {
public:
　　void Interface_doSomething();
　　　　　~~~~~~~~~~
};

void ConcreateClass::Interface_doSomething() {
　　　　　　　　　　 　　　~~~~~~~~~~
　　// 処理
};

なんて余計なものはつかないでしょう。しかし、VBではそうさせら
れる言語仕様。↓を見ればなんとなく分かっていただけるかと。
ttp://www.asahi-net.or.jp/~jz6h-ymmt/sandbox/vbPolymorphism/vbPoly.htm

忘れられる前にあげておこう

>>229
それのおかげでVBでは同じシグネチャのメソッドが存在する
複数のインタフェースを何の混乱もなく継承できるんだよね。
この点は良く出来ていると思った。

古い VB って 2.0 や 4.0 のことかと思ったよ。

5.0からOOP意識した造りになってるから、
不格好ながらも実装できて当然じゃないのか？

そうです。でも頑固な人間は難癖つけるのです。

>>231
そっか、そういう使い道があったんだ！とはいえ、その恩恵を
享受できる場面はすくないかもしれない、自分の場合。

どういう場面でつかったの？いや、煽りじゃなくて、純粋に興
味があります。あと後学の為

VB6でクラスモジュール使うメリットってなんかありますか？
自分は全部標準モジュールとフレームにべた書きしてるんですが。
あ、一応MVC分割はきちんとしてますよ。

━―━―━―━―━―━―━―━―━[JR山崎駅（＾＾）]━―━―━―━―━―━―━―━―━―

そろそろあげとくか、

それと、>>236 は釣りか？
MVC分割しているなら、標準モジュールよりクラスモジュール使ったほうがやりやすいと思うが？
しかもフレームじゃなくて、フォームだろ。と一応訂正しておく。

こんな糞スレageるなよ。

何かVC分ける理由がよく分からない。

どうせそのCはそのV専用になるわけだしさ。

クラスモジュールを使うことのデメリット→

OOPを理解できないPGに読めないので、保守性が下がる。

いやほんと。

>OOPを理解できないPGに読めないので
まあ、その時点で既にOUTだけどな。

>>240は真実。
>>239は無知。CはClassのCではなくて、Controller。
Cはマウス、キーボードなどによる制御を担当する（ようにすると良い）。
ModelがClass。ここでも読んどけ。http://www.sra.co.jp/people/aoki/MVC/page1.htm

ビジネスロジックをGUIから分離してGUIの変更がロジックに及ばないようにするのがMVCの意義。

あるVBプログラマ(伊○)は、自分の担当したフォームの中でListViewをつかっていた。
あるとき列の順序を変えてほしいというリクエストに恐ろしく時間を掛けていた。
なぜなら、列を変えると、すべての機能を書き直す必要があると判明したのだ。
しばらくがんばったが結局使い物にならず、見かねた彼の上司がすぐにはできませんと断ったらしい。
テスターをしてたユーザー激怒。ユーザーと喫煙所で一緒になった時に俺も愚痴られた。
「ITは仕事やるきあるの？列の並び変える事すら出来ないでお金もらっていいの？」とか。

伊○「あんなリクエスト、俺らエンジニアの仕事じゃない」と言って、辞めていった。
辞めてくれて助かった。

、、、愚痴ってしまった。もうしません。

>240
いくらVB厨とはいえ、人の作ったものの改修くらいはできるんじゃ?

変数名も関数名も長めに分かりやすく書いてあるだろうし、
関数の追加だって、あらかじめクラスはあるのだから
どこに追加すればいいかくらい分かるだろう。

そいつはどんな厨ぶりを発揮してくれたの?

>>242
＞>>239は無知。CはClassのCではなくて、Controller。

いや、そのつもりで書いたんだけれど。
って言うかどこをどう縦読みすれば>>239がCがClassを指してると解釈できるんだ？

それはすまんかった。こっちの間違いです。すんません。
しかも無知呼ばわりして、マジで申し訳ないです。

スタンドアロンなVBアプリではV,Cを分けなくてもいいんでないか。
VBではVとCが密接な関係なのに、敢えて分けるのは不自然と言う気もした。

V,Cを分けたほうが良い場合はServlet/JSP関連のシステム。ASPはよく分かりません。
表示（V）はJSP、CはSevlet、MはBeanとか。まあ人それぞれだろうね。
あと多様なLook&Feelで動かす場合とか。スキン切り替えもVC分離の例。かな？

>>245
ごめん、俺SwingのHack位なら出来るの。そんなヌルい返事は期待してないよ。

>>239
違うViewで同じControllerを共有できるように、でないかね。
昔(Smalltalk-80とか)は今時分程View間の関係が密接じゃなかったからな。

人じゃないけどコーディング規約では見たことありますね。
理由を上の人に聞いてみたら大体240みたいな返事が返ってきました。
VBは初めて2ヶ月なんですけど、こういうのって一般的なんですかね。

OOPは設計に個人差が出やすい。
ヘタ設計でOOPをやられると、とたんに保守性が下がる。

結局のところ、プログラマの質が揃えられないところでは
安全策としてOOPを禁止するのもひとつの手段かと。

# そういえば、害虫のプログラムの質があまりにも悪いんで、
# 安全策のために SQL のDelete 使用を禁止したとこがあったっけ。

VBの場合MVCのVはコントロールで、Cはイベントハンドではないかと思う。
となるとユーザコントロールを作らない限りはVは存在しないことになるか。

>>250
突っ込んでやろうと思ったが結構的を射てる。

そう? ありがと。
曼荼羅的にMVCが存在するなんて書いてあるサイトもあるし、
MVCにそった設計ってあやふやで人それぞれのような。

CとMだけならまだ考えやすいな。

C++だが、上司がfriend関数使いまくって困った。

その上司は無意識でPrivateを公開したい欲求があったんじゃない？

新人です。お仕事でVBAやることになりました。

Cの常識もJavaの常識もPascalの常識も通用しない新言語を前にして泣きそうです。

よく来たパラッパ。すべてのものはVariantなのじゃ。
心の目で見、心の耳で聞くのじゃ。

　　　 　∧＿∧
ﾋﾟｭ.ｰ　(　　＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
　　＝〔~∪￣￣〕
　　＝ ◎――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉

VBって有用な情報がまるでないね。
標準で使えるライブラリもないし最悪ぽ

>>258
あげて言ってもデマとしか思われないから注意したほうがいいよ。
どうせ「釣れた」っていうためだけにあげたんだと思われるのがオチだから。

>>256
JavaではすべてのものがObjectです。
VBではそれがVariantになっただけですね？

いや、マジで、使えるライブラリがほしいんよ
qsortとかいちいち書くのマンドクセ

>>261
検索ぐらいしろ。

検索とかじゃなくてさ、
標準になってないから困ってんのよ。わかる？

事実上標準のライブラリもないのかよ。ってこと

サンプルソースなんて腐るほどぐぐってるよ。>>262

腐るほど調べてクイックソートをやっと
組めたのか?

>>261
関数ポインタが使えないから汎用性がないのは仕方がないこと。

関数ポインタが無くても作れるよ。
そんなに難しいことじゃないんだけどなぁ。
頭固すぎ。

あのさ、できるできないじゃないの。わかる？
いちいち作らなくちゃいけないのがいやなの。

つか、264,266はうざいので以後放置します

sageずに書くほどのネタなのか？
旧BOCとかがそんなライブラリ出してなかったっけ？
アレならVBの標準だったといってもいいんでないか？

ていうかDLLでもOCXでも標準モジュールでもクラスでも
よく使うコードは自分で一度作っておいて使い回せば
いいだけの話だろ。

標準で入ってないからダメ、っつーのは情けないな。

>>266
具体的には？
(CallByNameとか？)

classもつかえねぇVBでOOなんかできるわけねーだろ。
＞＞１士ね

VBでコードを再利用したいなら
コピペ支援ツールを使うのが一番良いよ。

汎用性を持たせようとするとハマる。

汎用性ってよりバグ取りが大変だと思うが＞コピペ
どこにコピペしたのかフォローするのがコピペ支援ツール？

>>274
クラス書く→半端な言語仕様にイラつく、保守しづらいと周囲にウザがられる
DLL書く→OleVariantに対応するのがめんどい、配布しづらいと周囲にウザがられる

仕変やバグFix時にコードの一貫性、一意性を保証する仕組みを自動化（ツール等で）
するつもりなら、妥協的手段としてのコピペもありかな？

静的HTMLで類似する箇所をコピペするのは珍しいことではないし。
(比較対象として妥当かどうか・・・)

# 本末顛倒の感、なきにしも非ずだが・・・。

　　 　∧＿∧
　　　（　´ー｀） 　>>275　わかりますわかります
　　　（　¶¶¶　）
　　|￣￣￣￣￣|

VBでコードを再利用するなら普通はクラスや標準モジュールに書くだろ。
他の言語も同じ。まさか本気でそう思っているとは思えんが。
VBだからってDQNなやり方をするのは本当にDQN

つーか、ただ煽っているだけか。適当な事言っているみたいだし。
詳細説明をもとめても答えないだろうな。
> クラス書く→半端な言語仕様にイラつく、
> DLL書く→OleVariantに対応するのがめんどい

>>271
それもあり。あとSTLって知っているか？
STLにもソートがあるのだが、そこにも関数ポインタは使われていない。
関数ポインタが無いJavaにもソートはある。
つまりVBにもクラスがあるので同じような方法で実装できるわけだ。

>>272 いや。つまらん。でなおせ。

俺変なこと言ってる？
煽っているだけとは酷い言い草だなあ。
まぁ言葉足らずだったことは認めるけどさ。

>>274
コピペ支援ツールはソートや探索のルーチンを
ただ貼り付けるだけの奴のつもり。
0から書くよりはマシだろ？

>>278
>VBでコードを再利用するなら普通はクラスや標準モジュールに書くだろ。
標準モジュールにコピペするんだよ。

>他の言語も同じ。まさか本気でそう思っているとは思えんが。
他の言語と同じことやったら>>275の状況に陥ったんだが。

>VBだからってDQNなやり方をするのは本当にDQN
DQNじゃねぇやり方を示してみろよこの野郎！

コピペなんて言うからいけない。

(C++のテンプレートのように)汎用性を持たせたコードから、
指定した型のコードを機械的に生成するのならまぁいい。

しかし、一般に言われるコピペ。その害として上げられる
バグや修正があった場合、修正個所が複数に渡ってしまうような
事が起きるなら使ってはならない。

あと使う場所ごとにコードをコピペするのと勘違されるだろうな。
コピペといっても使うのは最初に一回で
複数のプロジェクトでその標準モジュールを使いまわすんだろ。
それなら問題ないよ。

熱くなってｽﾏｿ。
もちつきます。


つ旦

リストビューかコンボボックスをひそかに作ってソートする









なんて奴はいない。











と言い切れない気もしてきた。

>>284
DelphiのTListみたいにMVCのMとなる構造はないのか？VBには。

ソートかぁ。面倒だからJET呼び出して済ませちゃう。

Excelのインスタンス使ってソートしる！

それはそうと、相当そーっとソートしなきゃ。

>>288
卒倒しとけ。

よく考えるとソート用のライブラリを使おうがリストボックスを使おうが
結局用意されているライブラリを使っているだけだよな。
技術力とか関係ない気がしてきた。

>>290
って言うかプログラマ名乗るならクイックソート位実装できるだろと。

探すのめんどいから書くってのも手の一つだと思われ。

>>288
ガミラスには下品な男は必要ない

>>291
VBプログラマの世界をなめてるな、、、

リンクリストさえ作れない奴のオンパレードだぞ

>>293
改めて考えると、すごいよな。
5年10年仕事で毎日使っているのにその程度のままでいられえる
ってのは、コピペとおしえてクンだけで世の中わたってきた奴で
もない限り、無理だよな…

>>293
あんたの周りだけ。

>>293
コレクションあるから実装する必要がないというのも。

GlobalMultiUseアゲ

>>296
コレクションを使えるやつが1割もいないという罠

>>298
＞コレクションを使えるやつが1割もいないという罠

どんな業界なんだ・・・ここ。

>>299
>>298の周りだけでしょ（ｗ

何も見ずにｸｲｯｸｿｰﾄやB木を実装できなくても
しかし、「こういうものがあるんだ」というポイントを
押さえておくだけでいいような気もする。

Collectionを使えない、という人はCollectionの概念を知らないだけで、
概念が無いから、検索しようにもできないし、人に聞くのも容易でない。
（人に聞くときには、自分がやりたいことをすべて説明する）

とはいえ、
「こういうものがあるんだ、へー」という意識を持っている人は
自然に内部の実装にも興味を持ち、アルゴリズムを理解し、何も見ずに
実装できるようになるだろう。時がたち、忘れることがあっても
そこが差になるんだろう。

そんなことをつれづれに思いました。

>>301
でも、専門家でありプロフェッショナルである以上、知ってないというのもどうかと思うぞ。

いってる事はその通りなんだろうけど、前提が間違ってると思う。
VBの勉強しててCollectionに出くわさないなんてあり得ない。

殺していい人材だと思う。

VBでコレクションってどんな場合に使うのよ？

>>304
リストが欲しいとき、ハッシュマップが欲しいとき。