|
VB.NET移行の最大のハードルはオブジェクト指向プログラミング文化オリエント（株） ―― VB6とVB.NETの互換性維持については、あまり配慮されていないということでしょうか？ そうではありません。たとえば、従来のActiveXコンポーネント、これはレガシーCOMなどと呼ばれることもありますが、これをWindows Formsでも使えるような仕組みが用意されています。これら従来のActiveXコンポーネントは、Windows APIとIntel x86アーキテクチャに依存したネイティブ・バイナリです。これらのコンポーネントをWindows Forms上に貼り付けると、一種のラッパー（wrapper）のようなものが自動的に生成され、それがネイティブ・バイナリであることを隠蔽して、マネージド・コード環境でも機能できるようにします。 この仕組みによって、理屈では、従来のActiveXコンポーネントをそのままVB.NETでも使えるはずなのですが、現実にはいろいろと問題があります。ベータ1では残念ながら、この互換機能の完成度はあまり高くありません。また仮に完成度が上がったとしても、前述したように、ベースとなるフォームが異なりますので、描画などの細かい動作において、完全な互換性が維持できるかどうかは疑問です。さらにラッパーという余分な処理を通すことになりますから、当然ながらパフォーマンスへの影響もあるでしょう。このようなことから、弊社では、.NET環境では.NETネイティブなコンポーネントを用いるのが正しい選択であると考えています。現在、既存のActiveXコンポーネント製品を.NETへ移行しているのもこの理由からです。 言語仕様の違いについては、アップグレード・ウィザードというものが用意されています。VB.NETでVB6のプロジェクトを開くと、このウィザードが自動的に起動され、ソース・コードを走査します。そしてVB.NETで言語仕様が変更された部分を検出し、自動的に修正できるものは修正し、そうでないものはレポートとして非互換のコード部分をプログラマに報告してくれます。ただしこのウィザードは、ベータ1以前のPDCプレビュー版（プログラマ向けのカンファレンス、Programmer's Developer Conferenceで配布されたバージョン）では組み込まれておらず、VS.NETのベータ1でやっとウィザードのアルファ版が組み込まれたという印象です。このためかどうか、機能的には不満も多いですし、まだ完成度もあまり高くありません。 ―― それでは、既存資産には目をつぶって、まったく新規に開発を進めたほうが得策ということでしょうか？ ソフトウェア資産の規模や内容、プログラマの考え方などにもよるので、一概には言えませんが、あくまで個人的な意見として申し上げれば、名前は同じ“VB”であっても、VB.NETはまったく別のものだと考えたほうがよいと思っています。 たとえば、DOSからWindowsへの移行期を思い出してみましょう。Windowsへの移行初期では、「Windows対応」とうたいながらも、Windowsの流儀ではなく、DOS時代のインターフェイス（ファンクション・キーを駆使するなど）を引きずったアプリケーションが少なくありませんでした。しかしそうしたアプリケーションのうち、あるものはWindows環境に馴染まないという理由で淘汰され、あるものはWindowsの流儀に従ってインターフェイスを新規に設計し直しました。既存のWindowsアプリケーションから、.NET環境への移行においても、これと同じことが言えると思うのです。.NETはまったく新しいパラダイムです。この新しいパラダイムには、従来とは違った、それに最適な形があるはずです。既存の資産を無理矢理持ち込むよりも、新規に開発したほうが、より.NETの価値を活かすことができると思います。
―― VB.NETに移行するハードルは高く、既存資産の移行も容易でないとすると、はたしてVBプログラマは、VB.NETに取り組むべきなのかという疑問も持ちますが……。 プログラマが開発言語を選択するとき、これまではVC++か、VBかの二者択一でした。両者のギャップは非常に大きいので、いずれを選ぶかはある程度自明でした。しかしVS.NETでは、新しいオブジェクト指向言語であるC#が登場したため、言語の選択は微妙になるでしょう。.NET環境では、あらゆる言語で、クラス・ライブラリなど同一のフレームワークを使用します。またVB.NETは完全なオブジェクト指向言語になったため、前提となる知識もVB.NETとC#であまり変わりません。VB.NETでも、C#でも、VS.NET上の言語では、まったく同じコンポーネントを使ってプログラミングすることができます。 C++の敷居は依然高いにしろ、VB.NETか、C#かという選択はもはや好みの問題というレベルだと思います。VBが気に入っているならそのままVB.NETを選択すればよいでしょうし、この機会に新しい言語を学びたければC#を選択するのもよいでしょう。どの言語を選ぶにしても、私はできるだけ多くのVBプログラマに.NETの世界へチャレンジしてもらいたいと思っています。弊社では将来の.NET対応製品の言語サポートにおいて、VB.NETとC#を同等にサポートしていく予定です。 ―― 文化オリエントさんは、先ごろから自社プロダクツの開発環境をC#に全面的に移行したと伺いました。この決断に至った経緯をお教えください。 これまで弊社では、VC++を使用してコンポーネントを開発してきました。初期のVC 1.5から現行のVC 6まで、マイクロソフトの開発環境の変遷に応じて、使用するフレームワークも、MFC（Microsoft Foundation Class）からプラットフォームSDK、ATL（Active Template Library）1.0、ATL 2.0、ATL 3.0と変化してきました。その後、自社で独自のフレームワーク（ベースクラス）を開発し、コンポーネント開発を効率化しました。数値や日付などの入力を支援するインターフェイス・コンポーネントのInputManや、伝票入力コンポーネントのDenpyoManなどは、この独自のフレームワークを使って開発された製品です。開発は100％ C++だけで行ってきており、C++で築いた膨大な資産があるわけです。 Microsoft.NETが発表され、VS.NETのPDCプレビュー版を入手して、さっそく新しいVC++.NETの評価を行いました。VC++.NETでは、.NET Frameworkに従ったマネージドC++を利用すれば、煩雑なメモリ管理をCLRのガベージ・コレクタに任せることができます。これに対し、従来からのWindows APIやx86アーキテクチャに依存したコードはアンマネージドC++と呼ばれます。VC++.NETでは、これらマネージドC++と、アンマネージドC++を1つのプログラム内で混在させることができます。つまり、これまで自社で構築してきたソフトウェア資産は、アンマネージドC++として使用しながら、新規開発部分にはマネージドC++を使用するということが可能なのです。 しかしこれは現実的ではありませんでした。今述べたように、マネージドC++では、メモリ管理をCLRに一任でき、メモリ・アドレスをほとんど意識することなくプログラミングが可能なのですが、アンマネージドC++のコードを呼び出すときには、必要なメモリ領域を固定して渡さなければなりません。マネージド／アンマネージドC++を混在させると、マネージドC++のメリットが失われてしまうばかりか、今呼び出しているのはマネージドなのか、アンマネージドなのか、混乱をきたしてしまいます。 検討を重ねた結果、弊社では、既存資産を移行するのではなく、.NETのアーキテクチャに従って、完全にネイティブなマネージド・コードを新規開発することに決定しました。またプログラミング言語としては、C++ではなく、.NETに最も適した言語として開発されたC#を使用することにしました。C#とC++の書式はよく似ているので、言語の乗り換えはそれほどプログラマの負担にはなりませんでした。
―― C++プログラマから見た、C#の評価についてお教えください。 後発の言語であることから、言語仕様が簡潔で、生産性が高いことが大きなメリットです。実際に計測したわけではありませんが、C++を新しく学習するよりは、C#を習得するほうが簡単だと思います。長所の2つ目は、デレゲート（メソッドをカプセル化し、C++やCの関数ポインタのように扱うための機構。イベント処理やコールバック処理で使用される）を利用できること、そして3つ目は、前述したとおり、ガーベジ・コレクションを利用できることです。 一方の短所としては、クラスの多重継承が使えないこと、テンプレートが存在しないことがあります。 ―― 最後に、文化オリエントさんの将来展望についてお聞かせください。.NETでは、Windowsアプリケーションだけでなく、WebサービスやWebアプリケーションも重要な位置づけにありますが、これらへの対応もお考えでしょうか？ 将来に向けては、いくつかのフェーズがあると思います。何よりまず最初に取り組む必要があるのは、.NETの登場によって、VBプログラマが直面する問題を解決することです。具体的には、既存のVB Forms用のコンポーネントを、.NETネイティブに移行しなければなりません。これらの製品については、VS.NETの正式版が発表されるタイミングで出荷したいと考えています。現時点では、VS.NETの正式リリースは2001年末と言われています。 WebアプリケーションやWebサービスへの対応は、その次のフェーズとして考えています。まだ具体的にお話できる段階ではありませんが、これらに取り組む基本的な姿勢は、従来のビジネスモデルと何ら変わりません。標準では用意されない、高機能で使いやすいコンポーネントを提供していくということです。 鎌田 明 （かまた あきら）
|
||||||||||||||||||||
- 第2回 簡潔なコーディングのために （2017/7/26）
ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている - 第1回 Visual Studio Codeデバッグの基礎知識 （2017/7/21）
Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう - 第1回 明瞭なコーディングのために （2017/7/19）
C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える - Presentation Translator （2017/7/18）
Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
 |
|
|
|
|
