国民宿舎はらぺこ 大浴場

• Excel列名変換問題で第２回社内プログラミングコンテストを開催してみた(前編) (ITは芸術だ)

問題1: Excel列名変換問題

• 仕様
  • 入力されたアルファベットを数字に変換する。
  • 変換ルールはExcelの列名と同等。
  • 例) A=1、B=2、Z=26、AA=27、XFD=16384

• 起動時引数
  • [0] アルファベット (A～ZZZZ...[上限なし])

• 実行例
  • ExcelColConv.pl A → 1
  • ExcelColConv.pl AA → 27

問題2: Excel列名変換問題(逆変換)

• 仕様
  • 入力された数字をアルファベットに変換する。
  • ただし、問題1で作ったプログラムを拡張すること。

• 起動時引数
  • [0] 0=数字へ変換、1=アルファベットへ変換
  • [1] 変換する数字またはアルファベット(どちらも上限なし)

• 実行例
  • ExcelColConv.pl 0 AA → 27
  • ExcelColConv.pl 1 27 → AA

90分はかからなかったけどなぁ… まぁ、時間なんてちゃんと測ってないけど。

use strict;
use warnings;

sub exCol2Num ($) {
    my $col = shift;
    $col =~ /^[a-z]+$/io or die "Invalid Excel colmun name '$col'";
    my $num = 0;
    for my $letter ($col =~ /[a-z]/igo) {
        $letter = uc $letter;
        $num = $num * 26 + (unpack('c', $letter) - unpack('c', 'A') + 1);
    }
    $num;
}

sub num2ExCol ($) {
    my $num = shift;
    $num =~ /^\d+$/io or die "Invalid number '$num'";
    $num == 0 and die "Can't convert 0 to Excel colmun name.";
    my $col = '';
    do {
        my $subnum = $num % 26;
        $subnum = $subnum == 0 ? 25 : $subnum - 1;
        $col = pack('c', $subnum + unpack('c', 'A')) . $col;
    } while (($num = int(($num - 1) / 26)) > 0);
    $col;
}

my ($mode, $input) = @ARGV;
my $result =
    $mode eq '0' ? exCol2Num $input :
    $mode eq '1' ? num2ExCol $input : die "Unknown mode parameter '$mode'";
print "$result\n";

まぁでもよい問題ですた。

• Togetter - 「派遣PG時代の思い出」

からリンクを辿って

• システムエンジニア 生き残りの極意: 実はオブジェクト指向ってしっくりこないんです！

を読み、ブクマで糞を投げてみたものの、年配の日本人プログラマーにおいては割とありがちな傾向なのではないかと思うところもあり、ちょっと書いてみようかしらとか思った次第。

オブジェクト指向にありがちな、それもとっても日本人的な誤解のひとつに、「オブジェクト = 物、物体」という解釈があると思う。確かに object という英単語には「物、物体」という意味があるのだけれど、実際には物体を表現しているわけではないオブジェクトについてまで、それを物体だと見立てて思考展開するんだ、と無理矢理自分を納得させながら Java や C# やその他のオブジェクト指向 (に対応した) プログラミング言語で頑張っている人って、実は若手でも少なくないんじゃないかと思う。

object という英単語には他にも「対象」や「目的、目標」などの意味がある。そのことを踏まえた上で、オブジェクト指向による設計について考えてみて欲しい。

例えば Window という名前のクラスがあるとする。このクラスの概要を説明する際、大抵の人は「ウィンドウを表すクラス」と書いてしまうのではないかと思う。これは多分、「オブジェクト = 物、物体」という前提をかなり意識した書き方だと思う。

あるいはポリモーフィズムを意識している人ならばもう少しマシに、「ウィンドウを表す基本クラス」などと書くかも知れない。そして派生クラスとして、FrameWindow があったり、 DialogBox があったり、はたまた見た目にも概念的にもウィンドウとは似ても似つかない FormControl なんてのがあったりするかも知れない。それでもこれらは「ウィンドウを表すオブジェクト」の一種をインスタンスとして生成するためのクラスとして扱われることになる。

まぁでもここまでは、それはそれでいいのかも知れない、とある程度納得できてしまうレベルの話なのかも知れない。フォーム部品もウィンドウの一種だと無理矢理納得することが、思考展開する上で圧倒的に不可能なことだとは思わない。でもそう思えるのは、これらは実行したときに、画面上で割と物体っぽく振る舞う概念だからなのではないか。

ちょっとしたゲームを作ろう、ということになって、その設計を考えたときに、そんなにたいそうなプログラムになるわけでもないし、ということで、実行時のシーンに応じてクラスを分けてみよう、と考えたとする。例えば以下の通りだ。

• GameTitle
• GamePlay
• GameOver

名前を見ただけで、これらのクラスの「役割」は理解できると思う。GameTitle クラスはゲームのタイトルを表示する。プログラム実行時に最初に呼び出されるシーンだ。GamePlay クラスは実際にゲームを遊ぶプレイ中の制御処理を行う。タイトル表示シーンから特定のコントロール操作 (「start」ボタンを押す、等) により呼び出される。GameOver クラスはゲームオーバーになったときに行われる動作だ。スコアを表示したり、ハイスコアランキングに登録したり、といった処理が考えられる。

そもそもこのような設計手法は妥当なのか? 現実問題としてこのプログラムを実行時のシーンに応じてモジュール分けすると言うことは十分考えられることなので、少なくとも手段のひとつとして絶対にあり得ないと言うことはないだろう。個人的にはこれはこれで十分アリだと思うが、実際の開発においてはチームで議論するなり、リーダーが自身のセンスに基づいて主導するなりすればよいことだ。閑話休題。

さて、これらのクラスの概要を書くとしたら、あなたはどんな風に説明するか? 「ゲームタイトルを表すクラス」? 「ゲームプレイを表すクラス」? 「ゲームオーバーを表すクラス」? どれもクラス名以上のことは書いていない。そろそろ、「○○を表すクラス」論法は無理が生じてきていると言えるのではないだろうか?

それよりも、「本クラスにおいて、」と前置きして (あるいはそう前置きされている物と仮定して)、「ゲームタイトルのアニメーション表示を実装する」、「ゲームプレイ中の中枢的な制御を実装する。具体的には以下の制御が対象となる: …」、「ゲームオーバーの処理を実装する。ハイスコアランキングの登録を含む」などと説明した方が、すっきりするだろう。

オブジェクト指向の「オブジェクト」とは、観念的に「物」や「物体」を表すことを指す、と考えるより、設計においてプログラムを個別の部品というかモジュールに分ける際に、そのモジュールが何を「目的」として実装されるのか、そのモジュールが「目的」としている「対象」は何なのか、をはっきりさせるための、プログラミング上での表現手法、と考えるべきだ。

生成されるインスタンスを観念的に「物」と言い表すことはできるかも知れないが、オブジェクト指向プログラミングにおいて重要なファクターは、必ずしもそこだけではないはずだ。「クラスもインスタンスも両者を含めてオブジェクトと言います」なんて説明で日本人プログラマーをはぐらかすのはもう止めよう。オブジェクト指向とは、プログラムを「目的」単位でモジュール化する手法である。その単位こそが (文字通り) クラスであり、従ってクラスの説明は実装の目的を記述することであるべきだ。

そのことを念頭に置き、そうした観念に頭が慣れるまでは、「オブジェクト指向」という語は封印し、代わりに日本語で潔く、「目的指向」と言い表すようにした方がよいのではないか、と提案する次第なのである。