こまどブログ

技術のこととか仕事のこととか。

ScalaとJavaにおける変位指定と型パラメータの境界

Scalaジェネリクスの勉強で、簡単なリストを実装してみよう!というものが出てきた。

詳細は省くが、リストのadd()メソッドは以下のように宣言される。

/* Scala */
abstract class SimpleList[+A] {
  def add[B >: A](element: B): SimpleList[B]
}

ここで、クラスの型の変位の指定として+A、つまり共変(covariant)であることが指定されている。また、add()メソッドでは、境界型パラメータによって対象の型(A)およびそのスーパークラス(B)を引数に取り、また戻り値はその型のリストとなることが指定されている。

本記事では、変位の指定と境界型パラメータについてScalaJavaを往復しながら見ていく。

ジェネリクスの変位

変位を指定できるのは、Javaジェネリクスにはない機能だ。Javaジェネリクスは不変(invariant)となっており、以下のような代入は許されない。いずれもコンパイルエラーとなる。

/* Java */
List<Number> listOfSuper = new ArrayList<Integer>(); 
List<Integer> listOfSub = new ArrayList<Number>();

これに対して、Scalaで変位(上の例の場合は共変)を指定した場合には、以下のような代入が可能になる。CatAnimalのサブクラス)をパラメータにとったSimpleList[Cat]を、AnimalをパラメータにとったSimpleList[Animal]に代入できる。

/* Scala */
class Animal(val age: Int)
class Cat(age: Int) extends Animal(age)
val listOfSuper: SimpleList[Animal] = new SimpleList[Cat](/* 省略 */)

一方、反変(-A)を指定した場合は、型パラメータに代入された型の継承関係とは反対の関係になる。つまり、スーパークラスを型パラメータにとった値を、サブクラスを型パラメータにとった変数に代入することができる(=サブクラスの値をスーパークラスの変数に代入できるのと反対)。また、不変(A)を指定した場合には、Javaにおけるジェネリクスと同様、型パラメータ同士の継承関係にかかわらず、別の型として扱われる。

Use-site variance と Declaration-site variance、境界ワイルドカード

Javaジェネリクスは不変だが、境界ワイルドカード型を利用することで、部分的に共変や反変類似の効果を起こすことができる。以下の例では、メソッド定義時に下限境界<? super A>を利用している。

/* Java */
abstract class SimpleList<A> {
  abstract SimpleList<A> filter(Predicate<? super A> predicate);
}

上記のように定義されたメソッドを実際に呼び出すとき、引数predicateにはAまたはそのスーパークラスを型パラメータにとったPredicateインスタンスを渡すことができる。再び、IntegerとNumberを例に示す。

/* Java */
SImpleList<Integer> list.= new Cons<>(1, new Cons<>(2, new Cons<>(3, new Empty<>()));
SimpleList<Integer> filtered = list.filter(
    new Predicate<Number> {
      @Override
      public boolean test(Number t) {
        return t.intValue() % 2 == 1;
      }
    });

上の例では、Integer型のリストのメソッドfilter(Predicate<? super A> predicate)に対して、Predicate<Number>*1インスタンスを渡している。これは、Predicate<Number>Predicate<Integer>として扱われうる(=反変)ということではなく、あくまで引数で受け取る側がいずれの型も受け入れているに過ぎない。このように、使用する箇所において変位を指定する方式を、Use-site varianceという。

これに対して、Scalaが採用している方式は、Declaration-site varianceといい、宣言する箇所において変位を指定する。以下のサンプルコードにおけるPredicateでは、宣言時に変位を反変(-T)と指定している。宣言時に指定しているので、使用する箇所の方では単にdef filter(predicate: Predicate[A]): SimpleList[A]とすればよい。

/* Scala */
trait Predicate[-T] {
  def test(element: T): Boolean
}

abstract class SimpleList[+A] {
  def filter(predicate: Predicate[A]): SimpleList[A]
}

Predicateは反変に指定しているので、Predicate[Animal]Predicate[Cat]型の変数に代入できる。以下の例では、このPredicateの性質を利用して、SimpleList[Cat]filter(predicate: Predicate[Cat])メソッドに対して、Predicate[Animal]型のyoungerThan10を渡している。

/* Scala */
val listOfCat: SimpleList[Cat] = Cons(new Cat(4), Cons(new Cat(7), Cons(new Cat(12), Empty)))
val youngerThan10: Predicate[Animal] = new Predicate[Animal] {
  override def test(t: Animal): Boolean = t.age < 10
}
listOfCat.filter(youngerThan10) // Predicate[Animal]はPredicate[Cat]に代入できる(反変)

反変(あるいは下限境界ワイルドカード型)は、共変に比べて直感的にはわかりづらいが、具体的に考えるとわかりやすい。上の例で、filter()メソッドが引数であるPredicate型のオブジェクトに期待しているのは、thisの要素(Catまたはそのサブクラス*2のオブジェクト)についてBooleanの値を戻してくれることだ。個々の要素は、Predicate[MyClass]test(element: MyClass): Booleanに渡される引数になるから、このMyClassCatクラスを代入可能な型であれば、filter()メソッドに渡されるべきPredicateの型パラメータにとって適格だということになる。そのような性質を満たすMyClassは、Cat自身あるいはそのスーパークラスである。

関連して、『Effective Java』でも紹介されているJavaジェネリクスについての原則で、「PECS(Producer Extends, Consumer Super)」というものがある。PECSは、コレクションを引数に取るメソッドの定義の際に、当該コレクションが要素を供給する側(Producer)であるときにはCollection(? extends MyClass)を、要素を受容する側(Consumer)であるときにはCollection(? super MyClass)を利用せよ、と指示する。要素を受容する側は、自らのメソッド(たとえばadd())の引数に要素を受け取るので、上の例におけるPredicateと同じ状況になる。

反対に、要素を供給する側は、自らのメソッド(たとえばget())の戻り値に要素を与える。この場合、戻り値を受け取る側の型がCatであるとすれば、Cat型の変数に代入できる型を返せればよく、それはつまりCat自身あるいはそのサブクラスだ。それを境界ワイルドカード型で表現すると、<? extends Cat>となる。

型パラメータの境界

境界ワイルドカード型と混同しやすいのが、境界型パラメータである。Javaにおいて、境界型パラメータは、以下のようなものである。

/* Java */
<E extends Number> // 上限境界型パラメータ
// <E super Integer>   // これは存在しない!(下限境界型パラメータ)

境界ワイルドカード型が、どのような型のインスタンスを受け取ることができるかを指定する(Predicate<? extends Animal>には、Predicate<Cat>を代入できる)のに対し、境界型パラメータは、その型パラメータに指定することのできる型を指定する。以下のチュートリアル記載の例では、型パラメータTComparable<T>の実装クラスに制限している。

/* Java */
public static <T extends Comparable<T>> int countGreaterThan(T[] anArray, T elem) {
    int count = 0;
    for (T e : anArray)
        if (e.compareTo(elem) > 0)
            ++count;
    return count;
}

境界ワイルドカード型との大きな違いは、Tを引数の型の指定に利用できるという点だ(だから「パラメータ」なのだ)。Javaの場合は、<? extends MyClass><T extends MyClass>と似た構文になっているため非常にわかりづらい(しかもいずれも使用するときに記述する)のに対し、Scalaでは明快に異なる構文になる。冒頭に掲げたadd()メソッドで利用されている[B >: A]Scalaにおける境界型パラメータだ。

/* 再掲 */
/* Scala */
abstract class SimpleList[+A] {
  def add[B >: A](element: B): SimpleList[B]
}

上のadd()メソッドでは、元々のリストの型パラメータであるA自身あるいはそのスーパークラスを型パラメータBとして利用できるようになっている。これにより、たとえばCatAとした場合のSimpleList[Cat]は、add[Animal](element: Animal): SimpleList[Animal]というメソッドを持っているのと同様の機能を持つ。このメソッドは、猫のリストに(必ずしも猫ではない)動物を追加することができ、追加後の新しいリストは動物のリストとなる、ということを意味している。

先述の通り、Javaにおいて境界型パラメータは上限(extends)のみ存在しており、下限(super)は存在しない。それゆえ、上のScalaのコードに対応する以下のようなコードをJavaで書くことはできない。

/* Java の擬似コード */
abstract class SimpleList<A> {
  // これはコンパイルエラーになる
  abstract SimpleList<B super A> add(B element);
}

下限境界型パラメータがJavaに存在しない理由は、調べてみたがよくわからなかった。

docs.oracle.com

おわりに

以上、ScalaJavaにおける変位指定と型パラメータの境界について見てきた。今回、Scalaを勉強したことを通じて、曖昧な理解しかしていなかったJavaジェネリクスについて学びなおすことができた。また、Scalaの下限境界型パラメータを利用したadd()は提示されてみると実に自然な設計で、言語仕様上の実装の制限が設計の考慮の幅を狭めてしまっているということを確認できたいい体験だった。

*1:正確にはそれをもとに作られた匿名クラス。

*2:上の例ではサブクラスは作成していないが。

環境構築なしでTDDを楽しむ:cyber-dojoのご紹介

新しい言語をちょっと触ってみたいな、でもIDEとか整えるのはハードルが高いな、というときは、cyber-dojoで試してみることが多い。

f:id:ky_yk_d:20190126144310p:plain
「cyber-dojo」のトップページ

様々な言語でTDDを試せる「cyber-dojo

cyber-dojoは、Webブラウザで利用できるコードエディタ&実行環境で、様々な言語・テスティングフレームワーク、様々なお題でテスト駆動開発を楽しむことができる。

f:id:ky_yk_d:20190126144315p:plain:w700
様々な言語・テスティングフレームワークが選べる

使用したい言語とテスティングフレームワークを選ぶと、実装コードとテストコードのサンプルが用意された状態で開始される。お題を(FizzBuzzなど)を選ぶようにはなっているが、選んだお題に応じて、テストコードが用意されるということはない。したがって、cyber−dojo側で用意されている以外のお題で開発をすることも可能である。

サンプル:ClojureFizzBuzz

サンプルとして、ClojureFizzBuzzを書いてみた。

f:id:ky_yk_d:20190127004527p:plain

ソースコードをは以下の通り。

(ns fizzbuzz)

(defn fizzbuzz [n]
  (cond (= 0 (mod n 15)) "FizzBuzz"
        (= 0 (mod n 3)) "Fizz"
        (= 0 (mod n 5)) "Buzz"
        :else n ))
(ns fizzbuzz-test
  (:require [clojure.test :refer :all]
            [fizzbuzz :refer :all]))

(deftest fizzbuzz-test
  (testing "FizzBuzzでは"
    (testing "3の倍数でも5の倍数でもないとき、その数字を言う"
      (are [n] (= n (fizzbuzz n)) 1 2))
    (testing "3の倍数のとき、Fizzと言う" 
      (are [n] (= "Fizz" (fizzbuzz n)) 3 6 9 12 -3))
    (testing "5の倍数のとき、Buzzと言う"
      (are [n] (= "Buzz" (fizzbuzz n)) 5 10 20 -5))
    (testing "15の倍数のとき、FizzBuzzと言う"
      (are [n] (= "FizzBuzz" (fizzbuzz n)) 15 30 45 -15))
    )
  )

どんなときに使うか

cyber−dojoは、様々な用途に使うことができる。上のClojureの例がそうであるように、新しい言語を触ってみたいときには、開発環境を用意しなくてもいいし、テストコードのサンプルも見ることができるので便利だ。

また、TDDのワークショップにも便利だ。上で紹介したように単独のユーザーで利用し、同じ画面を複数人で見るモブプログラミング方式で利用することもできるし、グループセッション機能を使えば複数の参加者のコードをチューターが見るというような利用の仕方もできる。

cyber−dojoはブラウザだけで動作するから、参加者全員分の環境を整える必要はないし、参加者が急に増えたときにもPCさえあれば対応できる。限られた時間でワークショップを行いたい時などは、非常に便利だろう。

終わりに

新しい言語を学ぶときは、環境構築がネックになることが非常に多い。cyber−dojoは、そういった際の強い味方になるだろう。また、 言語におけるテストコードの書き方も同時に学ぶことも、実際の業務にその言語を生かそうとするのであれば有意義なことだろう。

プログラミングClojure 第2版

プログラミングClojure 第2版

リレーショナルモデルにおける制約とCQRS・SQLQL

前回の記事で、リレーショナルデータベースの役割として、以下の3つを挙げ、ドメイン駆動設計においては最後のものにあまり重きが置かれていないことを指摘した。

  • 集合演算によるリレーションの導出(検索)
  • ディスクへの書き込みによる永続化(蓄積)
  • 各種制約によるデータの整合性の確保

ky-yk-d.hatenablog.com

本記事では、リレーショナルデータベースの特性を改めて検討し、その特性からの帰結としてCQRSとSQLQLを位置付けてみたい。

リレーショナルモデルにおける整合性の確保

整合性の確保をリレーショナルデータベースが担うという発想は、決して新奇なものではない。リレーショナルモデルの父であるコッドの1970年の論文「A Relational Model of Data for Large Data Banks」*1でも、データの整合性(consistency)というテーマが大きく取り上げられており、それを維持するための制約宣言文(constraint statement)を定義するというアイデアも提起されている。

現実のリレーショナルデータベースにおいても、制約は確かに存在している。一意性制約や参照整合性制約、チェック制約などがそれである。また、制約という呼び方は通常しないが、トリガもまた、データの整合性を守る仕組みとして利用できる。『リレーショナルデータベース入門』では、以下のように記載されている*2

これらの制約を表現するためのツールは、現実のリレーショナルデータベースにおいては限定的な実装を受けるに留まっている。それにはパフォーマンスの問題も関係しているだろう*3。運用上も、制約というデータベースの定義の変更は大規模なロックを伴うから*4、ビジネスルールをデータベースの制約の側に大きく寄せることはリスクが大きい。現実のアーキテクチャは、現実のリレーショナルデータベースに基づいて構築されなければならないし、構築されているだろう。次に、リレーショナルデータベースの特性に応じたアーキテクチャについて考えてみる。

リレーショナルデータベースの特性から考えるCQRS

制約は、更新時にどのようにデータの整合性を守るかを関心事としている。これは、実際のリレーショナルデータベースにおいては、参照整合性制約などの限られた形で実装されるに止まっている。その一方で、参照を行うための言語であるデータサブ言語、その実装としてのSQL(のSELECT文)はかなり発達している。

以上のような事情から、リレーショナルデータベースは、参照には柔軟に対応できる(対応しても危険が少ない)のに対し、更新には柔軟に対応できない(対応すると整合性が守れない)という特性を持っている。更新の操作を提供する場合には、リレーショナルデータベース側では担えない制約を一枚外側のレイヤ(具体的にはアプリケーションのコード)でかけておく必要が生じる。

前回の記事で指摘したように、『エリック・エヴァンスのドメイン駆動設計』においては、この「更新には柔軟に対応できない」というリレーショナルデータベースの特性を補うものとして、ドメイン層のクラスが役割を果たす。具体的には、ドメインモデル上の集約に不変条件を結び付け、トランザクション整合性の単位として厳格に守るような工夫をするのである。

一方で、参照であれば、データの整合性を維持する役割をアプリケーションが担う必要もそれほどない*5。このことをアーキテクチャに反映させたのが、『エリック・エヴァンスのドメイン駆動設計』(2004年)から9年後に描かれた『実践ドメイン駆動設計』(2013年)で大きく取り上げられているCQRS(コマンド/クエリ責務分離)だと言える。


CQRSにおいては、書き込み系と読み取り系とでモデルを使い分ける。業務ルールに基づくデータの整合性に配慮すべき書き込み系のモデル(ドメインモデル、ライトモデル)から読み取り系のモデル(クエリモデル、リードモデル)を切り離すことができるというのが、そのポイントになる。

CQRSの着眼点は、書き込み系と読み込み系とではアプリケーションに対する要求が異なるということであり、必ずしもリレーショナルデータベースの特性に着目したものではない。しかし、先に指摘したリレーショナルデータベースの特性から考えてみると、自然な帰結としてCQRSを導くこともできたのではないだろうか。

リレーショナルデータベースの強みを活かす「SQLQL」

リレーショナルデータベースの特性からCQRSを導くとすれば、その先には「ユーザから直接SQLを受け付ける」という発想が見えてくる。yanchaさんが提案している「SQLQL」がそれである*6。SQLQLというのは、リモートのエンドポイントに対して、クライアントからSQLを文字列として送信することによってJSON形式の文字列として実行結果を得る仕組みを表している。

qiita.com

リレーショナルデータベースは、それ自体として柔軟な参照の仕組みを提供している。そうであるとすれば、

  • クライアントのアプリケーション
  • サーバのアプリケーション
  • リレーショナルデータベース

という構成をとった場合に、サーバのアプリケーションで一旦オブジェクトとして取り扱うことが、リレーショナルデータベースの柔軟さを殺すことになっているという解釈もできる*7

CQRSを採用するだけでは、上で指摘した事態は解消されない。参照側で、リードモデルとして静的なクラスを定義している場合はデータ構造に修正を施す必要があるし、データ構造を動的に生成している場合であっても、参照の仕方を変えるためにはサーバ側のクエリに手を入れる必要がある。

このような状況に対し、SQLQLを採用すれば、画面での参照の仕方を変えたい、欲しい属性が増えたという場合に、サーバのアプリケーションには一切修正を入れることなく対応できるわけである。柔軟な参照の仕組みを提供しているリレーショナルデータベースの能力を最大限に活かす考え方だと言えるだろう*8

終わりに

以上、参照は柔軟だが更新は柔軟でない(柔軟ではいけない)というリレーショナルデータベースの特性の自然な帰結として、CQRSとSQLQLを位置付けることを試みた。CQRSもSQLQLも他人の考えたものであるが、自分なりの整理ができたのではないかと思う。

本記事でできなかったことを挙げておく。まず、オブジェクト指向データベースやキーバリューストアなどのNoSQLデータベースには詳しくないので、それらとの比較はできなかった。また、大きな課題として、リレーショナルモデルとオブジェクト指向モデルの違いについても、検討が及んでいない。

オブジェクト指向には、単なるデータ構造としての意味だけでなく、振る舞いを持たせるという側面、あるいは人間のメンタルモデルとの一致を目指すという側面もある*9。今後の課題としたい。

*1:杉本啓さんによる対訳版を使用した。こちらの勉強会のページに原文および対訳版へのリンクがある。

*2:増永良文『リレーショナルデータベース入門』44ページ。ただし、ここでは整合性(consistency)ではなく「一貫性(integrity)」という表現が用いられている。両者の関係については、Quoraの回答が手がかりになる。

*3:コッドの1970年論文でも、整合性の検査が更新操作の速度を落としてしまうことへの懸念が述べられているとともに、対処するためのアプローチとしてバッチによる検査実行が挙げられている。

*4:データベースにおける制約の過度な利用については、『失敗に学ぶRDBの歩き方』に記載がある。それを読んでいた時の自分のツイートも参照。

*5:もちろん、柔軟に発行できる問い合わせのなかで「意味のある」ものだけを提供するという意味では、参照側もアプリケーションには意味がある。しかしそのアプリケーションは操作を隠蔽するだけで独自の操作を行うものではなく、ラッパー以上のものではないのではないかと思われる。

*6:SQLQLという概念の存在は、すえなみ(@a_suenami)さんに教えていただいた。

*7:「意味のある」参照のみを提供するということはもちろんある。先の注釈を参照。

*8:とはいえ、セキュリティなどの面でまだ実装上の課題は多いようだ。

*9:メンタルモデルとの一致という観点から、オブジェクト指向に対してDCIからの批判がある。この点については、「DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien」を参照のこと。