中の人の徒然草443

ここ最近、毎日数十分ほど集合理論について考えています。その中で思ったのは、F#が知的ツールとして優れているという事です。F#は数学的もしくは論理的な事を考えるのに向いています。私が情報技術者だからかもしれませんが、数学の証明よりも明瞭に思考を整理できます。
数学の証明も知的ツールとして優れているのですが、静的で宣言的すぎるような気がします。紙に書いたり頭の中で展開したりしたとき、F#のようにすぐに実行して実データを検証できません。また、細かな論理を記述するのに向いていないような気がします。それも私が技術者だから感じる事なのかもしれません。
技術者はその理論が常に現実に役立つかを考えます。現実に実行できないような理論を構築しても意味がありません。それに、手早く確認できるかなども考えてしまいます。といっても、数学を軽んじているというわけでもありません。まだそれほど学習していませんが、数学は一通り学習しようと思いすでに準備しています。幾何学・解析学・代数学・集合論はやります。他にはあるのかな？あったらやるかもしれません。
私は数学を楽しんでやっています。学生だった頃はさほど好きではなかったのですが、大人になってからその魅力にはまっています。受験だからやれと言われるといやですが、趣味でやる分には楽しいです。他には数独にはまった時期もありました。あとは、物理学や化学ももっと堪能したいです。う～ん、時間が足りないな。
それら自分の遊びを思い返せば、自分は自由に思考できるのを好む人間のようです。押しつけがましい勉強は嫌いですが、自分で自由に研究するのは大好きです。
今日本の教育が問題視されていますが、日本の教育は体罰なんてしていないで、知的な遊びを自由にさせたらいいと思います。私が学校を好まなかった理由は、自由に学問を堪能できないからです。型にはまることを好まない私のような人間も沢山いると思います。そういった子供に対して、カリキュラムに縛られることなく、あらゆる学問を自由に堪能できる場が与えたら、日本の生きた学力は向上するのではないでしょうか？
そもそも、学校が学問をするのに向いていないと感じさせること自体が間違っています。日本の教育機関が、本当の意味で学ぶ場になってほしいと心から願っています。現状はお受験という形式主義に縛られているような気がしてなりません。それを学問と呼ぶのは学問に対する冒涜です。
日本は全体的に、非理論的な形式に縛られていると思います。いい加減で無意味なシステムがはびこり、人を犠牲にし続けています。システムのために人が居るのではなく、人のためにシステムがあるのですから、ちゃんとしたシステムを作ることを目指すべきです。日本はルールとかシステムと創るのが苦手なのかな？
何かを変えようとする人を、日本のマスメディアはバッシングする傾向があります。だから何もしない方が得であり、結果として日本は何も変わりません。これでは鎖国のようです。形式上は開国していますが、心は鎖国していると思えてなりません。変なルールやシステムを変えず、人に精神論的な我慢だけを強いる。どれだけ犠牲が出ても一時的に騒いでお終い。これが本当に健全な社会だといえるでしょうか？
バグ（問題）が発生したら論理的に考え根本的に治す。この当たり前の行為を続けることが社会人であり、人の社会であるべきだと私は思います。いつまで子孫へと問題を先送りにするのか。私は恥ずかしいです。当たり前のことを当たり前に行う。そんな社会になってほしいです。

情報集合論（仮名） 限界は人間の錯覚

　この記事は自分用のメモです。無限次元体を相手にしたとき明らかになる事実は、限界があって人間がそこに到達するのではないというものです。理論的な上限は、人間が命名し、条件を定めた時点で発生します。例えば、要素数が3の集合に冪演算を実行すると、8個の要素を持つ冪集合が生成されます。ならば、要素数4の集合を作ってから、冪演算を実行したほうが要素数が多いのは明らかです。これは人間が作る学問の本質だと思います。
　原子よりも細かい要素が発見されると、人間の学問は発展します。その原因は情報が増えたからです。ということは、人間が認識できる情報を増やせばよいのです。人間の五感を文明の力で増やせば問題は解決です。それを繰り返せば、人類が保持する知識集合の要素数が増えます。この考えから私は量子力学とカオス理論を連想します。
　無限に存在する情報に対し、人間の能力は有限です。情報をどのように取り出すのか、それにより解釈が異なりますし、ほんの少しの情報の差だけでも多大な誤差をもたらします。人間は主観で物事を考えがちなので、あたかも世界が変わったかのように感じます。しかしそれもまた錯覚であり、情報の切り口を変えたのにすぎません。情報は無限次元体であり、どのようにカットしても、人間が納得できれば真実として存在するように感じるのです。ある意味全てが錯覚だといってもよいでしょう。
　人間はおごり、真理を明らかにするという考え方で知識体系を構築します。しかしながら、所詮人間の能力は有限です。真実の欠片をつなぎ合わせて自己満足しているだけです。先入観を捨て、謙虚な心で無限次元体を分析する必要があるでしょう。

情報集合論（仮名） 無限次元情報体

　この記事は自分用のメモです。情報集合論（仮名） 冪集合の正体についての考察ということは、要するに冪集合は無限次元を表わすと思われます。何故ならば、情報の組をよく観察すると、冪集合が表わすものは行列にしか過ぎません。従って、無限次元を表わしていると考えるのが妥当です。
　この結果は何ら不思議な事ではありません。そもそも情報は、やろうと思えば無限に微分できます。また、情報を無限に合成することも可能です。ならば、どの情報が分割できない情報なのか、どこが限界の情報なのかを考える事は愚問なのかもしれません。人間の情報認識能力が範囲を定めるのであって、情報は無限であり、いくらでも分割できますし、いくらでも合成することができるのです。
　しかしながら、ちっぽけな存在である我々人類は、大いなる自然に対して疑問を繰り返すことにより進歩します。この世の全ての真理を理解できると考えるのは愚かですが、無限から有限の情報を取り出す方法はいくらでも考え出せます。その無限の情報を有限の情報へと写像することが学問なのでしょう。
　その謙虚な心で情報を観察すると、無限に繰り広げられる情報の組にも法則性が見えてきます。生成された情報の組は冪演算回数に比例した深さを持っています。例えば、3つの要素からなる冪集合は、8個の要素を持ち、最高の組み合わせは要素が3個の集合です。すなわち、要素数＝深さ（1）となります。また、情報の組は新しい要素となりますので、再度冪演算を実行すると、2の8乗＝256個の要素を持ち、深さが2の冪冪集合が作れます。ということは、1次元の要素を多次元に拡張しているだけです。次元数には限りがありませんから、情報は無限次元体だと言えるでしょう。
　情報が無限次元体だとわかれば話は簡単です。全ての問題を抽象化すると、人間が認識して命名できるか否かになります。目の前の現象からどれだけ情報を取り出せるのか、適切な名前を付けられるのか、この2点が正しければ後は写像するだけです。
　さて、無限次元体をどうやって料理するべきか。その料理法が情報集合理論になります。それこそ無限に方法が考え出せますが、その中から人間が思考しやすい方法を選ぶ必要があります。

情報集合論（仮名） 冪集合の正体についての考察

　この記事は、自分の考えをメモするためのものです。冪集合は要するに、情報の組に過ぎない。すなわち、情報は任意の数組み合わせることができるという事だと思います。それを踏まえて、カントールのパラドックスを考えると、集合の集合は情報の組を含むのか否かが問題になってくると思います。
　情報の組を集合の集合に含むのであれば（おそらくそうだ）、素朴集合論は情報の重複を認めないのですから、いつしか情報が尽きて、そもそも冪演算が実行できない時が来るのでしょうか？この問題については、無限と極限に該当する問題だと思います。人間が知る全ての情報の集合は無限です。ならば、その集合の要素から成る組は無限となります。
　無限個ある情報の組みを作ろうとすれば、濃度の定義から2の無限乗個の情報ができるとわかります。ということは、一応上限の概念があることになります。しかしながら、人間が認識できる情報は人類が存続する限り増えるでしょう。もし、人間の文化が破壊されれば、情報の数は一時的に減りますが、人類が存続している限りまた増えます。
　これらの事から導き出される答えは、任意の集合から生成される冪集合は、集合の場を上限とし、無限大に大きくなるということだと思います。この値は理論的には収束しますが、上限値そのものが常に増加しているので、アキレスと亀状態だといえるでしょう。
　ただしこれは、冪演算を1回しか実行していないときにのみ成り立つ理論かもしれません。冪演算を無限回繰り返すことができるのであれば、情報は無限大に発散するかもしれない。しかしながら、素朴集合は重複を許さないのですから、理論的には組み合わせ数にも無限値の限界があるような気がします。すなわち、上限が変数で常に変動する場合、濃度がどのようになるのかが問題になるのです。
　この問題は宇宙のビッグバン説を連想させます。無限に広がり続ける情報宇宙。ただ、変化するのであれば関数ととらえることができるかもしれない。上限を変数とする関数。もしかしたら、これが無限の正体なのかもしれません。
　今までの考えをまとめると、人の情報N＜2のN乗（冪集合）＜冪冪集合<...<場の情報量であり、冪集合と場の情報量の間に、無限の距離があるということです。しかしながら、一時的には理論的な上限値が存在するでしょう。それは、無限関数を意味します。この無限関数の定義を目指すと面白いと思います。おろらく、カントールが目指していたものもそれなのでしょう。連続体仮説にその片鱗がうかがえます。残念ながら途中で終わっていますが。。。
　連続体仮説の問題は、実数の濃度を上限としているところです。私は実数の濃度にこだわる必要はないと思えてなりません。また、自然数に拘りすぎていると思います。実数も自然数もただの情報です。情報そのものを変数としてとらえれば、何も自然数や実数に縛られる必然性はありません。私の感覚としては、何らかのオブジェクトです。無限を研究するのですから、数に拘る必要すらないでしょう。ならば...

情報集合論（仮名） 等価性と集合

　この記事は、自分用のメモです。集合演算を実行するには、要素に等価性が必要です。等価性がなければ、集合の要素が片方の集合に含まれているか否かを判定できません。従って、等価情報集合が必要です。

//情報
type Info<'a, 'b, 'c>
  (
    f : 'a -> bool, //フィルター関数
    m : 'a -> 'b,  //マッピング関数
    parentGetDataFunc : ( List<'c> -> List<'a> ) option //親の関数
  ) =
  //フィールド
  let _filter = f
  let _map = m
  let mutable parentFunc = parentGetDataFunc
  member private this.Filter with get() = _filter
  member private this.Map with get() = _map
  member private this.PrentFunc with get() = parentFunc
  //親を考慮してデータを取得する
  static member (=>)( data : List<'c>, x : Info<'a, 'b, 'c> ) : List<'b> =
    let newData = x.PrentFunc.Value( data )
    newData => x
  //親を考慮しないでデータを取得する
  static member (=>)( data : List<'a>, x : Info<'a, 'b, 'c> ) : List<'b> =
    data
    |> List.filter x.Filter
    |> List.map x.Map

type Data<'T>( name : string, value : 'T ) =
  //フィールド
  let _name = name
  let _value = value
  //プロパティ
  member this.Name with get() = _name
  member this.Value with get() = _value
  //メソッド
  override this.ToString() = _name + ":" + value.ToString()

[<EntryPoint>]
let main argv = 
    //結果表示
    let PrintResult name data =
      printfn "%s" name 
      let f x = printf "%s " <| x.ToString()
      List.iter <| f <| data
      printfn "\n"
    //テストデータを準備
    let source =
     [ 
      yield "実験データ" :> obj
      for i in 1..10 -> ( "正数", i :> obj ) :> obj
      for i in -10..-1 -> ( "負数", i :> obj ) :> obj
      yield "終了" :> obj
     ]
    PrintResult "元のデータ" source
    //人間が認識する情報（情報集合）には必ず名前が必要
    let filter ( x : obj ) = 
      match x with
        | :? ( string * obj) as s  -> ( fst s ).Length > 0
        |_ -> false 
    let map ( x : obj ) =
      let name, value = x :?> ( string * obj )
      new Data<obj>( name, value )
    let humanSet = new Info<obj, Data<obj>, Unit>( filter, map, None )
    let humanFunc = fun ( x : List<obj> ) -> x => humanSet
    //等価性が必要な情報
    let equalFilter( x : Data<obj> ) = 
      match x.Value with 
        | :? System.IEquatable<int> -> true
        | _ -> false
    let equalMap( x : Data<obj> ) = 
      new Data<int>( x.Name, x.Value :?> int )
    let equalSet = 
      new Info<Data<obj>, Data<int>, obj>( 
        equalFilter, equalMap, Some( humanFunc ) )
    let data = source => equalSet
    PrintResult "等価情報集合" data
    //終了
    0

等価性を持つ要素がそろえば集合演算ができます。ただその前に、「素朴集合は要素の重複を認めない」という前提があるから、もう一つの情報集合である「重複なし情報集合」の定義が必要です。

情報集合論（仮名） 集合演算を考える

　この記事は、自分用のメモです。べき演算を考える際に、集合演算そのものの性質について考えてみます。素朴集合論の専門書では集合演算が、何の証明もなく定義されていますが、集合演算の性質について検討する必要があります。素朴集合論にパラドックスが生じた要因の一つは、集合演算の性質そのものの考察が足りないからだと思います。
　一番簡単な和集合演算から考えます。和集合は任意の数の集合を合成します。和集合演算の効果は単純なのですが、そのまま聞き流してはなりません。何事にも前提というものがあります。前提を考えると、和集合は合成する集合が正しく、論理空間が必要です。論理空間がなければ、集合の等価性が定義できません。等価性が定義できなければ、演算の結果そのものが検証できませんので、等価性は非常に重要な条件です。また、論理空間がなければ、和集合の否定演算が定義できませんので、やはり和集合を包含する全体集合である論理空間が必要です。
　和集合が満たすべき条件は積集合演算も同じです。やはり、演算に参加する集合が正しく、論理空間がなければ演算が実行できません。差集合演算も同様です。ということは、べき集合演算にも論理空間が必要だとの考えに至ります。ただし、べき演算の結果を考慮すると、和集合と同じ論理空間だとは思えません。具体例をもとに、その点をよく考えねばなりません。
　X = { a, b, c }ならば、冪集合P(X)は{ φ, { a }, { b }, { c }, { a,b }, { a,c }, { b,c }, { a,b,c} }となります。冪集合P(X)に{ a,b,c }が含まれている点に注目します。この新しい集合の論理空間はなんでしょうか？素直に考えるのであれば、演算対象となる集合を含む集合ということになります。従って、べき集合演算は、論理空間となる全体集合を変える性質を持つ演算と言えると思います。冪集合の濃度は2の要素数乗ですから、この考察結果は正しいと思われます。
　

情報集合論（仮名） 型の設計

　この記事は、自分用のメモです。基本イメージでは普通に型を定義していましたが、むろん正式にすると型を設定するまでに考察する必要があります。前回のプログラムを情報集合論として、正式に定義すると以下のようになります。

//情報
type Info<'a, 'b, 'c>
  (
    f : 'a -> bool, //フィルター関数
    m : 'a -> 'b,  //マッピング関数
    parentGetDataFunc : ( List<'c> -> List<'a> ) option //親の関数
  ) =
  //フィールド
  let _filter = f
  let _map = m
  let mutable parentFunc = parentGetDataFunc
  member private this.Filter with get() = _filter
  member private this.Map with get() = _map
  member private this.PrentFunc with get() = parentFunc
  //親を考慮してデータを取得する
  static member (=>)( data : List<'c>, x : Info<'a, 'b, 'c> ) : List<'b> =
    let newData = x.PrentFunc.Value( data )
    newData => x
  //親を考慮しないでデータを取得する
  static member (=>)( data : List<'a>, x : Info<'a, 'b, 'c> ) : List<'b> =
    data
    |> List.filter x.Filter
    |> List.map x.Map

type Data( name : string, value : obj ) =
  //フィールド
  let _name = name
  let _value = value
  //プロパティ
  member this.Name with get() = _name
  member this.Value with get() = _value
  //メソッド
  override this.ToString() = _name + ":" + value.ToString()

[<EntryPoint>]
let main argv = 
    //テストデータを準備
    let source =
     [ 
      yield "実験データ" :> obj
      for i in 1..10 -> ( "正数", i :> obj ) :> obj
      for i in -10..-1 -> ( "負数", i :> obj ) :> obj
      yield "終了" :> obj
     ]
    printfn "元のデータ"
    let f ( x : obj ) = printf "%s " <| x.ToString()  
    List.iter <| f <| source
    printfn "\n"
    //人間が認識する情報（情報集合）には必ず名前が必要
    let filter ( x : obj ) = 
      match x with
        | :? ( string * obj) as s  -> ( fst s ).Length > 0
        |_ -> false 
    let map ( x : obj ) =
      let name, value = x :?> ( string * obj )
      new Data( name, value )
    let humanSet = new Info<obj, Data, Unit>( filter, map, None )
    let data = source => humanSet
    printfn "%s" "情報集合" 
    let f ( x : Data ) = printf "%s " <| x.ToString()
    List.iter <| f <| data
    printfn "\n"
    //終了
    0

名前も付けられないようなごみデータはふるい落とすということです。F#はもともと型システムがあるのでちょっと婉曲的な表現になりました。
　このプログラムで表したのは、フィルター条件の設定です。フィルターは必ず1つ以上の情報を除去するものでなくてはなりません。そうしないと、条件を付ける意味がありません。すなわち、必ず親集合の濃度は子集合の濃度よりも高くなります。これにより集合理論のパラドックスを防ぎます。
　しかしながら、集合論のパラドックスの解決法を明確に示すには、べき演算の性質を考える必要があります。分かっていることをいちいち示すのは骨が折れますが、自分の理論を検証するためにやるしかない。

情報集合論（仮名） 基本定義を表現

　この記事は自分用のメモです。基本イメージをはっきりさせるために、情報集合論の基本定義をF#で実装しました。

//情報
type Info<'a, 'b, 'c>
  (
    f : 'a -> bool, //フィルター関数
    m : 'a -> 'b,  //マッピング関数
    parentGetDataFunc : ( List<'c> -> List<'a> ) option //親の関数
  ) =
  //フィールド
  let _filter = f
  let _map = m
  let mutable parentFunc = parentGetDataFunc
  member private this.Filter with get() = _filter
  member private this.Map with get() = _map
  member private this.PrentFunc with get() = parentFunc
  //親を考慮してデータを取得する
  static member (=>)( data : List<'c>, x : Info<'a, 'b, 'c> ) : List<'b> =
    let newData = x.PrentFunc.Value( data )
    newData => x
  //親を考慮しないでデータを取得する
  static member (=>)( data : List<'a>, x : Info<'a, 'b, 'c> ) : List<'b> =
    data
    |> List.filter x.Filter
    |> List.map x.Map

//人間が認識する情報
type InfoSet<'a, 'b, 'c>
  (
    name : string, //識別するための名前
    f : 'a -> bool, //フィルター関数
    m : 'a -> 'b,  //マッピング関数
    parentGetDataFunc : ( List<'c> -> List<'a> ) option //親の関数
  ) =
  inherit Info<'a, 'b, 'c>( f, m, parentGetDataFunc)
  //エラーチェック
  do 
    if name.Length = 0 then 
      raise <| System.ArgumentException( "必ず名前を指定してください。" )
  //フィールド
  let _name = name
  //プロパティ
  member this.Name with get() = _name

[<EntryPoint>]
let main argv = 
    //テストデータを準備
    let source =
     [ 
      yield "実験データ" 
      for i in 0..10 -> i.ToString()
      for i in -10..-1 -> i.ToString()
      yield "終了"
     ]
    printfn "元のデータ"
    List.iter <| printf "%A " <| source
    printfn "\n"
    //人間が認識する情報（情報集合）には必ず名前が必要
    let humanSet = 
      new InfoSet<string, string, obj>( 
        "情報集合", ( fun x -> true ), ( fun x -> x ), None )
    let data = source => humanSet
    printfn "%s" humanSet.Name
    List.iter <| printf "%A " <| data
    printfn "\n"
    //終了
    0

F#は数学的なイメージを定義するのに向いています。個人的には数学の証明よりもF#プログラミングのほうが自分の考えを定義しやすい。

初心者のためのC#プログラミング本格入門107 - 例外の報告をキャッチしよう

　この記事は、初心者のためのC#プログラミング本格入門106の続きです。前回は、アプリケーションの種類に関係のないエラー通知方法「例外処理」について解説しました。今回は、報告されたエラー情報を受け取る手段について解説します。
　エラーを通知することを「例外をスローする」といいます。throwキーワードを使用しているから分かりやすいかと思います。スローされた例外を受け取るにはどうしたらいいのでしょうか？やはり、専用の構文を使用します。

class SimpleListTest : Test
{
    //元となるオブジェクト空要素を削除した時の、
    //Enumeratorオブジェクトの挙動をチェック。
    private void EnumeratorWhenRemoveElement()
    {
        base.Execute( );

        //任意の要素を準備
        int count = 10;
        for ( int i = 0 ; i < count ; i++ ) {
            this.target.Add( i );
        }

        //Enumerator取得後1要素を1つ消す
        this.ie = this.target.GetEnumerator( );
        this.target.Remove( );
        count = this.target.Count;

        //Enumeratorの個数をチェック
        int ieCount = 0;

        //例外がスローされるかもしれない処理をトライ（試みる）
        try 
        {
            while ( ie.MoveNext( ) == true ) ++ieCount;
        } catch ( System.InvalidOperationException e ) 
        {
            //例外をキャッチ♪
            System.Console.WriteLine( "例外スローされました。" );
            System.Console.WriteLine( e.ToString( ) );
        }

        if ( count != ieCount ){
            string message = 
            "Enumeratorと元のオブジェクトの要素数が一致してません。";
            base.Error( message );
        }
    }
}

文法はちょっと難しく見えるかもしれません。でも、やっていることは単純なので大丈夫です。tryキーワードで試して、catchキーワードで受け取ります。
　初心者の方は｛｝でプログラムがくくられているのが気になると思います。この理由は、｛｝はプログラムを塊で扱うからです。if文やwhile文でも｛｝を使っているから、それを思い返すと納得できると思います。
　さて、このサンプルを実行すると例外がスローされます。しかも、「System.InvalidOperationExceptionはハンドルされませんでした」などといったよくわからないダイアログ（画面）まで表示されます。慣れないとビックリするかもしれませんが、気にする必要はありません。「詳細を表示」という場所をクリックしてから、表示されている三角をクックして詳細な情報を見てください。その中に、StackTraceという項目がありますので、そこをよく読んでください。すると、どういった順序でプログラムが実行されたのかわかります。
　この問題を解決するには、プログラムの実行順序をもとに内容を理解します。答えを提示します。

class SimpleListTest : Test
{
    //foreachを模倣する
    public void ForeEachTest()
    {
        //準備
        base.Execute();
        for ( int i = 0 ; i < 10 ; ++i ) 
        {
            this.target.Add( i );
        }

        //これを追加
        this.ie = this.target.GetEnumerator( );

        //1 ～ 9 の数値が格納されているはず
        int x = 0;
        System.Text.StringBuilder error = 
            new System.Text.StringBuilder();
        ie.Reset();
        do {
            if ( ie.Current != x ) 
            {
                string message = 
                    "ForeEachTestで予期せぬ値が返されました。" +
                    "予想値：" + x +
                    " 返された値" + ie.Current +
                    System.Environment.NewLine;
                    error.Append( message );
                    base.Error( message );
            }
            ++x;
        } while ( ie.MoveNext() );
        if ( error.Length != 0 ) {
            base.Error( error.ToString() );
        }
    }
}

この件で分かったと思いますが、多くのエラーの解決法自体は簡単です。例外処理の便利さがわかってもらえると思います。
　初心者の方はまだ慣れないと思いますが、何度も使いますので安心してください。使っているうちに覚えます。

VBオブジェクト指向プログラミング講座 第17回 継承の種類を知ろう

　この記事は、第16回　継承の背景を知ろうの続きです。前回は、継承の概要を解説しました。今回は、継承の種類について解説します。
　継承といっても色々な意味があり、大別すると2種類存在します。インタフェース（メソッドの名前・戻り値の型・パラメーター）を継承（再利用）するのか、メソッド内のプログラムを継承（再利用）するのか、それにより継承の意味合いが異なります。VBプログラミングでは、インタフェースを実装するのか、親クラスを指定するのかで対応します。
　初心者の方は、この2つの継承はほとんど同じだと感じるでしょう。しかし、意味合いが全く異なります。どちらを使うのかによって、設計レベルで違いが生じます。ですから、同じプログラムを書くのは面倒だから、元からあるクラスを継承しようなどといった感覚で使用すると痛い目にあいます。継承を使用する際には、2つの継承を正しく意味を理解し、設計レベルで熟慮せねばなりません。
　インタフェースの継承（実装）は、同じ使い方ができる事を意味します。例えば、2つの整数を引数として受け取り実数を返す演算メソッドは、2つの整数を渡せば何らかの実数値を返すことを意味しています。他には、2つの座標を受け取り何も値を返さないMoveメソッドなどがありえます。
　実装の継承は、期待された振る舞いを行う事を意味します。意味はインタフェースの継承よりも難しく、親オブジェクトに期待されている事を実現することを意味します。この継承については、ある程度実務経験がないとわからないと思います。インタフェースの継承との違いは、より強くオブジェクトの定義にしたがう点にあります。
　インタフェース継承の場合は、メソッドレベルで求められていることをすれば済みます。しかしながら、実装の継承は、親オブジェクトが求められている条件を満たさないと矛盾が生じます。厄介なことに、VBコンパイラは人間が考えていることはわかりません。ですから、親オブジェクトの仕様と全く違う事をしてもエラーになりません。プログラマーがオブジェクトの仕様をよく考えて、実装の継承を行う必要があります。
　具体例を挙げると、子オブジェクトが親オブジェクトのメソッドをオーバーライドしたい場合、いくつかの事を考えねばなりません。親メソッドを内部で呼ぶべきでしょうか？呼ぶにしても、子オブジェクトが先に処理をするのでしょうか？親オブジェクトの処理を先にするのでしょうか？そういったカプセル化に反した判断をせねばなりません。
　今までの説明を読んで、「面倒なことを考えたくないからインタフェースの継承だけを使用する」と思った人が居るかもしれません。しかし話はそれほど単純ではありません。実装の継承は面倒な分、正しく設計した時の効果が非常に高くなります。何故ならば、同じようなプログラムを書く必要がなくなるので、生産性が高くなるからです。
　どちらの継承をするにしても、設計レベルで熟慮する必要があります。