タイプCOMオブジェクトのプロパティがあっても問題ありませんか

VB.Netを使用して、Microsoft Excel用のCOMアドインを開発しています。特定の要素を含むワークシートを表すクラスを作成しました。たとえば、ListObjectがあるとします。次のようにListObjectのプロパティを作成します。

Public Class MySheet

Private myTable as Excel.ListObject
Public Property Table() As Excel.ListObject
    Get
        Return myTable
    End Get
    Set(ByVal value As Excel.ListObject)
        myTable = value
    End Set
End Property

次に、たとえばMySheetクラスに、ListObjectの属性を表すプロパティがあります。

Private myTableStyle As String
Public Property TableStyle As String
    Get
        Return myTableStyle
    End Get
    Set(ByVal value As String)
        myTableStyle = value
        Me.Table.TableStyle = value
    End Set
End Property

このように設定したのは、メインコードで、スタイルを変更するたびに2つのプロパティ（MySheetクラスのTableStyleプロパティとListObjectのTableSTyleプロパティ）を更新する必要がないためです。だから私のメインコードで私は持つことができます：

Dim MySheetObject As MySheet = New MySheet()
MySheetObject.Table = SomeListObject
MySheetObject.TableStyle = "TableStyleMedium4"

最後の行は、文字列値をMySheetオブジェクトのプロパティとして格納し、ExcelのListObjectのTableStyleプロパティを変更します。

これは大丈夫ですか、それともいくつかのコーディング原則に違反していますか？

TableStyleローカルで「キャッシュ」する理由は他にもあるかもしれませんが、それ以外の場合は、「時期尚早の最適化」と見なされる場合があります。プロパティは次のように実装できます。

Public Property TableStyle As String
    Get
        Return Me.Table.TableStyle
    End Get
    Set(ByVal value As String)
        Me.Table.TableStyle = value
    End Set
End Property

これはExcelと密接にリンクしているプログラムであることを考えると、この場合の.Netオブジェクトの通常の扱いと同じ方法でExcel.ListObjectを扱うのは比較的合理的だと思います。 2つの個別のプロパティを必要としないなどの非常に小さなメリットをもたらすには、複雑さを追加する価値があります（ただし、COMオブジェクトであることとは関係ありません）。