asatoの技術的な日常日記

「成長に最大の責任をもつ者は、本人であって組織ではない。自らと組織を成長させるためには何に集中すべきかを、自らに問わなければならない」  非営利組織の経営 - ピーター・ドラッカー

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

コード進化パターン:列挙型への定数の追加

コード進化パターンを更新。

 Java におけるコード進化パターン

今回は、「列挙型への定数の追加」という単純なパターン。

コードの変化だけを書くなら、これだけ。

before:

public enum EnumType {
TypeA,
TypeB
}



after:

public enum EnumType {
TypeA,
TypeB,
TypeC
}




つまらない例に思えるけど、一つ議論するならば、このパターンが起こらない状況もあるってこと。どんな状況か。

sun の列挙型の例に載っているけど、たとえば、 季節を表す列挙の場合。


enum Season { WINTER, SPRING, SUMMER, FALL }



季節は普通四つしかないので、この列挙型に対する、定数の追加や削除の進化パターンはない。

この季節の例はわかりやすいけど、普通が通用しなくて、さらに進化パターンが許されていない状況もあるかもしれない。しかし、言語レベルで、許されていない進化パターンを制御する仕組みは無い。制御の仕組みがないということは、誤った進化が起こってしまうということ。

スポンサーサイト

コメント

expression problem

はじめまして。いきなりですが失礼します。
今回ご紹介の進化パターンはプログラミング言語研究の世界でいうexpression problemに近い気がします。データとそれを扱う関数を独立に追加できるか?(型安全性を保存したままで)という問題です。

関数型言語OCamlだとpolymorphic variantという機能を使えば、再コンパイル無しでうまいこと修正できます。

  • 2007/10/08(月) 23:52:24 |
  • URL |
  • とおりすがり #cgf6TkE.
  • [ 編集]

はじめまして。コメントありがとうございます。expression problem との関係性は想定外でした。今後再考してみます。

expression problem は、ある意味では、ある種のコード進化が難しいことを示す問題ではないかと思います。オブジェクト指向の場合、Visitor パターンを適用したクラス構造には、関数(ConcreteVisitor)追加の進化は容易ですが、データ(ConcreteElement)追加の進化は困難です。OCaml は使った経験が無いのですが、データと関数の追加の進化をうまく扱えるということかと思います。

しかし、今回の記事の焦点は、季節などの意味的な制約、もしくは設計の制約やルールとして、起こっていいコード進化とそうでないコード進化があることがあるということでした。そして、そのような制約を明示的に表現し、制約やルールの違反を確認できる(たとえばコードの編集時やコンパイル時に教えてくれる)機構が言語レベル、もしくは開発環境レベルで組み込まれていないのではないか、ということでした。

  • 2007/10/09(火) 01:55:50 |
  • URL |
  • asato #-
  • [ 編集]

>expression problem は、ある意味では、ある種のコード進化が難しいことを示す問題ではないかと思います。
まさにその通りだと僕も思います。

>起こっていいコード進化とそうでないコード進化があることがある
polymorphic variantを使ったこんな例は、どうでしょう(いきなりOCamlのコードで恐縮ですが):

type season = [<`Spring|`Summer|`Autumn|`Winter];;
この<記号(closeと読んで下さい)は、season型の値がたかだか上の4つしか取り得ないことを強制しますが、

type game_mode = [> `TITLE,`OPENING,`MAP_VIEW];;
この>記号(open)は、game_mode型の値は、この3つ以外の新たな値もあり得ることを示しています。

(ここで`記号はpolymorphic variantの値に付く特別な記号だと思って下さい)

season型については「コード進化が起こってはいけない」ことを、game_mode型については、「コード進化が起こり得る」ことを、プログラミング言語のレベルで制約できているんじゃないかなー、と、素人のアイデアのレベルですが、そう思います。


  • 2007/10/09(火) 02:39:43 |
  • URL |
  • とおりすがり #cgf6TkE.
  • [ 編集]

なるほど。OCamlではそんな表現ができるのですね。expression problem 中心に考えてしまったので勘違いしてしまったかもしれません。OCamlとpolymorphic variantについてはまた詳しく調べてみます。


とりあえず軽く調べても良く分からなかったは、

type season = [<`Spring|`Summer|`Autumn|`Winter];;

の場合、たとえば

type season = [<`Spring|`Summer|`Autumn|`Winter|'Hoge];;

と元のコードから変更することはできるのでしょうか?

あと、close として表されている場合は、新たに型(Hoge)を追加してはいけない、と読むのが正しいのでしょうか?

  • 2007/10/09(火) 03:50:33 |
  • URL |
  • asato #-
  • [ 編集]

コメントの投稿


管理者にだけ表示を許可する

トラックバック

トラックバックURLはこちら
http://asatohan.blog77.fc2.com/tb.php/76-48169eac
この記事にトラックバックする(FC2ブログユーザー)

FC2Ad

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。