レベル: 初級 Teodor Zlatanov (tzz@iglou.com)Gold Software Systems
2002年 1月 01日 developerWorksの当連載記事は、Perlでのプログラミングの質を高めるための完結したガイドになるように構成されています。このシリーズの第5回となる今回は、オブジェクト指向プログラミングとは何か、それはどのような時に使用すべきなのか、また、Perlにおいてそれはどのように機能するのかという点についてTeodor Zlatanov氏が解説します。オブジェクト指向プログラミング (OOP) は、パワフルなプログラミング手法ですが、決して万能薬であるわけではありません。プログラマーはOOPの使い方を知ると同時に、どのような状況において、OOP以外の従来のプログラミング手法の方がより適しているのかを知る必要があります。PerlでのOOPの使用はいたって簡単です。C++ やJavaのような制約の厳しい言語とは異なり、PerlでのOOPには、状況に応じて生じるプログラマーに対する制約もごくわずかです。OOPは、すべてのプログラマーがそのツールキットに追加すべきものであり、また、Perlが解決できる問題の範囲を拡大する極めて便利な技法です。
オブジェクト指向プログラミング (OOP) とは
OOPは、プログラミング方法論、つまり、問題解決のための全般的なアプローチを指します。一方、アルゴリズムは、特定の問題を解決するための特定のアプローチを指します。OOPは、本来強固な方法論であり、手続き型および関数型のプログラミング方法論との間に壁を作ってしまう傾向があります。OOPと特にうまくかみ合うような組み合わせでない限り、これらとの連携はうまくいきません。この傾向は、Perlにおいてはそれほど強くないものの、依然としてはっきりと存在しています。
この記事では、関数型および手続き型プログラミングと比較しながら、PerlにおけるOOPの基礎について解説し、PerlプログラムとモジュールにおけるOOPの方法を紹介します。この記事はあくまで概説であり、PerlでのOOPに関してあらゆる側面を詳しく解説するものではありません。詳細な解説は、数冊分の書籍に匹敵する量になってしまいます。また、そのような解説書もすでに何冊か出されています。詳細な内容に関しては、この記事の末尾にある参考文献をご参照ください。
OOPとは、実際にはどのようなものか
OOPは、オブジェクトを用いた問題解決の手法です。プログラミング用語でいうオブジェクトとは、問題を解決するためのプロパティーと振る舞いを持つエンティティーを意味します。本当はもっと具体的な定義をすべきなのですが、今日のコンピューター業界には驚くほど多種多様なOOPのアプローチがあるため、このような定義しかできません。
OOPは、Perlプログラミングのコンテキストにおいて、その言語の使用に不可欠なものではありません。Perlバージョン5以降ではOOPが推奨されていますが、それでも、必須ということではありません。すべてのPerlライブラリーはモジュール化されていますが、これはPerlが、少なくともOOPの基本的な部分を採用しているということです。さらに、ほとんどのPerlライブラリーはオブジェクトとして実装されます。これはすなわち、明確に定義されたインターフェースを通じて、特定の振る舞いとプロパティーを持つOOPエンティティーとしてユーザーがそれらを使う必要があるということです。
OOプログラム言語の重要な特性
一般に、OOプログラム言語には、3つの不可欠な言語特性があります。それは、継承、ポリモーフィズム (多態性)、カプセル化です。
Perlは継承をサポートします。1つのオブジェクト(子)が別のオブジェクトを開始点(親)として使用し、そのプロパティーと振る舞いを必要に応じて変更する際に、継承が用いられます。この親子の関係によって、他のオブジェクトに基づくオブジェクトの作成が可能となるため、これは、OOPに不可欠なものです。この再利用という特性は、プログラマーに高く評価されているOOPのメリットのひとつです。
継承には、単一と多重という2つの種類があります。単一継承は、子が1つの親を持つ継承です。一方、多重継承はより自由であり、子が複数の親を持ちます。(これはプログラミングの世界の話であり、現実に何組もの両親がいたなら、大変困ったことになるでしょう。過大な解釈は避けるようにしましょう。)Perlは、多重継承をサポートしていますが、実際には、複数の親はめったに見られません。
ポリモーフィズム (ギリシャ語の「多形」が由来) は、ひとつのオブジェクトを別のオブジェクトに見せる手法です。これは、少し複雑であるため、例を使って説明しましょう。たとえば、皆さんが4頭の羊 (Ovis aries) のいる牧羊場を持っていて、さらに2頭の山羊 (Capra hircus) と1頭のジャーマン・シェパード (Canis lupis familiaris) を買ったとします。皆さんは今、何頭の動物を飼っているでしょうか。羊、山羊、犬の数を合計して、7という答が出るはずです。ここで皆さんは、ポリモーフィズムを使ったことになります。つまり、3種類の動物を1つの一般的な「動物」というカテゴリーとして扱ったということです。皆さんが、羊、山羊、犬を哺乳類としてまとめて考えたとすれば、これはいともたやすい思い込みともいえるでしょう。生物学者は常に、このようにポリモーフィズムを使っています。そしてプログラマーは、他の科学の優れたアイデアを「盗用」、いえ、「再利用する」のが得意なのです。
Perlにおいて、ポリモーフィズムは完全にサポートされています。Perlプログラマーは、継承された振る舞いを変更するのではなく、オブジェクト・プロパティーを使って総合的な振る舞いを変更することを好む傾向があるため、ポリモーフィズムはあまり頻繁には使われていません。これはつまり「ポート234のUDPパケット受信/送信」「ポート80のTCPパケット受信」「ポート1024のTCPパケット送信」に対応する3つのIO::Socket::INETオブジェクトを作成するコードが多く見られ、一方、それぞれにIO::Socket::INET::UDPTransceiver、IO::Socket::INET::TCPReceiver、IO::Socket::TCPTransmitterを用いるコードはあまり使われないということです。生物学で言えば、これは犬と山羊を単に哺乳類と言っているのと同じですが、山羊にはCapraフラグを立て、犬にはCanisフラグが立ててあるということです。
純粋なOOP主義者は、あらゆるものが適切に分類されるべきであると考えますが、Perlプログラマーは決して純粋なOOP主義者にはなりません。多くの場合、PerlプログラマーはOOPの規則に対して柔軟に構えることができ、純粋なOOP主義者よりも、比較的自由でいられます。
カプセル化とは、オブジェクトの作成者が許可する場合を除いてユーザーによるアクセスを拒絶するよう、オブジェクトの振る舞いとプロパティーを囲むことをいいます。これにより、オブジェクトのユーザーは、行うべきではない操作を行ったり、アクセスすべきではないデータにアクセスしたりすることがなくなり、トラブルを避けることができます。Perlは、やはり柔軟な形で、このカプセル化に対応しています。リスト1を参照してください。
なぜOOPは強力な方法論なのか
OOPがどのような点において強力な方法論であるのか、という話に戻りましょう。手続き型プログラミング (PP) および関数型プログラミング (FP) との組み合わせを難しくするいくつかの重要な概念がOOPにはあります。まず第一に、PPとFPにはクラスというものが存在しないため、PPとFPのいずれにも継承やクラスのポリモーフィズムという概念がありません。確かに、PPとFPにもカプセル化は存在しますが、それはプロシージャー・レベルに限られ、クラスまたはオブジェクト属性としてではありません。これらのOOPツールを使うと、プログラマーは通常、プロジェクト全般において互換性のない方法論を併用するのではなく、OOPのみを使用するようになる可能性が高くなります。
すべてのプログラムは、結局、命令の手続き型の実行であり、どんなに純粋なOOPであっても、すべてのOOPプログラムには、最初のオブジェクトを作成する関数 (メソッドとも呼ばれる) およびコードの中には手続き型コードが含まれている、という意見もあるでしょう。Javaのように純粋なOOPに近い言語であっても、必ずmain()関数を必要とします。したがって、OOPは単なるPPのサブセットに過ぎないようにも見えます。しかし、OOPをシーケンシャルな命令までに細分することは、システム・アーキテクトやプログラマーの関心はひきません。それは、どんな操作も結局はアセンブラー命令に細分されるのと同じことです。OOPはあくまでも方法論であって、それ自体が目的ではないのです。
OOPはオブジェクトを中心とし、手続き型プログラミングはプロシージャー (ここではプロシージャーはOOP手法を使わずに利用できる関数として、メソッドはオブジェクト内からしか利用できない関数として大まかに定義することにします) をベースとしているため、OOPと手続き型プログラミング方法論を組み合わせることは難しいことです。メソッドと同様、プロシージャーもユーザーによって呼び出される関数ですが、この2つにはいくつかの違いがあります。
プロシージャーには、連携するオブジェクト・データがありません。パラメーター・リストでデータを渡すか、あるいはその有効範囲でデータを使用しなければなりません。プロシージャーは、呼び出し中に渡されたデータにアクセスすることができ、また、プログラム全般でグローバル・データにもアクセスすることができます。メソッドは、そのオブジェクトのデータにしかアクセスしません。要するに、メソッドの関数有効範囲は通常、メソッドを含むオブジェクトになります。
多くの場合、プロシージャーはグローバル・データを使っていますが、本来はこれは絶対に必要な場合のみに限られるべきです。グローバル・データを使用するメソッドは、できる限り早急な再書き込みを必要とします。プロシージャーは通常、いくつかのパラメーターによって他のプロシージャーを呼び出します。メソッドにはわずかなパラメーターしかなく、他のプロシージャーよりも、他のメソッドへの呼び出しをはるかに多く行います。
関数型プログラミング (FP) は、いくつかの理由からOOPとは相性がよくありません。その最も重要な理由は、FPが問題解決のための詳細な関数型アプローチに基づいているのに対し、OOPはオブジェクトを使った概念の表現を行うということ、また、FPプロシージャーはどこでも使用できるのに対して、OOPメソッドはそれを保持するオブジェクト内からのみ使用できるという点です。
ここまでいろいろと説明してきましたが、ではこれから、Perlが、OOP、FP、PPの方法論の組み合わせに最も適した言語の1つである理由を説明しましょう。
PerlはOOPと手続き型/関数型プログラミングの組み合わせをいかにして行うのか
Perlは、柔軟な言語です。さまざまな方法で、またプログラマーにとって最も都合のよい方法でプログラマーの希望を実現します。この点において、PerlはJavaやC++のような言語とは全く対照的です。たとえば、変数が宣言されていない場合、Perlでは変数の自動作成も可能です (ただし、これは奨励されません。実際には強く推奨される「use strict」プラグマの使用によって代用できます)。皆さんが自分の首をしめて大変な思いをしたいのであれば、Perlはそのためのさまざまな道具を用意して声援をおくってくれることでしょう。
したがってPerlは、方法論の誤用を招きやすい言語であるとも言えます。でも、恐れることはありません。大丈夫です。たとえば、内部オブジェクト・データへのアクセス、稼動中のクラスの変更、稼動中のメソッドの再定義はすべて可能です。コーディング、デバッグ、実行の効率を上げるためであればプログラマーが規則を破ってもよい、というのがPerlのやり方です。それで目的を達成できるのであれば、それでいいのです。このようなわけで、Perl自体は、プログラマーにとって最良の友にも、最悪の敵にも、どちらにもなり得るのです。
OOP、FP、PPを組み合わせることが規則を破ることであるのにもかかわらず、なぜ皆それを行おうとするのでしょうか。少し、この問題について考えてみることにしましょう。OOP、FP、PPとは、一体何でしょうか。これらは、プログラミング方法論、概念の束、プログラミング・チームのための規則の積み重ねに過ぎません。OOP、FP、PPはツールであり、すべてのプログラマーが最初にすべきことは、そのツールを知ることです。ハッシュのソートを行う際にFP Schwartzianトランスフォームを使用できず、プログラマーが独自のSort::Hashtableを記述した場合、あるいは、システムのホスト名を取得する際に、Sys::Hostnameモジュールを再使用できず、手続き型コードを記述してそれを行った場合、そのプログラマーは時間、労力、コストを無駄にし、コードの質と信頼性を低下させていることになります。
プログラミング・チームは、最もよく知っているツールを使うことで満足してしまうこともありますが、これこそまさに起こりうる最悪の事態といえます。コンピューター・プログラミング業界のように激しく変化する革新的な業界においてごく一部のツールのみを利用し続けるということは、すなわち、そのチームが数年のうちに何もできないチームになってしまうということを意味します。効率の向上、コードの改善、チームの革新に繋がるものであれば、プログラマーはあらゆる方法論を組み合わせることができるべきなのです。Perlは、そのような態度を認め、奨励しているのです。
OOPのメリット
OOPのメリットはあまりに多岐にわたり、この記事ではとても扱いきれません。また、先に述べたように、このテーマについて多くの書籍が出版されています。OOPのメリットには、コード再利用の容易さ、コード品質の向上、一貫性のあるインターフェース、適応性、その他さまざまなものがあります。
OOPはクラスとオブジェクトを基としており、OOコードの再利用とは、必要に応じたクラスのインポートを指します。コードの再利用こそ、OOPを採用する最も重要な理由であり、OOPが今日の業界で重要視され、好評を博してきた理由です。
しかしここには、落とし穴もあります。たとえば、これまでの問題に対するソリューションが必ずしも現在の状況に最適なものとは限らず、十分な文書化がされていないライブラリーの場合、それを理解し利用するまでに、新しいコードを書くのと同じくらいの時間がかかってしまうことも考えられます。システム・アーキテクトは、こうした落とし穴を見極めて回避しなければなりません。
カプセル化によってデータ破壊(「フレンドリー・ファイアー」)が低減され、また、新たに記述すべきコードの量と複雑さが、継承とポリモーフィズムによって軽減されるため、コードの品質は向上します。コード品質とプログラミングの技術革新との間には微妙なバランスがありますが、それはチームの構成と目的に完全に左右されるため、そのチームに任せるのが最もよいでしょう。
OOPにおける継承と再利用は、コードにおける一貫性のあるインターフェースを促進します。しかし、それによってすべてのOOコードが一貫性のあるインターフェースを持つようになるわけではありません。プログラマーは依然として、全体的なアーキテクチャーに忠実でなければなりません。たとえば、(将来の拡張に対応し、極めて使いやすいモジュラー・インターフェースによる) エラー・ロギングのフォーマットとインターフェースに関するチームの合意が必要です。次のエラー・ロギング機能が現れたとき、彼らはインターフェースについて学んだことが無駄ではないことを実感します。そのようになって初めて、すべてのプログラマーは、その場限りのprintステートメントではなく、そのインターフェースを積極的に使うようになります。
適応性は、プログラミングにおいて、いくぶん捕らえどころのない概念です。私はこれを、環境と使用法の変化に対する受容と先取りと定義することにします。品質の高いソフトウェアにとって、適応性は重要です。なぜなら、周囲の環境と共に進化することが、すべてのソフトウェアに求められるからです。優れたソフトウェアには、すばらしい進化も要求されます。OOPでは、そのモジュラー設計、優れたコード品質、一貫性のあるインターフェースによって、オペレーティング・システムやレポート・フォーマットの変更も、根本的なアーキテクチャーを変更せずに行えるため、そのような進化がより促進されます。
PerlにおけるOOPの使用法
信じられないかもしれませんが、PerlにおけるOOPは、初心者や中級レベルのユーザーでも難しいものではなく、高度な使用法でもそれほど複雑ではありません。これまで、OOPの複雑な仕組みについて取り上げてきたため、皆さんはそれが信じられないかもしれません。しかしながらPerlには、プログラマーに対する制約をできる限り軽減するという傾向があります。PerlのOOPは、言ってみればバーベキューのようなものです。皆が各自の肉を持ち寄って、好みの焼き方で料理をします。また、関連性のないオブジェクト間での容易なデータ共有という、バーベキューにおける共同の精神もそこにはあります。
まず第一歩は、Perlパッケージを理解することです。パッケージは、C++ のネームスペースやJavaのライブラリーと類似しており、境界域はデータを特定の領域に囲い入れるようになっています。しかし、Perlパッケージは、プログラマーにとってアドバイザリに過ぎません。デフォルトでは、Perlにはパッケージ間のデータ交換に関する制約はありません (しかし、プログラマーは字句変数を使ってそれを行うこともできます)。
リスト1. パッケージ名、パッケージ切り替え、パッケージ間データ共有、パッケージ変数
#!/usr/bin/perl
# note: the following code will generate warnings with the -w switch,
# and won't even compile with "use strict". It is meant to demonstrate
# package and lexical variables. You should always "use strict".
# pay attention to every line!
# this is a global package variable; you shouldn't have any with "use strict"
# it is implicitly in the package called "main"
$global_sound = "
";
package Cow; # the Cow package starts here
# this is a package variable, accessible from any other package as $Cow::sound
$sound = "moo";
# this is a lexical variable, accessible anywhere in this file
my $extra_sound = "stampede";
package Pig; # the Pig package starts, Cow ends
# this is a package variable, accessible from any other package as $Pig::sound
$Pig::sound = "oink";
$::global_sound = "pigs do it better"; # another "main" package variable
# we're back to the default (main) package
package main;
print "Cows go: ", $Cow::sound; # prints "moo"
print "＼nPigs go: ", $Pig::sound; # prints "oink"
print "＼nExtra sound: ", $extra_sound; # prints "stampede"
print "＼nWhat's this I hear: ", $sound; # $main::sound is undefined!
print "＼nEveryone says: ", $global_sound; # prints "pigs do it better"
|
この例では、すべて同じファイル内で定義されているため、ファイル有効範囲の字句変数$extra_soundが、3つすべてのパッケージ(「main」、「Pig」、「Cow」)でアクセスできることに注目してください。通常、各パッケージはそれぞれのファイル内で定義されるため、字句変数はそのパッケージ専用のものです。このようにカプセル化が行われます。(詳細については、「perldoc perlmod」を実行してください。)
次に、クラスに対するパッケージの関連づけを行います。Perlに関する限り、クラスは単なる架空のパッケージに過ぎません (一方、オブジェクトはbless()関数によって実際に作成されます)。繰り返しますが、PerlではOOPの規則は緩和され、プログラマーがこれに拘束されないようになっています。
new()メソッドは、クラス・コンストラクターの標準的な名前です (ただし、Perl特有の柔軟性により、任意の名前を使うこともできます)。これは、クラスがオブジェクトにインスタンス化されると必ず呼び出されます。
リスト2. barebonesクラス
#!/usr/bin/perl -w
package Barebones;
use strict;
# this class takes no constructor parameters
sub new
{
my $classname = shift; # we know our class name
bless {}, $classname; # and bless an anonymous hash
}
1;
|
Barebones.pmという名前のファイルの中のリスト2のコードを任意のディレクトリーに置いて、そのディレクトリーから次のように実行すると(つまり「ライブラリー・パスに現行ディレクトリーを組み込み、Barebonesモジュールを使って新規Barebonesオブジェクトを作成すると」)、皆さんご自身でこのコードをテストすることができます。
perl -I. -MBarebones -e 'my $b = Barebones->new()'
|
たとえば、printステートメントをnew()メソッドの内部に置いて、$classname変数が保持するものを見ることもできます。
Barebones->new()の代わりにBarebones::new()を呼び出した場合には、クラス名がnew()に渡されません。つまり、new()はコンストラクターとしての役割ではなく、通常の関数としての役割を果たします。
なぜ$classnameを渡す必要があるのか、不思議に思えるかもしれません。なぜbless {}, "Barebones";ではいけないのでしょうか。継承があるので、このコンストラクターは、Barebonesから継承するクラスによって呼び出されますが、Barebonesでは呼び出されません。違うものに違う名前が付いていてよいと思われるかもしれませんが、それはOOPでは間違いです。
あらゆるクラスには、メンバー・データとnew()以外のメソッドが必要です。これらを定義することは、いくつかのプロシージャーを記述するのとあまり変わらないほど簡単です。
リスト3. メンバー・データとメソッドを持つクラス
#!/usr/bin/perl -w
package Barebones;
use strict;
my $count = 0;
# this class takes no constructor parameters
sub new
{
my $classname = shift; # we know our class name
$count++; # remember how many objects
bless {}, $classname; # and bless an anonymous hash
}
sub count
{
my $self = shift; # this is the object itself
return $count;
}
1;
|
このコードは次のようにしてテストすることができます。
perl -I. -MBarebones -e 'my $b = Barebones->new(); Barebones->new(); print $b->count' |
そして「2」という結果が得られるはずです。コンストラクターは2回呼び出され、各Barebonesオブジェクトではなく、Barebonesパッケージの有効範囲にある字句変数($count)を変更します。オブジェクトにローカルなデータは、そのオブジェクト自体に格納されている必要があります。Barebonesの場合には、それはオブジェクトとして認められた匿名ハッシュです。メソッドの呼び出しにおいて、オブジェクトにどのようにアクセスできるか注目してください。オブジェクトへの参照は、これらのメソッドに渡される最初のパラメーターです。
特定の条件下においてPerlによって自動的に呼び出される、DESTROY()、AUTOLOAD()のような、特殊なメソッドがいくつかあります。AUTOLOAD()は、動的なメソッド名を可能とする汎用メソッドです。DESTROY()はオブジェクト・デストラクターですが、どうしても必要な場合以外は、使うべきではありません。Perlでデストラクターを使うということは、皆さんがまだC/C++ プログラマーのような考え方をしていることの証拠になります。
では、継承について考えてみましょう。これはPerlでは、@ISA変数を変更することによって行われます。その変数にクラス名のリストを割り当てるだけでよいのです。それだけです。@ISAには何でも入れることができます。クラスをSatanの子にすることもできます。Perlはいたって自由であり、何でもよいのです (でも、皆さんの司祭、牧師、イマーム、ラビ等には怒られるかもしれませんが...)。
リスト4. 継承
#!/usr/bin/perl -w
package Barebones;
# add these lines to your module's beginning, before other code or
# variable declarations
require Animal; # the parent class
@ISA = qw(Animal); # announce we're a child of Animal
# note that @ISA was left as a global default variable, and "use
# strict" comes after its declaration. That's the easiest way to do it.
use strict;
use Carp;
# make your new() method look like this:
sub new
{
my $proto = shift;
my $class = ref($proto) || $proto;
my $self = $class->SUPER::new(); # use the parent's new() method
bless ($self, $class); # but bless $self (an Animal) as Barebones
}
1;
|
以上、PerlのOOPに関する本当の基礎について説明しました。この言語には、皆さんが学ぶべきことがまだまだたくさんあります。それらに関しては、優れた書籍が数多く書かれています。そのような書籍の一部を紹介していますので、参考文献をご覧ください。
h2xs: 新たな親友
Perlクラスの記述やドキュメンテーション (POD) スケルトンの作成ができ、皆さんをもっと楽にしてくれるようなツールがあったらよいと思いませんか。Perlには、h2xsという、まさにうってつけのツールがあります。
覚えておくべき重要なフラグは、「-A -n Module」です。これを使い、h2xsは、たくさんの便利なファイルを持つ「Module」という名前のスケルトン・ディレクトリーを生成します。これには、次のものがあります。
-
Module.pm、すでに記述されたスケルトン・ドキュメンテーションを持つ、モジュール本体
-
Module.xs、モジュールをCコードにリンクするためのもの(詳細については「perldoc perlxs」を実行してください)
-
MANIFEST、パッケージするためのファイルのリスト
-
test.pl、スケルトンのテスト・スクリプト
-
Changes、モジュールに対する変更のログ
-
Makefile.PL、makefile生成プログラム(「perl Makefile.PL」と共に実行します)
以上のファイルをすべて使う必要はありませんが、必要に応じて使えるということは心強いことです。
練習問題
- OOP、PP、FPにはどのような違いがありますか。
- OOプログラム言語に不可欠な特徴はどのようなものでしょう。それぞれがどのように使われているか例で示してみましょう。
- どのような場合にOOPが適していないでしょうか。
- オブジェクトにインスタンス化されたとき、固有のオブジェクトIDの一種として現行オブジェクト・カウントをそのオブジェクト自体に格納するクラスを
new()メソッドで記述してみましょう。これが良い方法である、あるいは良い方法ではない理由を説明してください。
- 皆さんの肉親の家系図を描いてみましょう。これはなぜ、OOPにおける継承と違うのでしょうか。OOPでは家族関係をどのように表現するでしょうか。
- すべてのオブジェクトが、すべてのオブジェクトの基本オブジェクトである単一ソースから継承しなければならないとすれば、どのようなプロパティー、メソッド、属性をその基本オブジェクトに入れますか。たとえば、すべての場合に固有IDを持たせるようにしますか。すべてのオブジェクトに対する基本オブジェクトは、なぜ必ずしもよい方法ではないのでしょうか。
-
h2xsによって生成されるファイルを注意深く見てみましょう。Makefile.PLは、Perlで実行に際して何を行いますか。その結果生成されるMakefileのターゲットを見てみてください。デフォルトで指定されているもののほか、test.plを使って簡単なテストを行ってください。
参考文献
著者について  | | | Teodor Zlatanovは1999年にボストン大学を卒業し、コンピューター・エンジニアリングで学位を取得しています。1992年以来プログラマーとして働いており、Perl、Java、C、C++などの言語を使用してきています。関心を持っている領域としてはオープン・ソース作業、Perl、テキスト構文解析、3層のクライアント/サーバー・データベース・アーキテクチャー、Unixのシステム管理などです。助言や間違いの指摘を歓迎しています。連絡先はtzz@bu.eduです。 |
記事の評価
| 
