VB.NETでもAutofacで依存性を注入したい

はじめに

OpenCoverのコードを読んでいたら、AutofacというDIライブラリが使用されており、気になったのでそれについてです。

チュートリアル

Getting Started — Autofac 4.0 documentation

大体の手順をざっくりと列挙すると

1. 脳内でいい感じに制御の反転を組み立てる
2. Autofacの参照を追加する
3. アプリケーションの開始時に
4. ContainerBuilderのインスタンスを生成し
5. コンポーネントを登録して
6. コンテナを生成して
7. アプリケーションの実行の間
8. ライフタイムスコープを生成して
9. ライフタイムスコープを使ってコンポーネントのインスタンスを解決する

といった感じです。

Imports Autofac

Module Module1
    Sub Main()
        Dim builder = New ContainerBuilder()
        builder.RegisterType(Of ConsoleOutput)().As(Of IOutput)()

        Dim container = builder.Build()

        Using scope = container.BeginLifetimeScope()
            Dim out = scope.Resolve(Of IOutput)()
            out.WriteLine("hello world")
        End Using
    End Sub
End Module

Interface IOutput
    Sub WriteLine(value As String)
End Interface

Class ConsoleOutput
    Implements IOutput, IDisposable

    Public Sub WriteLine(value As String) Implements IOutput.WriteLine
        Console.WriteLine(value)
    End Sub

    Public Sub Dispose() Implements IDisposable.Dispose
        Console.WriteLine("IDisposable.Dispose")
    End Sub
End Class

hello world
IDisposable.Dispose

直接コンテナからコンポーネントのインスタンスを生成せずに、ライフタイムスコープからインスタンスを生成することでライフタイムスコープが破棄された時点でライフタイムスコープから生成されたインスタンスも同時に破棄されます。

また、コンポーネントに複数のコンストラクタが存在する場合、コンテナ内に引数となりうる他のコンポーネントが登録されていればそのコンストラクタを使用してインスタンスを生成してくれます。

Module Module1

    Sub Main()
        With "ジャムおじさんとバタコ"
            Dim builder = New ContainerBuilder()
            builder.RegisterType(Of AnpanMan)().As(Of IAnpanMan)()
            builder.RegisterType(Of Jam)().As(Of IJam)()
            builder.RegisterType(Of Batako)().As(Of IBatako)()
            Dim container = builder.Build()

            Using scope = container.BeginLifetimeScope()
                scope.Resolve(Of IAnpanMan)().Anpanchi()
            End Using
        End With

        With "バタコのみ"
            Dim builder = New ContainerBuilder()
            builder.RegisterType(Of AnpanMan)().As(Of IAnpanMan)()
            builder.RegisterType(Of Batako)().As(Of IBatako)()
            Dim container = builder.Build()

            Using scope = container.BeginLifetimeScope()
                scope.Resolve(Of IAnpanMan)().Anpanchi()
            End Using
        End With
    End Sub

End Module

Interface IBatako
End Interface

Class Batako
    Implements IBatako
End Class

Interface IJam
End Interface

Class Jam
    Implements IJam
End Class

Interface IAnpanMan
    Sub Anpanchi()
End Interface

Class AnpanMan
    Implements IAnpanMan

    Private _anpanchi As String

    Public Sub New()
        _anpanchi = "顔が濡れて力が出ない"
    End Sub

    Public Sub New(batako As IBatako, jam As IJam)
        _anpanchi = "元気100倍アンパンマン"
    End Sub

    Public Sub Anpanchi() Implements IAnpanMan.Anpanchi
        Console.WriteLine(_anpanchi)
    End Sub
End Class

元気100倍アンパンマン
顔が濡れて力が出ない

おわりに

無事に元気100倍アンパンチが出来ました。

余談ですが、ジャムおじさんやバタコさんは人間じゃなかったんですね。

おわり

VB15の新機能の確認したい

はじめに

3月7日にVisual Studio 2017がリリースされました。

と言うことで今回も露骨なアクセス稼ぎVB15の新機能を確認していきましょう。

どうでもいいですが、VS2017のアイコンって梵字っぽいですよね。筆で書かれたっぽくして色を周りに合わせたら紛れてても気付かなそう。

新機能

新機能はこちらにまとまっているっぽいです。

今回もプログラミングの効率を上げる嬉しい新機能が目白押しではありませんでした。ざんねん

• 値タプル
• ByRefによる使用量の戻り値
• 二進数リテラルと桁区切り

上二つはなんかC#7.0との互換性の為に導入された感がありますし、二進数リテラルも『はぁ、そうですか』感が否めません。

まぁ、とりあえず確認していきましょう。

値タプル

タプルと言えば.NET Framework 4からSystem.Tupleが存在しました。 存在しましたが2つ程欠点が存在しました。

• System.Tupleは参照型で何だかんだ言ってメモリの使用効率とGCのペナルティが発生する
• タプルの要素へのアクセスにItem1やItem2などといった人の温もりの感じられない名前で扱わないといけない

この2つの問題の解決策として導入されたのが値型のタプルであるSystem.ValueTupleと言語機能による名前付きタプルのサポートです。

値型であるため、何だかんだ言ったメモリの使用効率の改善とGCペナルティの削減が図られています。 がこちらは遅延バインディングと暗黙の型変換とアンリミテッドボックス化ワークスにまみれているVBプログラマには関係ありませんGCによる予測困難な遅延の発生を極限まで抑えたい（≒ゲーム実装）などで効いてくることですので、VBの主戦場である生産性アプリケーションではほとんど関係ありません。正直パフォーマンスは二の次で良いから読めるコードを書いてくれ頼む

で、前置きが長くなりましたがVB15の新機能の1つ目の名前付きタプルのお時間です。

あの無味乾燥で温かみの感じられないItem1などの名前ではなく、SyohizeiやKingakuといった温かみのある名前で扱えるようになります。

Function HogeOld(a As IEnumerable(Of Integer)) As Tuple(Of Integer, Integer)
    Return Tuple.Create(a.Min(), a.Max())
End Function

Function Hoge(a As IEnumerable(Of Integer)) As (min As Integer, max As Integer)
    Return (a.Min(), a.Max())
End Function

Dim a = {1, 2, 3, 4, 5, 6, 7, 8, 9}
Dim b = HogeOld(a)
Dim c = Hoge(a)

Console.WriteLine($"min={b.Item1} max={b.Item2}")
Console.WriteLine($"min={c.min} max={c.max}")

もしかしたら弊社の環境が壊れているだけかもしれませんが、この機能はなぜかソリューションを作成しただけでは使えません。

定義済みの型は定義されていません

とは面妖なエラーメッセージですが、どうにかして解決しましょう。

System.ValueTupleの方はNuGetパッケージをインストールすると解決します。

PM> Install-Package System.ValueTuple

属性の方はNuGetパッケージの方にもないっぽいのでCoreFXのコードからコピペで対応します。

github.com

C#なら単純なコピペで行けますが、VBの場合はVBコードに脳内トランスパイルするか別プロジェクトとしてC#でコピペして参照を追加する必要があり軽い敗北感すら感じます。

ということでパパッとVBコードとして書き換えます。

Namespace Global.System.Runtime.CompilerServices

    <CLSCompliant(False)>
    <AttributeUsage(AttributeTargets.Field Or AttributeTargets.Parameter Or AttributeTargets.Property Or AttributeTargets.ReturnValue Or AttributeTargets.Class Or AttributeTargets.Struct Or AttributeTargets.Event)>
    Public NotInheritable Class TupleElementNamesAttribute
        Inherits Attribute

        Private ReadOnly _transformNames As String()

        Public Sub New(transformNames As String())
            If transformNames Is Nothing Then
                Throw New ArgumentNullException(NameOf(transformNames))
            End If

            _transformNames = transformNames
        End Sub

        Public Function TransformNames() As IList(Of String)
            Return _transformNames
        End Function

    End Class

End Namespace

ByRefによる使用量の戻り値

誤訳なんじゃねーのってくらい意味が分かりませんが、機能の方も同じくらい意味が分かりません。

何よりも動くサンプルコードが現状見当たりません。

たぶんC#のref returnに対応する何かなんだと思います。

二進数リテラルと桁区切り

Dim answer = &B0010_1010
Console.WriteLine($"生命、宇宙、そして万物についての究極の疑問の答え = {answer}")

生命、宇宙、そして万物についての究極の疑問の答え = 42

おわりに

VB14でC#6.0との言語格差がかなり縮まったのでVBの今後に期待したのですが、VB15とC#7.0で差はまた開きつつありますね。

ちなみにC#7.0の新機能はこちらです。

blogs.msdn.microsoft.com

あくまでも個人的な感想ですが、VBとC#は手続き型・オブジェクト指向プログラミング言語として（F#と比べて）かなり近い立ち位置にいると思います。 そんなパラダイムもベースとなるクラスライブラリ群もランタイムも共有する2つの言語を同じようにマイクロソフトがメンテナンスしていくかどうかには疑問を感じます。

VB.NETはVB6からC#への過渡期にVB6プログラマーをC#にスムーズに移行させるために作られた。かどうかは分かりませんが現状を見るとC#とVBのどちらに未来があるかといわれるとC#に軍配が上がるのは明らかです。 VBは初心者向けなんて言われることがありますが、少なくともVB.NETとC#は同じオブジェクト指向というパラダイムの上に成り立っている言語ですから言語としての複雑さは同程度なはずです。むしろ書籍・コミュニティの充実しているC#のほうが学びやすいのではないでしょうか。 仮にVBプログラマがC#を理解できないというのなら、それはC#が複雑だからではなくVBすら良く分かってない可能性があります。

とまぁ、お前はVBの何なんだよと言われそうな感じですが、弊社としてはVBは嫌いではないです。 ただ、恐らくはいずれC#（もしくは次の言語）に乗り換えないといけない時が来るのでいつまでも塩漬けにしておくのは得策ではありませんよって事です。

おわり

VB.NETでも遅延バインディングの呼び出し規則を確認したい

はじめに

遅延バインディングを使用したコードを眺めていた時にふと思ったのですが、遅延バインディングはどういう呼び出し規則でメソッドを呼び出しているのだろうと気になりました。

軽く調べてみたところ、言語仕様っぽいのは見つかりませんでした。 分かんないや！これは図書館に行かないとわかんないかも！

Roslynのコードを読めば分かりそうでありますが、あれを読むのは無理なので軽くテストで確認する程度にしておきましょう。

VBは遅延バインディングできるフレンズなんだね

単純な継承関係

Class Hoge

    Public Sub HogeHoge(arg As Object)
        Console.WriteLine("すごーい")
    End Sub

    Public Sub HogeHoge(arg As Fuga)
        Console.WriteLine("たのしー")
    End Sub

End Class

Class Fuga
End Class

Dim h As Object = New Hoge()
h.HogeHoge(new Object)
h.HogeHoge(New Fuga())

すごーい
たのしー

期待通りに呼び出されています。たのしー

亜空間型変換

Class Hoge

    Public Sub HogeHoge(arg As Integer)
        Console.WriteLine("すごーい")
        Console.WriteLine(arg)
    End Sub

End Class

Dim h As Object = New Hoge()
h.HogeHoge("123")

すごーい
123

さも当然かのように型変換をかけてきます。すごーい

拡大と縮小変換

Class Hoge

    Public Sub HogeHoge(arg As Fuga)
        Console.WriteLine("すごーい")
    End Sub

    Public Sub HogeHoge(arg As FugaFuga)
        Console.WriteLine("たのしー")
    End Sub

End Class

Class Fuga
End Class

Class FugaFuga
End Class

Class Piyo

    Public Shared Widening Operator CType(source As Piyo) As Fuga
        Console.WriteLine("拡大変換ができるフレンズなんだね")
        Return New Fuga()
    End Operator

    Public Shared Narrowing Operator CType(source As Piyo) As FugaFuga
        Console.WriteLine("縮小変換ができるフレンズなんだね")
        Return New FugaFuga()
    End Operator

End Class

Dim h As Object = New Hoge()
h.HogeHoge(New Fuga())
h.HogeHoge(New FugaFuga())
h.HogeHoge(New Piyo())

すごーい
たのしー
拡大変換ができるフレンズなんだね
すごーい

拡大変換と縮小変換では拡大変換が優先されます。へー

継承と拡大変換

Class Hoge

    Public Sub HogeHoge(arg As Fuga)
        Console.WriteLine("すごーい")
    End Sub

    Public Sub HogeHoge(arg As FugaFuga)
        Console.WriteLine("たのしー")
    End Sub

End Class

Class Fuga
End Class

Class FugaFuga
End Class

Class Piyo
    Inherits FugaFuga

    Public Shared Widening Operator CType(source As Piyo) As Fuga
        Console.WriteLine("拡大変換ができるフレンズなんだね")
        Return New Fuga()
    End Operator

End Class

Dim h As Object = New Hoge()
h.HogeHoge(New Fuga())
h.HogeHoge(New FugaFuga())

Try
    h.HogeHoge(New Piyo())
Catch ex As System.Reflection.AmbiguousMatchException
    Console.WriteLine(ex.Message)
End Try

すごーい
たのしー
これらの引数
    'Public Sub HogeHoge(arg As ConsoleApplication2.Fuga)':
        最も固有ではありません。
    'Public Sub HogeHoge(arg As ConsoleApplication2.FugaFuga)':
        最も固有ではありません。 に最も固有な、パブリック 'HogeHoge' がないため、オーバーロードの解決に失敗しました

継承関係と拡大変換ではオーバーロードを一意に決定できないっぽいので、呼び出しに失敗しSystem.Reflection.AmbiguousMatchExceptionがスローされます。へーきへーき！フレンズによって得意なこと違うから!

ジェネリック

Class Hoge(of T)

    Public Sub HogeHoge(arg As T)
        Console.WriteLine("すごーい")
    End Sub

    Public Sub HogeHoge(arg As Object)
        Console.WriteLine("わーい")
    End Sub

End Class

Class Fuga
End Class

Class FugaFuga
End Class

Dim h As Object = New Hoge(Of Fuga)()
h.HogeHoge(New Fuga())
h.HogeHoge(New FugaFuga())
h.HogeHoge(New Object())

すごーい
わーい
わーい

ジェネリックもちゃんといけます。すっごーい

まとめ

遅延バインディングは遅いと言われますが、実行時の型情報からオーバーロードの決定を毎回やっていたらそりゃ遅いよねってお話。

また、静的なオーバーロードはコンパイル時に決定されるのに対して遅延バインディングの動的なオーバーロード解決は実行時に決定されるのでこんなこともできます。

Class Hoge

    Public sub HogeHoge(arg as IEnumerable)
        Console.WriteLine("たのしー")
    End sub
    
    Public Sub HogeHoge(arg As Hashtable)
        Console.WriteLine("すごーい")
    End Sub

    Public Sub HogeHoge(arg As ArrayList)
        Console.WriteLine("わーい")
    End Sub

End Class

Dim a As IEnumerable = new Hashtable()

Dim h As Object = New Hoge()
h.HogeHoge(a)

Dim ho = new Hoge()
ho.HogeHoge(a)

すごーい
たのしー

事前バインディングはコンパイル時にどれが呼び出されるかがすでに決定されているので実際の型で呼び出し先のメソッドが変わることはありませんが、遅延バインディングは実行時に決定されるので実際の型で呼び出し先のメソッドを切り替えることができます。 乱用すればパターンマッチングっぽいことができるかもしれません。

でも、こう考えると遅延バインディングも自分が何をやっているのかを完全に把握したうえで使うなら結構有用かもしれません。 ただ、コンパイル時ですら意味わかんないのに実行時まで不確定要素が出てくるとさすがにいろいろとアレなので弊社は遠慮しておきます。

たーのしー