設計技法

複数通貨のMoneyをジェネリクスで作る

凪瀬 — Tue, 19 May 2009 00:54:00 GMT

Kanazawa.processではテスト駆動開発入門を読んで、テスト駆動開発を学びました。その本でのテスト駆動開発のサンプルとして挙がっていたテーマは複数通貨のMoneyを作るというものでした。

Dollarという米ドルを表現するオブジェクトを作り、Francというスイス・フランを表すオブジェクトを作り、そしてMoneyというオブジェクトに統合していくというリファクタリングの過程を経ています。

これをジェネリクスを使って設計したらどうなるでしょうか。

public abstract class Money<T extends Money<T>> { public abstract T add(Money<?> m); }

Moneyオブジェクトに演算用のメソッドadd()を定義します。引き算や掛け算など要求に合わせて各種用意するといいでしょう。

Money<T extends Money<T>> という型変数の宣言方法は自己言及するジェネリクスの稿で取り上げた手法です。add()の戻り型をTとしておくことで具象型自身の型を返させることができます。

これをDollarやFrancでオーバーライドして実装します。

public class Dollar extends Money<Dollar> { @Override public Dollar add(Money<?> m) { // ... } }

こうすることで、Dollarのadd()はDollar型で返るわけです。しかし、これだけだとDollarやFrancといった通貨単位ごとにadd()の実装を施さねばなりません。 protectedなファクトリーメソッドを用意して、オブジェクトの生成を具象型に委譲することでスーパークラスであるMoney型で統一的にadd()を記述することができます。

public abstract class Money<T extends Money<T>> { /** 為替レート */ Map<Class<? extends Money<?>>, Map<Class<? extends Money<?>>, Double>> rateMap; /** 値 */ protected double value; /** 加算メソッドの共通実装 */ public T add(Money<?> m) { double rate = rateMap.get(this.getClass()).get(m.getClass()); return getInstance(this.value + m.value * rate); } /** 具象型の生成 */ protected abstract T getInstance(double value); /** コンストラクタ */ protected Money(double value) { this.value = value; } }

こうした手法で通貨単位ごとに型を作って何が嬉しいかと言えば、ドル建てである場所にスイス・フランの型が紛れ込んだ場合にコンパイルエラーにすることができるという点です。

設計にはいろんな手法がありますし、それぞれにメリット、デメリットがあるので要求に合わせて柔軟に選べるようにしたいものですね。

ソフトウェア品質の12の属性

凪瀬 — Tue, 03 Feb 2009 08:36:00 GMT

システム開発において「品質の向上」という標語がしばしば掲げられますが、「品質の属性」については無頓着なケースが多いのではないでしょうか。

ひとくちに品質といっても多様な属性があります。顧客と品質の話で揉めたことはありませんか？品質には多様な属性があり、単一の軸で良しあしを決められないという側面があります。そのため、単に「品質」と言ってしまうと認識に齟齬が生じるのです。

Karl E. Wiegers氏が著書「ソフトウェア要求」で挙げた、すべてのプロジェクトが検討すべき12の属性は以下のとおりです。

可用性	availability	動作可能時間の指標。システム故障までの平均時間MTTF(Mean Time To Failure)を平均修復時間MTTR(Mean Time To Repair)とMTTFの合計で割った値。稼働率とも呼ばれる。
効率性	efficiency	同じ処理性能を出すのにどのぐらいのハードウェアのスペックが必要か。
柔軟性	flexibility	機能拡張への柔軟性。順次拡張していくアジャイル開発を可能にするためにはある程度の柔軟性を備えた設計にする必要がある。
完全性	integrity	データが正確で完全であること。改ざんなどされておらず、正しく動作すること。情報セキュリティの目標事項のひとつとして挙げられる。
相互接続性	interoperability	他システムとのデータ連携の容易さ。
保守性	maintainability	バグの修正や仕様変更の容易性。
移植性	portability	ある稼働環境から、別の稼働環境へ移行させるために要する工数など。 JavaなどにみられるVM方式など高レイヤでの稼働システムは移植性が高いとも言える。
信頼性	reliability	特定の期間、故障なしでソフトウェアを実行できる可能性。
再利用性	reusability	プログラムコードの再利用性。オブジェクト指向などによるモジュール化によって高めることができる。もっとも、日本だとソースコードが納品先の所有になる契約となることが多くライセンスの問題で再利用性が低い。
堅牢性	robustness	耐障害性。異常データなどの入力に対する耐性。
試験性	testability	テストのしやすさ。
使用性	usability	ユーザビリティ。使いやすさ。

これらは多くのプロジェクトに共通する属性ですが、もちろんこれで全てと言うわけではなく特定ジャンルではさらに追加の品質属性を考慮する必要が出てきます。同じ本から引用すると「組み込みシステムに重要な品質属性としてはさらに安全性、導入容易性、サービス能力があります。スケータビリティは、インターネットアプリケーションに重要なもう一つの属性です。」ということになるでしょう。

これらの品質属性は、すべてを同時に上げることができません。トレードオフが発生するのです。

品質属性のトレードオフ

これら品質の属性は、相互に作用し合っています。ある属性を高めれば他の属性も高まる、あるいは低くなるということがおきます。以下の表は左側の属性を上げた場合に上側のどの属性が高く、あるいは低くなるかを表しています。（追記：引用元「ソフトウェア要求」228ページ）

	可用性	効率性	柔軟性	完全性	相互接続性	保守性	移植性	信頼性	再利用性	堅牢性	試験性	使用性
可用性								＋		＋
効率性			－		－	－	－	－		－	－	－
柔軟性		－		－		＋	＋	＋			＋
完全性		－			－				－		－	－
相互接続性		－	＋	－			＋
保守性	＋	－	＋					＋			＋
移植性		－	＋		＋	－			＋		＋	－
信頼性	＋	－	＋			＋				＋	＋	＋
再利用性		－	＋	－	＋	＋	＋	－			＋
堅牢性	＋	－						＋				＋
試験性	＋	－	＋			＋		＋				＋
使用性		－								＋	－

まずは品質には属性があることを顧客に伝えましょう。そして属性にトレードオフが発生することを理解してもらいましょう。

ソフトウェア工学と品質属性

ソフトウェア工学の数々の成果はこれらの品質属性にどう影響を与えたのでしょうか？

構造化プログラミング

試験性 - 適切なモジュール分割は試験性を高めます。より高めるにはステートレスな機能を意識的に分割することです。ステートレスな関数は引数と戻り値によって容易にテストでき、自動テストなどによる自動化も行いやすくなります。
再利用性 - 構造化によりある程度、再利用性が高まりました。

契約に基づくプログラミング

完全性・堅牢性 - モジュール間での「契約に基づくプログラミング」のほつれに対して適切にエラー処理を施すことで完全性・堅牢性を高めることができます。

オブジェクト指向

柔軟性・保守性 - オブジェクト指向によって動的なフローチャートになるプログラムを容易に制御できるようになりました（ポリモフィズム）。これを活用することで、既存箇所に手を入れることなく追加のクラスを作成するだけでの拡張が可能になります。
再利用性 - 構造化プログラミングよりさらに再利用性を高めることができます。ポリモフィズムを活用したプログラミングは再利用性の点でも優れています。

VM技術、仮想化技術

移植性 - Javaの標榜する"Write once, run anywhere"は究極の移植性と言えます。現在のJava開発は主にWindows機上で行われており、そのままUnix系のOSで稼働する本番機で動作させるようなことが行われています。携帯電話におけるJavaMEの採用もこの点を活用してのことです。

O/Rマッピング

移植性 - O/RマッピングもDBを特定製品に縛らないという意味で移植性を高める効果があります。

DIコンテナ

柔軟性・保守性 - DIコンテナによる設計は柔軟性・保守性を高めます。
試験性 - DIコンテナによる疎結合は試験性をより高めます。DBなどを伴うシステムですら、スタブによって自動テスト化することが容易になりました。

ここでは目立つ特徴をピックアップしましたが、もちろん品質属性への影響はここに挙げただけにはとどまりません。各種パラダイムを眺める際に、品質属性への影響と言う点でみつめるとまた違ったものが見えてくるかもしれません。

次世代のカプセル化手法

凪瀬 — Wed, 07 Jan 2009 21:48:00 GMT

「interfaceに物申す」 (1) (2) (3) は、public, protected, privateといったアクセス制御の修飾子によるカプセル化の限界を憂いたものです。

そもそもこれらの修飾子はクラスを境界としたカプセル化であるため、デザインパターンなどクラス群で表現されるモジュールの内外の境界でのカプセル化には無力です。 Javaではパッケージプライベートというアクセス制御レベルも存在しますが、モジュール境界とパッケージ境界を一致させることが現実的ではないことはご周知のとおりです。こうしたクラス群で表現されるモジュールに対して、カプセル化を行うための新たな機能が求められているわけです。

そこでスーパーパッケージ(superpackage)という概念が提唱されました。これはJSR 294として仕様の策定が行われており、Java7で搭載される見込みです。 (http://www.infoq.com/news/2009/01/java7-updated参照)

スーパーパッケージについては http://journal.mycom.co.jp/articles/2007/05/13/superpackage/ が比較的詳しいかと思います。

アーキテクチャ選定を考える

凪瀬 — Sun, 28 Sep 2008 14:15:00 GMT

アーキテクチャ選定ではメリットとデメリットを考えるではフレームワークやアーキテクチャの選定は合目的でなくてはならない、ということを言いましたが、「システムの贅肉」という曖昧な概念を説明できていませんでした。

なんとなくイメージはできるんだけど、論理的な定義をうまくあたえれていない…。

骨格＝要件の大きさ

まず、確認しておくことは、システムの規模そのものの大きさです。要件定義・要件開発において、スマートになるように要件を決めよう、という話題ですね。

お客さんに「ちょっとここはこうなるようにしてほしい」とか言われたときに気にするのがこの点。今の設計に無理なく乗るなら軽く「いいですよ」と返せるところですが、その一見小さく見える事象に対応するために骨格がいびつになるような場合は悩んでしまいますね。

さて、そんな要件開発ですが、絶対値というか、要求される事象の大きさの下限は決まっていて、目的を達成するために必要な最低限の骨格を作るだけでも、とても大きな骨格になってしまうものもあります。

ネズミかゾウかではなくて、肥満か筋肉質かだろうが言っているのはこの骨格の大きさと、プログラミングのまずさからくる贅肉を混同するな、ということですね。

体の大きさ＝実装の大きさ

要件を実装するにあたって、実装手段によってソースコード、つまるところ実装の大きさが異なります。大雑把にいえばステップ数ですね。 (ステップ数という単位は誤差が酷いのであまり使いたくないですが、プログラムの大きさと正の相関を持つのは事実)

成長の早さ＝リリースまでの期間

システムを完成させるまでの期間、というのはゾウなりネズミなりが成人するまでの期間に相当するでしょう。

ゆっくり時間をかけて成長（プログラミング）が進み、完成までに数年の歳月を費やすシステムもあれば、非常に高速で成長しわずかに数か月で稼働にこぎつけるシステムもあることでしょう。

一般には、小さなシステムの方が、リリースまでの期間は早く、大きなシステムほどリリース時期は遅い。

養育費用＝開発コスト

成人までの間にどれだけの費用を投入したのかという数値ですね。

成人後の成長＝アジャイル性

アジャイルなシステムというのは成人が早い。割と未熟なうちにリリースしてしまう。リリース後の成長も大きく、成人してからも代謝が高いのですね。

対してウォーターフォール式のシステム開発などは、成人後にほとんど成長は止まってしまう。下手をすると成長などまるでなくて、「老後の介護」にばかり手間がかかるということもありえるのです。

代謝を高めるための設計手法と言うのもあります。こうした後の変更がある場合にそれは活きてくる。でも、いざそのときが来ない限りはそうした設計の良さというのは日の目を見ない。ソフトウェアの保守性はアップサイドリスクであるで言ったのはそういう事情のことなのですね。

寿命＝システムの寿命

システムは改修をしつつ、使われるわけですが、やがて寿命を迎えます。死因はさまざまですが、

土台となるOSやミドルウェアが死んだ
要求の変更に対応できなくなった

というのが大きいかなと思います。

システムというのは設計時に、いろんな前提条件を加味します。こういう部分は変更が容易なように、この辺は変えなくてもよい、とかいろいろ。「全部対応できるように」だといくらカネがあっても足りません。

それらの前提が覆ってしまったとき、それがシステムが死ぬべき時だと私は考えます。

贅肉・筋肉＝？？？

さて、問題となるのがここですね。「実装の質」と言いたいところですが、ひとことに「質」と言っても質にも種類があるので混乱しやすい。

例えば、高い処理効率（パフォーマンス）をたたき出すようなカリカリにチューニングされたソースコードというのは、変更に対してとても弱い。柔軟性に欠けるわけですね。

逆に抽象化を施し、仕様変更などにも柔軟に対応できるようなコードというのはパフォーマンスで劣る。柔軟だけど速度は遅い。

なので、これらのメリット・デメリットを考えた上で適度なところでバランスする必要があります。赤筋（反応が遅いが持続力がある）と白筋（反応が速いが持続力がない）みたいなもんですね。ハンマー投げの室伏広治氏は白筋が多く、マラソンは苦手だというエピソードもあります。状況を見て合致する「質」を選ばなくてはいけない。

ただ、一見して贅肉と分かるものも中にはあって、

コードクローン。要するにコピー＆ペーストによって冗長なコードになっている状態
構造化がうまくされていない
データ構造が非効率

といったところはかなり目立つ贅肉ですね。データ構造が悪いと、それを処理するプログラムも煩雑になって贅肉が贅肉を呼ぶ状態。

こうした、明らかな贅肉はそぎ落とすことでコードが数分の一になることがありますが、経験則からして1/10を超えない。どんだけ贅肉で太らせようとても骨格が支えられないほどには大きくなる前にシステムが破たんするのではないかと思います。人間の体重も世界記録では700kgぐらいらしく、限界までいっても10倍そこそこのようですね。

体脂肪を落とす効率

システムの贅肉を落とし、体脂肪率を10%にするためのコストと、体脂肪率10%から1%に落とすコスト、1%から0.1%に落とすコストが概ね等しいと思います。(無責任な社会、限定責任な社会から着想)

まぁこれは概念的な話なので数字が正確かというと怪しいのだけども、指数関数的だよね、というのは理解いただきたい。過度なダイエットは費用ばかりが嵩むので、ほどほどの贅肉は許容せざるをえないというわけです。

とはいえ、このほどほどの贅肉はコードが数分の一に縮むほどの贅肉じゃない。人間だって体脂肪率が0%になることはないでしょう？多少の脂肪に病的に神経質になっても仕方がない。

合目的なアーキテクチャ選定

フレームワークやアーキテクチャの選定は合目的でなくてはならない。そこで取り上げられる評価軸は「小規模 - 大規模」なんて単純な1軸ではないわけです。

システムの骨格の大きさ：要求事項の絶対値
システムの実装の大きさ：ソースコードの量
リリースまでの期間：開発速度
リリースまでのコスト：開発生産性
リリース後のコスト：可変性
システムの寿命

「時間、品質、料金」のうちから、2つを選択できる、なんてジョークがあるのですが、示唆深いと思いませんか？

これらのうち、何を活かして何に目をつぶるのか、その比率はどの程度にするのかというのが、アーキテクチャ選定で悩む部分です。小さなシステムは、使い捨てにすることもできる。リリースまでの期間が短くコストも小さいなら、定期的に使い捨てにするという方法論もアリでしょう。過去のリソースを使いたいからCOBOLで開発というのもコスト・リスクが見合うならあるいはアリでしょう。

コンセプトは前提条件の上に繰り広げられるものです。コンセプトだけ聞くと「ないわー」と思うようなことでも、特定のシチュエーション下では「そうせざるを得ないね」という合理的なものであったりするのです。

目的があってその実現手段としてアーキテクチャを選ぶのですから、アーキテクチャ単体だけを取り上げて安易に良しあしと言ってはいけない。

出来ることなら、技能あるチームで今風のアーキテクチャで今風の設計をするようなシステム開発をやりたいものですね。

アーキテクチャ選定ではメリットとデメリットを考える

凪瀬 — Thu, 25 Sep 2008 23:16:00 GMT

アルゴリズムであるとか、アーキテクチャというのは、必ずメリットとデメリットがあります。

プログラマは前提条件に合わせてメリットが活き、デメリットは表に出ないように考えアルゴリズムの選定します。アーキテクトがフレームワークやアーキテクチャを選定する時も同等です。

「大規模プロジェクトではどうするか」を考えるより、「大規模にしないためにはどうするか」を考えようというエントリに対し、私はネズミかゾウかではなくて、肥満か筋肉質かだろうと答えたわけですが、さて、では筋肉質なシステムとはどんなシステムか？という話になります。

思うに、筋肉質なシステムというのは、選定したアーキテクチャなり、フレームワークなりのメリットが活き、デメリットが隠れるようになっている、そんなシステムのことではないでしょうか。

だから、それが例えばCOBOLで新規開発という話だったとしても、「過去資産を活用する」というメリットが大きく、その過去資産の活用のための工数がデメリットにならず、過去資産を流用することで未来の保守の工数が嵩むといったデメリットもでない、というなら筋肉質と言えましょう。

通常は、このメリット・デメリットを秤にかけて、相応にメリットが大きいという状況でないといけないわけで、東京海上の例では、本当にデメリットは小さいの？と疑問に思うわけです。

さて、ではJavaのフレームワークの中ではすっかり枯れた技術という評判のStrutsはどうなのでしょうか？Strutsは初出が2001年と古く、近年のAJAXなどの対応を盛り込むにはマッチしないフレームワークだと私は評しています。非同期通信を伴わない、単純なWebシステムで工数を抑えて機能を量産するというなら、それなりにメリットは活きるでしょうし、デメリットは隠れるのではないかと思います。

これはStrutsに限らず、PHPやRubyでの開発でも、状況によってはメリットは活きず、デメリットが表出することになります。そうしたミスマッチな選択をしたプロジェクトは、その無理から脂肪のような無駄なソースが膨らみ、デメリットだらけとなってしまうことでしょう。私が選定するならFlexなどのリッチクライアントとかかなぁ。ユーザ容貌的にそちらの方がマッチして贅肉が少なくなる気がしますね。

ソートをしないで並び替え

凪瀬 — Tue, 15 Jul 2008 09:22:00 GMT

ゆの in Javaとかに嵌って放出が遅れましたが、ソート祭りの話題。

非破壊で順序を変更してとりだす

GoFデザインパターンのIteratorパターンを用いて元になるListには手を加えずにソートと同じような効果を得るサンプルです。

public class SortIterator<T> implements Iterator<T>, Iterable<T> { /** ソート対象 */ private Iterable<T> target; /** ソート用Comparator.この実装を変えることで並ばせ方を変えられる */ private Comparator<T> comparator; private T preElement; private List<T> equalValues; /** * コンストラクタ * @param target ソート対象。SetやListなどを渡すことができる * @param comparator 並ばせ方を決めるComparatorの実装 */ public SortIterator(Iterable<T> target, Comparator<T> comparator) { this.target = target; this.comparator = comparator; this.equalValues = new ArrayList<T>(); } @Override public boolean hasNext() { T min = null; targetLoop: for (T elem : this.target) { // 前回までに返した値より小さいものは飛ばす if (this.preElement != null && this.comparator.compare(this.preElement, elem) < 0) { continue; } // 前回と同じ値のものは、重複を確認してすでに返した値なら飛ばす if (this.preElement != null && this.comparator.compare(this.preElement, elem) == 0) { // 参照の同値性で判断するために敢えてcontains()は使わない // contains()だとequals()による比較になるため for (T value : this.equalValues) { if (value == elem) { continue targetLoop; } } this.preElement = elem; this.equalValues.add(elem); return true; } // 前回までに返した値より大きいもののうち、最小のものを探す if (min == null) { min = elem; continue; } if (this.comparator.compare(min, elem) < 0) { min = elem; } } if (min == null) { return false; } this.equalValues.clear(); this.equalValues.add(min); this.preElement = min; return true; } @Override public T next() { return this.preElement; } @Override public void remove() { throw new UnsupportedOperationException(); } @Override public Iterator<T> iterator() { return this; } }

これを以下のように呼び出します。

List<Integer> list = new ArrayList<Integer>(); list.add(new Integer(3)); list.add(new Integer(1)); list.add(new Integer(4)); list.add(new Integer(2)); list.add(new Integer(1)); SortIterator<Integer> ite = new SortIterator<Integer>(list, new Comparator<Integer>(){ @Override public int compare(Integer o1, Integer o2) { return o2.compareTo(o1); } }); for (int i : ite) { System.out.println(i); }

出力結果は

1 1 2 3 4

ちゃんと整列していますね。

解説

このクラスではソート対象のIterableと比較に用いるComparatorを保持して hasNext()のたびに今までに返した値より大きいもののうち一番小さいもの、つまり「次に小さい奴」を探してnext()でそのオブジェクトを返します。

最初に「データをちょうだい」と言われた時に「一番小さい奴」を探して返し、「次のデータをちょうだい」と言われたら「次に小さい奴」を探して返し、 …。

でも、それで利用側から見ると並び変わったように見えるんですね。

設計に利用するヒント

Listの中身そのものを並び替えた方が効果的なシチュエーションの方が多いかもしれませんが、一時的に他の並び方を使いたいという場合はIterator側に並び替えを仕込むのも一つの手です。

これは非破壊であることがメリットで、複数のスレッドからオブジェクトの持ついろんな属性での並び替えを並列に取得することもできます(その間に元のListが変更されると動きがおかしくなりますが…)。

そういう意味ではImmutableパターン、つまりオブジェクトを変更不可能にすることで並列時の安全性を確保するようなケースで有用です。

データを利用する人が多岐にわたる場合、自分の都合だけで並び替えるわけにいかないかもしれません。そのような場合に、外付けでデータの順番が変わったように見せる手法があることを知っておくとうまい設計を起こすヒントになるかもしれません。

外から利用する分には中のデータの表現方法なんて隠蔽されていて関心の外ですから、必要になった時に自転車操業的に「次に小さい奴」を探して渡す、でも大丈夫なんですよね。

サニタイズとハンガリアンとヒューマンエラーとアスペクト指向

凪瀬 — Sun, 06 Jul 2008 18:34:00 GMT

このあたりの話題は、個々のプログラマに対して「気をつけろ」と注意喚起してもなくならない話題なのですが、その背景的な部分をば少し。

サニタイズは消毒足り得ない

sanitize = 「無害にする」、という英単語ですが、≒ sanitate 「消毒する」と紹介されることが多いですね。でも、この消毒という比喩は文学的ではあるけども、技術的には問題のある比喩に思います。 XSS(Cross Site Scripting、クロスサイトスクリプティング)への対処として言われることが多いですね。

現実の消毒というのは、過剰に繰り返しても問題はなく、消毒済みのものをそのままもう一度消毒しても構わない。なので、食品衛生的な現場では過剰なぐらいに「とりあえず消毒」というスタンスでやるわけです。

これに対しプログラム上やりたいことというのは「その場の文脈でメタ文字となる文字をエスケープすること」 ( 続・「サニタイズ言うなキャンペーン」とはより)なわけで、例えば対HTMLでのエスケープ処理として"&"といった記号を"&"と置き換えたりするような処理です。これは何度でも行える「消毒」ではなく、 正しい場所で一度きりしか実行してはいけない「変換処理」なんですよね。

しかし、プログラムにおけるエスケープは消毒とは違ってあくまで「変換処理」ですから、 正しい場所で一度だけ、しかも漏れなく行う必要がある。そして、その場所というのが、「HTMLを出力する場所全て」というどうやって網羅するんだよ、と言いたくなる広範な個所なのですね。

ハンガリアン記法

話は変わってハンガリアン記法。 Jittaさんの言う「型によるハンガリアン（システムハンガリアン）使うな」の話です。

Wikipediaでも見てもらうと掴めると思うのですが、"iWindowHeight"みたいに、変数名の頭に型を表現する情報を付加すると言う記法です。

この記法、Javaなどの強い型付けの言語の場合、プログラム上の「型」と変数名での「型」と冗長になるんですね。そしてプログラムでの「型」はコンパイル動作で機械的にチェックされるので型の相違などは検出・修正できるわけでバグとなっていつまでも残るようなことはないわけです。そして、この冗長を常に保つことの難しさというのが欠点として挙げられていて、メリットがないということが言われている。

ハンガリアン記法を保つためには、「全ての変数を宣言する箇所で」網羅的に命名を確認する必要があります。そしてソースコードを修正する際に「型を変更する全てのケース」で網羅的に変数の命名も直さなくてはならない。

ヒューマンエラー

例えば、小学生低学年向けの、算数のドリルをやるとしましょう。算数の足し算を延々とやるわけです。算数の足し算ぐらいは誰でもできますね。では、1万問のドリルで全問正解してください、と言われたら「そんなの簡単だよ」と言えるでしょうか？

これは単純で簡単な作業であっても、人間はなんらかの間違いを犯すと言うことです。「うっかりして」の「うっかり」なのです。

あなたがチームリーダーだとしましょう。10人のメンバー全員に1万問のドリルで全問正解させるにはどうしたらいいでしょうか？この「うっかり」に対して「気合いを入れて」とか「集中して」とか精神論を掲げても、確実性が上がるわけではありません。

俗にサニタイズと呼ばれる処理も、ハンガリアン記法も、原理を理解して対処することは難しくはない。 (いや、サニタイズ言うなキャンペーンはその原理の理解がされていないことを憂いてのキャンペーンだったか…) 算数ドリルのような話題です。ただし、その数がべらぼうで、「うっかり」間違えることもあるというものです。

10人分の計算ドリルをあなたが検算することで全問正解を目指すとしましょう。あなたは検算を間違えないでやりとおせるでしょうか？「うっかり」検算を間違えたりしないでしょうか？ XSSの話題というのはこの個々は簡単な作業なのだけども、漏れなく実施しそれを保証するのが難しいというところが本題です。そして一か所でも漏れがあるとそれでセキュリティホールになる可能性があるって言うんだから嫌になる。

ハンガリアンでもやはりきっちりと網羅して行うことの難しさというのがあって運用に堪えない。

こうした部分にはヒューマンエラーがするりと入り込んでくるので頭が痛い問題です。

アスペクト指向というパラダイム

拙稿アスペクト指向の概念でおおむね解説しているわけですが、アスペクト指向では「全てのXXに全部YYをする」という事象を扱います。これをアスペクト、「横断的関心事」と呼ぶわけです。上記、挙げてきた件を解決しようという試みなわけですね。

このアスペクト指向というのはOOP(オブジェクト指向プログラミング)の概念とぶつかるものではなく、相補的なものと言えます。

AOP(アスペクト指向プログラミング)に対応した言語では、関数のようなものを作って、この処理を「全てのXX」に差し挟む、ということが記述できます。この「全てのXX」という部分にOOPでのオブジェクトなどが用いられたりするわけです。

また、AOP対応言語でなくとも、設計のパラダイムとしてのアスペクト指向というのはあって、 OOPでのデザインパターンでProxyパターンというものがありますが、これは、 Proxyするオブジェクトで前後に処理を一律に差し挟むことを可能とする。アスペクト指向的な概念に対してOOPの枠内でできる対処法のひとつなんですね。

XSSに代表されるように、横断的関心事というのは人間の手作業ではヒューマンエラーとも密接に関わって非常に対処しにくい。 AOPはプログラミングのパラダイムとしてだけではなく、開発体制をいかに構築するか (私はこれをシステムを構築するプログラミングの仕事と類似する事項と思っています) という部分にも応用することができる。

日常の開発の中で、こうしたアスペクトを捉えて、それを一網打尽にするジョインポイントはどこか、そう考えると見えてくるものがいろいろあるのです。

Seaserのホットデプロイとリフレクション

凪瀬 — Tue, 17 Jun 2008 15:39:00 GMT

Seaserのホットデプロイは開発向けにはなかなか便利ですが、これを使えるようにフレームワークの構成を考えるのはかなりしんどいものがあります。今回はハマったポイントとしてリフレクションを取り上げます。

Seaserのホットデプロイ

Seaserのホットデプロイは実行時に特定箇所でクラスローダを毎回新しくするというシンプルなものです。

結構、割り切った作りになっているなぁというのが感想ですが、そのシンプルさと原理からいろいろと制限事項も生まれてしまう。

今回、私がハマったところはフレームワーク内でリフレクションをする際に、クラスローダの違いからClassCastExceptionを出したり、NoSuchMethodExceptionを出したりしたことでした。

クラスローダの基礎知識

まず、基礎知識としてクラスローダが違う場合、同じClassでも代入互換性がありません。Classの同一性は、Class自身とそのクラスローダによって定められます。

次に、クラスローダは階層構造をなしていて、まず親クラスローダにロード処理が移譲されます。

ClassLoader

ClassLoader クラスは、委譲モデルを使ってクラスとリソースを探します。ClassLoader の各インスタンスは、関連する親クラスローダーを持ちます。クラスまたはリソースを見つけるために呼び出されると、ClassLoader インスタンスはそれ自体でクラスまたはリソースの検索を試みる前に、その検索を親クラスに委譲します。「ブートストラップクラスローダー」と呼ばれる仮想マシンの組み込みクラスローダーはそれ自体では親を持たず、ClassLoader インスタンスの親として動作します。

このため、親が同じである場合は、同じクラスローダ(つまるところ親)で読み込まれることで代入互換を持つことがあります。

クラスローダを跨ぐ場合のClassCastException

Seaserのホットデプロイは HotdeployUtilのstart()とstop()の間でクラスローダが変わることで実現しています。

なので、この区間の中と外ではクラスローダが異なります。そのため、戻り値のClassCastExceptionが発生することがあります。

SingletonS2ContainerFactory.init(); S2Container container = SingletonS2ContainerFactory.getContainer(); HotdeployUtil.start(); Object o = container.getComponent("testLogic"); System.out.println(o.getClass().getClassLoader()); Hoge hoge = (Hoge)o; HotdeployUtil.stop();

log4j:WARN No appenders could be found for logger (org.seasar.framework.container.factory.S2ContainerFactory). log4j:WARN Please initialize the log4j system properly. org.seasar.framework.container.hotdeploy.HotdeployClassLoader@6e70c7 Exception in thread "main" java.lang.ClassCastException: test.logic.impl.TestLogicImpl cannot be cast to test.Hoge at test.LoaderTest.main(LoaderTest.java:19)

こうした再読込をおこなうタイプのクラスローダは親クラスローダへの委譲を行わないことで実現できます。親へ委譲してしまうと読み込み済みのクラスをリフレッシュすることができません。

しかし、この場合、クラスローダ越境ができなくなります。通常は、親への委譲を先に行うことで、共通して読み込まれるクラスには互換があったわけですが、クラスをロードしなおすために、親への委譲を行わないようにすると、上記例のようにClassCastExceptionとなってしまうのです。

リフレクションの際のメソッドシグネチャにも注意！

こうしたクラスローダを跨いだ箇所でリフレクションを行っていると、わかりにくいバグに遭遇することがあります。

SingletonS2ContainerFactory.init(); S2Container container = SingletonS2ContainerFactory.getContainer(); HotdeployUtil.start(); Object o = container.getComponent("testLogic"); Method[] ms = o.getClass().getMethods(); System.out.println(Arrays.toString(ms)); Method m = o.getClass().getMethod("setHoge", Hoge.class); HotdeployUtil.stop();

log4j:WARN No appenders could be found for logger (org.seasar.framework.container.factory.S2ContainerFactory). log4j:WARN Please initialize the log4j system properly. [public void test.logic.impl.TestLogicImpl.setHoge(test.Hoge), public test.Hoge test.logic.impl.TestLogicImpl.getHoge(), public native int java.lang.Object.hashCode(), public final native java.lang.Class java.lang.Object.getClass(), public final void java.lang.Object.wait(long,int) throws java.lang.InterruptedException, public final void java.lang.Object.wait() throws java.lang.InterruptedException, public final native void java.lang.Object.wait(long) throws java.lang.InterruptedException, public boolean java.lang.Object.equals(java.lang.Object), public java.lang.String java.lang.Object.toString(), public final native void java.lang.Object.notify(), public final native void java.lang.Object.notifyAll()] Exception in thread "main" java.lang.NoSuchMethodException: test.logic.impl.TestLogicImpl.setHoge(test.Hoge) at java.lang.Class.getMethod(Unknown Source) at test.LoaderTest.main(LoaderTest.java:24)

ご覧のように、setHoge(Hoge)が存在しているにも関わらず、NoSuchMethodExceptionが投げられsetHoge(Hoge)はない！と言われてしまうのです。これは、getMethod()の引数に渡すHoge.classと、読み込まれたコンポーネントのHoge.classでクラスローダが異なるためです。

開発用と割り切って全体を囲ってしまう

クラスローダの越境は非常に厄介ですので、処理の頭からお尻までまるごとクラスローダを差し替えるように使うのが無難です。

Servletであれば、ホットデプロイ用の HotdeployFilter が用意されていますのでそちらでリクエストの全体で差し替えるほうがよいでしょうね。

ジェネリクスを最大限活用するための設計技法 Stateパターン編

凪瀬 — Thu, 05 Jun 2008 21:17:00 GMT

今回はStateパターン編です。 Stateパターンはオブジェクト指向のポリモフィズムで動きを切り替えるという点で前回の Strategyパターンと同じです。

ただし、Stateパターンはそのインスタンス自身が「状態」を表現するという点で異なります。

電卓のUIのStateを作る

まず、Stateの使いどころですが、ここでは以前にわんくま同盟で取り上げられた電卓を例にしてみましょう。

επιστημηさんのところに電卓を状態遷移で捉える話題がでていたのですが、この状態遷移というのがStateパターンの使いどころになります。

電卓基本動作の状態遷移表

初期状態数値入力状態数式作成状態計算結果表示状態

数字入力なにかする
→数値入力状態なにかする
→数値入力状態なにかする
→数値入力状態なにかする
→数値入力状態

演算子入力なにかする
→初期状態なにかする
→数式作成状態なにかする
→数式作成状態なにかする
→数式作成状態

'='入力なにかする
→初期状態なにかする
→計算結果表示状態なにかする
→計算結果表示状態なにかする
→計算結果表示状態

'C'入力なにかする
→初期状態なにかする
→初期状態なにかする
→初期状態なにかする
→初期状態

電卓基本動作の状態遷移表
	初期状態	数値入力状態	数式作成状態	計算結果表示状態
数字入力	なにかする →数値入力状態	なにかする →数値入力状態	なにかする →数値入力状態	なにかする →数値入力状態
演算子入力	なにかする →初期状態	なにかする →数式作成状態	なにかする →数式作成状態	なにかする →数式作成状態
'='入力	なにかする →初期状態	なにかする →計算結果表示状態	なにかする →計算結果表示状態	なにかする →計算結果表示状態
'C'入力	なにかする →初期状態	なにかする →初期状態	なにかする →初期状態	なにかする →初期状態

この、「初期状態」「数値入力状態」「数式作成状態」「計算結果表示状態」がStateパターンではオブジェクトのインスタンスで表現されます。そして、そのクラスには「数字入力」「演算子入力」「'='入力」「'C'入力」の4つのメソッドが定義されます。

Java/** @param <R> Stateの具象型 */ public interface State<R extends State> { /** 数値の入力 * @return 遷移するState. 以下同じ */ R onInputNumber(int num); /** 演算子の入力 */ R onInputOperation(Operation ope); /** '='の入力 */ R onInputEquale(); /** 'C'の入力 */ R onInputClear(); }

C#public interface State<R> where R : State { /// <summary>数値の入力</summary> /// <returns>遷移するState. 以下同じ</returns> R onInputNumber(int num); /// <summary>演算子の入力</summary> R onInputOperation(Operation ope); /// <summary>'='の入力</summary> R onInputEquale(); /// <summary>'C'の入力</summary> R onInputClear(); }

より抽象的にすることで再利用性を持たせる

通常のStateパターンだと、この時点で具象型を用いるのでジェネリクスの出番はないところですが、 電卓と同じユーザインターフェースを持つ別のアプリケーションを作れるようにジェネリクスで抽象化しておきます。

ご覧の通り、各メソッドは処理をした上で次に遷移するべきStateを返すようになっています。このときに自信の型を返したいので自己言及するジェネリクス( Java版、 C#版) で取り上げた手法を用います。

これらの実装を作る際にはジェネリクス(サンプルソースのR)を具象化するわけですが、この型は電卓用であれば電卓用、同一UIを用いた別の何かであればそれ用に独自に拡張します。 電卓用のStateと別の何かのStateは混同して利用されることはありません。

つまり、このUIを共通に提供するような再利用性の高いフレームワークを設計する場合でないと、このようなStateパターンの多様な拡張性を持たせると言う設計は活きてこないのです。

逆に、このようなジェネリクスを活用することで、今まで再利用が不可能だと思っていたパーツを再利用可能な形でライブラリとすることができます。

補足

Javaの場合はさらに Strategyのインスタンスをenumで扱うで取り上げたように、Stateのインスタンスをenum化することができます。

ジェネリクスを最大限活用するための設計技法 Strategyパターン編

凪瀬 — Fri, 30 May 2008 17:59:00 GMT

前回は振りだけでしたが、今回からデザインパターンとの絡ませ方を紹介してきます。

Strategyパターンの実例

Strategyパターンの実例として java.lang.Comparator および System.Collections.Generic.IComparer によるソートを取り上げます。

Strategyパターンによって切り替わるのは、ソートのアルゴリズムではなく、二つのオブジェクトの比較方法です。ここではUserというオブジェクトを想定してみます。

Javapublic class User { public String name; public int age; }

このUserのListがあるとして、これを名前(name)順にソートするのか、あるいは年齢(age)順にソートするのかといったことをStrategyパターンで切り替えるわけです。

そのためのStrategyのインターフェースが先に挙げた java.lang.Comparator および System.Collections.Generic.IComparer となるわけです。

これらの実装クラスをStrategyとしてソートのメソッドに渡すことで、ソート処理の動きを切り替えることが出来ているわけです。

Java Strategyの実装public class UserNameComparator implements Comparator<User> { public int compare(User user1, User user2) { return user1.name.compareTo(user2.name); } }

Java ソート処理の呼び出し List<User> list = new ArrayList<User>(); list.add(new User("ABC", 10)); list.add(new User("BCD", 12)); list.add(new User("CDE", 8)); Collections.sort(list, new UserNameComparator());

C# Strategyの実装 public class UserNameComparer : IComparer<User> { public int Compare(User user1, User user2) { return user1.name.CompareTo(user2); } }

C# ソート処理の呼び出し List<User> list = new List<User>(); list.add(new User("ABC", 10)); list.add(new User("BCD", 12)); list.add(new User("CDE", 8)); list.Sort(new UserNameComparer());

ジェネリクスによる具象化

さて、ここでジェネリクスによる具象化がどこで行われるかを見てみましょう。

まずはソート処理を呼び出す部分。こちらではListに入るオブジェクト型を明示しています。ここのソースコード状ではジェネリクス型パラメータは具象化されているわけです。

そして呼び出されたソート処理の中身、つまるところクラスライブラリ内では当然ながら StrategyであるComparatorやIComparerのジェネリクス型は具象化されない状態で処理されます。ですから、ソートのアルゴリズム中ではListのオブジェクトが何型かを意識してはいけません。動的にinstanceofとかで調べることはできますが、覗き見はしてはダメ。

そして、実際のStrategyの具象型部分。ここでは比較を行うオブジェクトは具体化されています。型が具体化されているのでキャストなどは不要で、Listに格納される型に合わせた処理をそのまま記述できます。

キセルのような中抜きの抽象化

ジェネリクスがない場合、Strategyの実装クラスでキャストしなくてはなりません。事実、ジェネリクス搭載前のJavaではそのようにコードを書かざるを得ませんでした。

ソートのアルゴリズムを抽象化したら、比較のアルゴリズムの引数まで抽象型(Object型)になってしまっていたのです。これをジェネリクスによって具象化することができるようになりました。

中間のソートのアルゴリズム中では型は抽象的に、呼び出し部分およびStrategyの実装部分では具体的にというわがままな抽象化がジェネリクスによって可能となったのです。