ネタつつき144 - 文章における情報濃度

　文章は基本的なコミュニケーションですが、非常に奥が深いものです。文章の目的は、対象となる人達に情報を伝達する事です。まれに、自分を誇示するために文章を書く人がいますが、それは、双方向のコミュニケーションではありません。独りよがりなものです。相手に情報を伝えるのが本来の目的ですから、自分を誇示する必要は全くありません。伝えたい情報からしてみれば、書き手の自己顕示欲は不純物です。
　私は一応専門家ですから、専門分野についてはいくらでも情報濃度を高め、情報量を無限に増やす事が出来ます。専門家は知識を売る職業ですので、1つの文章で書ける量では務まりません。しかしそれは、目的からしてみれば、何の意味も持ちません。目的を果たさなければ何の意味もないのです。
　私は文章を書くとき、自我を殺すつもりで書いています。目的が第一ですので、邪魔にならないように、想定する読み手にあった人物像を描き、伝達したい情報だけを書きます。この歳に問題となるのは、主となる情報と補助となる情報の扱い方です。
　書こうと思えば無尽蔵に書けますから、油断すると一気に主となる情報が霞んでしまいます。ですから、主となる情報以外は、あっさりと書いた方がよいと考えています。例えば、ある特定のプログラミング技法を書くとき、OSに関する事はさらりと流します。OSは深く書こうと思えば、いくらでも濃くかけますが、そんな事をしてしまえば、主役はOSとなってしまいます。OSについて細かく書かれた文章を読んで、誰がプログラミング技法の文章だと思うでしょうか？
　重要なのは情報の濃淡です。主となる情報は濃く、かつ量を適度にします。それ以外の情報については、限りなく薄く、かつ量を少量にします。そうすれば、濃淡が鮮やかな文章となり、伝えたい情報が伝わる確率が高くなります。
　ただし、主となる情報を濃く書けばよいというものではありません。専門家が濃く書こうとすれば、一冊の本をかけます。しかしそれは、本として出すべき情報であり、コミュニケーションをとるという目的に合致しません。読み手に伝わらなければ何の意味もありません。
　これはコミュニケーション全般に言える事です。適切な場面、適切な情報濃度、適切な相手、それら全てが一致しないと情報は受け取ってもらえません。伝える相手をよく考え、相手に合わせて文章を書けるように練習しましょう。かくいう私も一生練習だと思っています。文章は奥が深く、終着地点はないでしょう。それでも向上心を持ち続け文章を書き続ければ、たとえ少しでも上達します。
　文章を書くと言う行為は、自己を押し殺し、伝えたい情報を伝える事だけを考えて書きましょう。文章には自己顕示欲は要りません。真心があればそれでいいのです。

VBオブジェクト指向プログラミング講座 第3回 クラスで情報を隠蔽する

　この記事は、「第2回 いきなり継承を使ってクラスを感じる」の続きです。前回は、クラスについて少しだけ解説しました。今回は、クラスを使う理由のうちの一つ、情報隠蔽について解説します。
　前回、モジュールを使うよりも、クラスを使った方がお得だと書きました。しかし、定義が面倒だからクラスを使うというのであれば、本当のオブジェクト指向プログラミングとは言えません。まだまだ、オブジェクト指向プログラミングの利点があります。
　解説のためにサンプルを提示します。

'EntryPoint.vb
Imports System
Imports System.Windows

Module EntryPoint

    <STAThread()>
    Sub Main(ByVal args As String())
        Dim app As MyApplication = New MyApplication()
        app.Run()
    End Sub

End Module

'MyApplication.vb
Imports System
Imports System.Windows

Public Class MyApplication
    Inherits Application

    Public Sub New()
        Dim win As HelloWindow = New HelloWindow()
        win.Show()
    End Sub

End Class

'HelloWindow.vb
Imports System
Imports System.Windows

Public Class HelloWindow
    Inherits Window

    Public Sub New()
        Me.Title = "Hello World"
        Me.Height = 300
        Me.Width = 300
        Me.WindowStartupLocation = WindowStartupLocation.CenterScreen
    End Sub

End Class

前回のサンプルよりも、MyApplicationクラスが増えています。これが、オブジェクト指向の概念と関係があります。
　オブジェクト指向プログラミングを行う理由の一つが、ロジックが分割されてソースコードが読みやすくなるというものです。サンプルコードの場合、スタートアップロジックが分割され、役割分担が明確になっています。つまり、処理を開始するモジュール、アプリケーションの定義、ウインドウがはっきりと分かれています。
　これは情報隠蔽（カプセル化）の概念を表しています。オブジェクト指向プログラミングでは、クラス（オブジェクト）単位でロジックを考え、他のオブジェクトの細かい情報を気にしません。こうすることにより、一つの物事に集中してプログラミングを行えます。
　意図的に情報を隠蔽することにより、ロジックやコード等の情報の結合度を弱めているのです。情報隠蔽の利点は、WPFのプログラミングをすれば分かると思います。もし情報が隠蔽されていなければ、1画面を表示するだけでも大量のプログラミングが毎回必要になります。誰しもそれは避けたいでしょう。オブジェクト指向プログラミングの利点は、普段意識しないレベルにまで浸透していると言えます。
　ちなみに、Applicationクラスを継承した独自の子オブジェクトを、定義するのはWPFプログラミングでよくやる事です。Applicationの子クラスを定義することにより、アプリケーションの管理を行いやすくできます。こういったオブジェクト指向プログラミングの手法は、慣れない人はコードが増えるだけだと感じるでしょう。しかし、本格的なプログラミングを行うと、自然とありがたみが分かります。続く。

VBオブジェクト指向プログラミング講座 第2回 いきなり継承を使ってクラスを感じる

　この記事は、第2回　オブジェクト指向プログラミングは必須知識の続きです。前回は、オブジェクト指向プログラミングの大切さを、少しだけ書きました。今回は、オブジェクト指向プログラミングの基礎、クラスについて解説します。
　VBの解説の伝統は、サンプルを提示して解説のスタイルです。そのスタイルを踏襲して、サンプルから始めます。

'EntryPoint.vb
Imports System
Imports System.Windows

Module EntryPoint

    <STAThread()>
    Sub Main(ByVal args As String())
        Dim win As HelloWindow = New HelloWindow()
        Dim app As Application = New Application()
        app.Run(win)
    End Sub

End Module

'HelloWindow.vb
Imports System
Imports System.Windows

Public Class HelloWindow
    Inherits Window

    Public Sub New()
        Me.Title = "Hello World"
        Me.Height = 300
        Me.Width = 300
        Me.WindowStartupLocation = WindowStartupLocation.CenterScreen
    End Sub

End Class

いきなり継承を使用したので驚いたかもしれませんが、Window（フォームみたいなもの）を継承して、プログラマーが独自のWindowを定義するのはよくある事です。現時点ではあまり気にしないでください。
　Meキーワードが多用されている点に注目して下さい。モジュールとクラスの違いは多々ありますが、この部分にも違いが見られます。モジュールは、プログラマーが定義していないメンバーは呼び出せません。一方クラスは、親が持つメンバーを子クラスから呼び出せます。この1点だけでもクラスは非常に便利だと言えます。
　今回はこれで終わりです。ちょっと物足りないと思いますが、情報を詰め込みすぎると読む方が大変なので少しずつ解説していきます。続く。

VBオブジェクト指向プログラミング講座 第1回 オブジェクト指向プログラミングは必須知識

　理由は知りませんが、VBを使用した本格的なプログラミングの資料が、あまり見当たらないので書く事にしました。今回の連載は、VBのユーザが不得意と噂される、オブジェクト指向プログラミングを題材に選びました。理由は、オブジェクト指向プログラミングの資料が、Web上にあまりないからです。これではVBの初心者が学習できません。噂が本当になってしまいます。どこまで解説できるか分かりませんが、たとえ少しでもお役に立てれば幸いです。
　いきなりですが、現代のプログラマーにとって、オブジェクト指向プログラミングは必須知識です。オブジェクト指向プログラミングが出来なければ、VBの能力を全く生かしていないと言っても過言ではありません。VBはヴァージョン7の頃から、本格的にオブジェクト指向プログラミングをサポートしています。ヴァージョン7の機能を使わずとして、VBを使っているとは言えません。今やVBはヴァージョン11(VS2010年の時のヴァージョン)です。4ヴァージョン前の機能は、きっちり使いこなしましょう。ちなみにヴァージョンは、コマンドラインでVBを起動すると確認できます。
　プログラミングの学習といえば、「Hello World」プログラムです。VBらしくビジュアルに「Hello World」してみましょう。空のプロジェクトで「Hello World」を作ります。

Imports System
Imports System.Windows

Module EntryPoint

    <STAThread()>
    Sub Main(ByVal args As String())
        Dim win As Window = New Window()
        win.Title = "Hello World"
        win.Height = 300
        win.Width = 300
        win.WindowStartupLocation = WindowStartupLocation.CenterScreen
        Dim app As Application = New Application()
        app.Run(win)
    End Sub

End Module

このプログラムは、System、System.Xaml、PresentationCore、PresentationFramework、WindowsBaseの各ライブラリが必要です。参照を追加しましょう。
　次回から、オブジェクト指向プログラミングの解説を開始します。お楽しみに。

実践的オブジェクト指向設計入門20

　この記事は、実践的オブジェクト指向設計入門19の続きです。前回は、プログラム中の位置による状態の表現について解説しました。今回は、今回は制御の実装の内の1つ、状態機械エンジンについて解説します。
　オブジェクト指向方法論OMTでは、状態機械エンジンを明示的に表現し、かつ実行するなんらかの手段を用意する事が提唱されています。これは難しい概念だと思います。情報科学を学習していない人にはピンとこないでしょう。
　簡潔に説明すると、動的モデルを状態機械で表現すると、オブジェクト指向分析を効直接的に表現でき、強いては（※）検証がやりやすいと言う事です。確かに状態の変移として捉える見方は有用です。
※長すぎて省略しているからちょっと強引になっています。
　しかしながら、情報科学について学習していない人は出来ないでしょう。そんな人は、インスタンスの状態遷移をよく分析して、その流れがスムーズになる設計を行うと考えて下さい。続く。

初心者のためのC#プログラミング本格入門93 - IEnumeratorインタフェースも実装しよう

　この記事は、初心者のためのC#プログラミング本格入門92の続きです。前回はIEnumerableインタフェースと、インタフェースについて書きました。今回はIEnumerableインタフェースと関係がある、IEnumeratorインタフェースについて解説します。
　System.Collections.Generic.IEnumerableを実装するには、System.Collections.Generic.IEnumeratorも合わせて実装しなくてはなりません。何故ならば、System.Collections.Generic.IEnumerableインタフェースが要求する、GetEnumeratorメソッドは、System.Collections.Generic.IEnumeratorとSystem.Collections.IEnumeratorを返すからです。ひとまず、宣言してみましょう。

class SimpleList : 
    System.Collections.Generic.IEnumerable<int>,
    System.Collections.Generic.IEnumerator<int>
{

これらのインタフェースが要求する定義を、実装するのは大変だと感じませんでしたか？幸いマイクロソフト社の開発環境はよくできています。カーソルをインタフェースの先頭部分に移動させクリックすると、ボックスが表示されるので、そこで「○○を実装します」という旨の選択肢が表示されます。それを選択すれば、自動的にコードが追加されます。

class SimpleList : 
    System.Collections.Generic.IEnumerable<int>,
    System.Collections.Generic.IEnumerator<int>
{
    public System.Collections.Generic.IEnumerator<int>
        GetEnumerator()
    {
        throw new System.NotImplementedException();
    }

    System.Collections.IEnumerator
        System.Collections.IEnumerable.GetEnumerator()
    {
        throw new System.NotImplementedException();
    }

    public int Current
    {
        get { throw new System.NotImplementedException(); }
    }

    public void Dispose()
    {
        throw new System.NotImplementedException();
    }

    object System.Collections.IEnumerator.Current
    {
        get { throw new System.NotImplementedException(); }
    }

    public bool MoveNext()
    {
        throw new System.NotImplementedException();
    }

    public void Reset()
    {
        throw new System.NotImplementedException();
    }
}

throw new System.NotImplementedException();は、「まだ実装されていないよ」という合図です。
　初心者の方は、定義の数に圧倒されてしまったかもしれません。でも、心配ご無用です。個々の内容は簡単です。少しずつ解説していきますのでご安心ください。

初心者のためのC#プログラミング本格入門92 - IEnumerableインタフェースを実装しよう

　この記事は、初心者のためのC#プログラミング本格入門91の続きです。前回は配列と同様にアクセスできるオブジェクトを、定義する文法「インデクサ―」について解説しました。今回は、よりコンテナらしいオブジェクトの作り方を解説します。
　インデクサ―を使えば、配列の様に[]で個々の要素にアクセス出来ます。しかし、それだけでは不十分です。コンテナ（オブジェクトを格納するオブジェクト）には他の特徴があります。それはforeachで使用できる機能です。配列とSystem.Collections.Generic.Listは、foreachループで使用できます。
　現在作成中のSimpleListも以下の様に出来れば、コンテナらしいと言えます。

SimpleList list = new SimpleList();
foreach( int l in list )
{
}

このプログラムを書くと、GetEnumeratorを定義していないと言う旨のエラーになります。エラーをなくすには、System.Collections.Generic.IEnumerableインタフェースを実装します。

class SimpleList : 
    System.Collections.Generic.IEnumerable<int>
{
}

親オブジェクトを継承する文法と同じですが、意味は違いますので注意して下さい。インタフェースの場合は、継承というよりも実装と言った方がふさわしいです。
　インタフェースは機能のセットを表すオブジェクトです。そして、インタフェースを継承するとは、自分で機能をプログラミングすることを意味します。親オブジェクトを継承すると、名前とシグネチャ（メソッドの名前とパラメータなどの定義）とプログラムが手に入ります。一方インタフェースは、プログラムは自分で作る必要があります。面倒に追われるでしょうが、プログラムを継承しない方が得な事もあります。その利点（お得さ）については、難しい概念なので少しずつ解説していきます。

オブジェクト指向プログラミングが奏でるレガシーコードとテストコードの輪舞曲

　オブジェクト指向プログラミングの利点は色々ありますが、今回はテストとの関係を書きます。オブジェクト指向プログラミングはテストを手助けします。
　オブジェクト指向言語のリファクタリングはしやすいが、非オブジェクト指向言語のリファクタリングがやりにくいとよく言われます。この原因は色々ありますが、テストがやり難いというのが大きな要因です。テストもなしにリファクタリングするなんて自殺行為です。考えられません。それ故に、醜いコードが放置されます。非オブジェクト指向言語で書かれたプログラムを保守する人は大変です。
　こんな時は、オブジェクト指向プログラミングを自分でするしかありません。だからといって、コンパイラがしている事を自分でするのも面倒です。「関数テーブルを作ってそれを呼び出す様にする」なんて事を、テストもなしにするのは自殺行為です。私はWindowsAPIプログラミングで多用しましたが、テストも書いていました。しかしテストが無いレガシーな状況で、それをするのは危険であり避けなればなりません。もっと簡単に出来る方法があります。表現を変えて考え方を使用すればいいのです。
　オブジェクト指向プログラミングの原点を、今一度考えてみましょう。オブジェクト指向プログラミングの核は、データ構造と関数の関係が逆転している点にあります。そこに注目すれば自ずと道は開けます。一番需要があるC言語の例を書きます。
　C言語の場合、重要なのはヘッダーファイルです。従って、ヘッダーファイルのリファクタリングをします。ヘッダーファイルならば、間違ってもコンパイラが手助けしてくれます。具体的には、ヘッダーファイル内の宣言を、データ構造視点で書き変えます。例えば、foo構造体を使用する関数群を、ひとつのヘッダーファイルに移動します。そして、コンパイルすれば、ヘッダーファイルの変更場所をコンパイラが教えてくれます。後は修正するだけです。
　ヘッダーファイルがデータ構造を基準でまとまっていれば、オブジェクト指向プログラミングの感覚でテストを出来ます。では、特別なデータ構造（構造体）を使用していないプログラムはどうすればいいのでしょうか？それについては、ちょっと難しいですがオブジェクト指向設計の考えを適用します。具体的には、パラメーターをよく観察して、新しい構造体を定義します。そして、関数の定義を変えます。最後にヘッダーファイルを変えれば、リファクタリングの準備が出来ます。リファクタリングの準備が出来たらこっちのものです。いくらでもリファクタリングの技法を応用できます。
　先に紹介したリファクタリング技法を私は、ヘッダーファイルの細分化と呼んでいます。じゃあ逆はあるのとかと思った人は鋭いです。ヘッダーファイルの統合化も考えています。こちらの技法は正しく逆で、関数を大まかに分類してから、ヘッダーファイルを構成します。次に、そのヘッダーファイルを参照させます。こうしておけば、後でヘッダーファイルをリファクタリングしても影響が少なくなります。
　今回紹介したC言語のリファクタリングテクニックは万能ではありません。しかし、便利なテクニックです。以上の様に、オブジェクト指向プログラミングは、オブジェクト指向プログラミング機能を持った言語に頼る概念ではありません。オブジェクト指向の概念をよく理解していれば、いかようにも応用できます。オブジェクト指向プログラミングを、言語の機能として捉えるのではなく、概念として習得しましょう。そうすれば、レガシーコードを前にしても恐れる必要がなくなります。

中の人の徒然草417

暑いが続いていますね。溶けそうなインドリです。
お盆休みを取っていたのですが、お盆って結構つかれる。
仕事中毒な私の場合、仕事をしていた方が疲れないような気すらします。
話しは変わりますが、Linuxもなかなかいいですね。私はDebianも少しだけ使っているのですが、Emacsを使うと結構、中毒になります。Windowsが一番好きですが、Linuxも結構いいですね。
EmacsはLISPを弄るまで凝っていないのですが、凝る人の気持ちが分かります。キーボードから手を離さないスタイルは、集中が途切れなくていいです。
WindowsもPowerShellがあるし、F#を使って自分で作ってもいいのですが、何故なんだろ？Windowsを使っていると自然とマウスも使ってしまいます。雰囲気の問題なのかな？それともWindows系アプリケーションのインタフェースが問題なのかな？
WindowsにもEmacsをインストールしているからもっと練習してみよう。そして、便利なツールをF#で作るのもいいかな。
タッチパネル式も悪くはないんだけど、キーボードから手を話したくない時があるのも確かです。要はどんな方法でも使用できるインタフェースが理想です。音声、キーボード、モーションキャプチャー、人工知能などを全て同時にやれば、凄い事になりそうです。未来のOSはこんな感じになるでしょう。

プログラマー「開発環境を全て立ち上げろ。
　それから、会社のイントラネットに接続して、仕事一覧をゲットしろ。」
OS「分かりました。」
プログラマー「今日の仕事は・・・げぇ沢山あるな。」
OS「げぇ？沢山？新しいコマンドですか？」
プログラマー「気にするな。仕事を難易度別納期別に並べろ。」
OS[了解しました。]
プログラマー「よし、タスクAを左モニターに表示、タスクBを右モニターに表示、
手元のタブレットに設計書を表示しろ。」
OS[了解。]
プログラマー「仕事リストにあるテストを順番に実行しろ。」
OS[了解。テストに失敗しました。]
プログラマー「？？？おかしいな・・・あれ？この設計書矛盾があるぞ。」
OS「設計書の論理チェックを実行します。結果は偽です。」
プログラマー「やはりそうか。担当者を呼び出してくれ。」
OS「電話します。つながりました。」
設計者「いきなりなんだい。こっちは忙しいんだ。」
プログラマー「設計書ID20103を見ろ。ID3057との結合部分でバグがあるぞ。
論理チェックをしたのか？」
設計者「すまん。それはお客様の要望による仕様変更だ。」
プログラマー「何？何時そんな事があった。」
設計者「30分ほど前かな。今丁度会議しているところだ。まだまだ変更されそうだ。」
プログラマー「会議中に俺と通話？さては人工知能だな。」
設計者「そうだ。どうせクレームが来ると思って用意しておいた。」
プログラマー「ちぇ、人工知能に文句を言っても仕方がない。」
設計者「用が無いようだから切るぞ。」
プログラマー「先ほど論理エラーが出た設計書に関するプログラムをすべて出せ。」
OS「げぇ、沢山あるな。」
プログラマー「覚えたのか！」

なんて事になりそうです。仕事量が増える事があっても減りそうもありません。不思議だな。ちなみにこの想像、足用キーボード、右手用キーボード、左手用キーボード、ディスプレイ（室内スクリーン）360度配置、音声入力機能ON、マウス無数（4次元モニターを指定）、開発用OSを起動です。こんな未来ちょっと嫌かな。でもやってみたい気もする。特に開発環境やOSを作る方は面白そうです。

初心者のためのC#プログラミング本格入門91 - 配列と同じ？インデクサ―を知ろう。

　この記事は、初心者のためのC#プログラミング本格入門90の続きです。前回は、配列とデータ構造について解説しました。今回は、配列と同様にアクセスできるオブジェクトを、定義する文法について解説します。
　配列と同様に[]記号で、オブジェクトに格納した要素にアクセスするためには、新しい文法であるインデクサ―を使用します。インデクサ―は、パラメーター付きプロパティとも呼ばれている文法です。パラメーター付きプロパティという表現はぴったりなので、そう考えてみればサンプルプログラムを一目見てわかると思います。

class SimpleList
{
    //インデクサ―の例
    public int this[ int index ]
    {
        get 
        { 
            return this.data[ index ];
        }
    }
}

thisキーワードとパラメーターに注意してみれば、プロパティを定義していると同じです。それ故に、パラメーター付きプロパティとも呼ばれているのです。パラメーターを定義している部分に注目して下さい。[]記号内にパラメーターを定義しています。thisキーワードとこの点に注目すれば、インデクサ―の記述が出来ます。
　インデクサ―を定義したので、早速テストプログラムを修正しましょう。

class SimpleListTest : Test
{
    //テストを完成させよう
    public void OneElementAdd()
    {
        //テキトーに要素を追加して確認してみよう
        base.Execute();
        this.target = new SimpleList();
        int value = 10;
        this.target.Add( value );
        
        //要素の数が増えているはず
        if ( this.target.Count != 1 )
        {
            string message = "要素追加後の要素数が間違っています。" +
                "追加処理が正しく行われていません。" +
                "予想値：1 返却値： " + 
                this.target.Count;
            base.Error( message );
        }
        
        //追加した要素は取り出せるはず
        if ( this.target[ 0 ] != value )
        {
            string message = "正しく値が追加されていません。" +
                "予想値：" + value +
                " 結果：" + this.target[ 0 ];
            base.Error( message );
        }
    }
}

プログラムを修正したら、テストを実行して下さい。テストが失敗してエラーが表示されます。
　新しい要素を追加した筈なのに、何故0が返されるのでしょうか？前回の内容を思い出して考えてみて下さい。配列は番号で管理されていて、0番目から数えます。と言う事は、格納する時の番号の指定がおかしいと分かります。
　こんな時はブレークポイントを設定し、実行中に止めて変数を見てみましょう。1番目に要素が追加されている事が確認できます。これを解決するには初期値を-1にするだけです。ただし、Countプロパティに注意せねばなりません。

class SimpleList
{
    public SimpleList()
    {
        this.data = new int[ 10 ];
        this.insertIndex = -1;
    }
}

テストを実行すると、今度はCountプロパティの値でエラーになります。配列は要素を0番から管理しているので、個数は1を追加せねばならない事が原因です。変数の意味と使用法をよく考える事が大事なのです。

class SimpleList
{
    private int insertIndex; //挿入場所

    public int Count
    {
        get { return this.insertIndex + 1; }
    }
}

今度はテストをパスします。ひとまず安心ですね。
　インデクサ―を使用すると、配列風のオブジェクトを定義できます。配列の様に、他のオブジェクトを格納、および管理をするオブジェクトの事をデータ構造もしくはコンテナと呼ぶ場合があります。新しい用語を覚えるのは嫌かもしれませんが、オブジェクトの性質が分かりやすいと言う理由でまだ使用するのでぜひ覚えておきましょう。この様なオブジェクトをプログラミングすると、プログラミングの深い理解につながります。
　インデクサ―を使用すると、配列とほぼ同じだと感じたと思います。しかし、本当はまだ機能が足りません。次回はさらに配列の様なオブジェクトにしていきます。お楽しみに。