こまどブログ

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

JavaにおけるOptionalによるnull安全のための覚書

Java8から導入されたOptionalを利用することで、よりnull安全なコードを書くことができる。ただし、使い方を間違えるとかえってバグを生むことにも繋がる。適切に利用するための覚書を書く。

nullを返す可能性のあるメソッドは、Optional型を返すメソッドに変更する

これがベースになる。Optionalが導入されるまでは、nullを返す可能性のあるメソッドと返す可能性のないメソッドは言語の上では区別できなかった。そのため、nullを返すかもしれないメソッドを呼び出す際には、プログラマがそれを意識した上で、呼び出し元の方でnullチェックを書く必要があった*1

Optionalを返すように変更することで何が起きるか。Optional型のオブジェクトが戻り値となることによって、そのまま(Optionalから中身を取り出さずに)利用することが禁止されるのだ。中身を利用するためには、Optional型に定義された各種のメソッドを利用する必要がある。同時に、空のOptional(メソッド変更前のnullに対応)が返ってくることを考慮して呼び出すことも強制されるので、「うっかり」nullが画面に表示されてしまったり、NullPointerExceptionをスローしてしまったりということはなくなる。

nullになる可能性のあるフィールドに対するgetterは、Optional型を返すメソッドとする

これは上の原則に含まれているが、意識しにくいものだと思う。通常、getterというと、以下のようなものを想像する。

public class User {
  private String name;
  public String getName(){
    return this.name;
  }
}

このような(しばしばsetterを一緒に書かれる)getterは、Javaプログラマにとっては見慣れたもの(好き嫌いはともかく)だろう。フレームワークがこの種のメソッドの定義を要求している場合もあり、全部を否定するわけではないのだが、Optionalを使ってnull安全なコードを書くという観点からは、この種のgetterは再考に値する。

getterもまた、ひとつのメソッドだ。nullを返す可能性があるのであれば、戻り値の型はOptional型にするべきだ。もしUserのname属性が未設定を許すのであれば、以下のように修正する*2

public class User {
  private String name;
  public Optional<String> getName(){
    return Optional.ofNullable(this.name);
  }
}

ちなみに、上のようなメソッドを用意する場合、同一クラス内からもフィールドに直接アクセスするのではなく上記のメソッドを利用するようにすべきだ。そうすることで、nullチェックを実装し忘れることを防ぐことができる。このように、外部に対するカプセル化のためのメソッドを自分自身もまた利用することを、自己カプセル化という。Optional型を戻すgetter以外についても使えるテクニックだ。

引数やフィールドにはOptional型を使わない

以上では、メソッドの(nullになる可能性のある)戻り値をOptional型に変更すべきだと書いてきたが、メソッドの(未設定を許容する)引数やフィールドに対しては、Optional型は使わない。

それは、Optional型の引数やフィールドが実行時にnullである可能性を排除できないためだ。下記のようなコードを書いても、思った通りにメソッドが使ってもらえる保証はない。メソッドの利用者は、空のOptionalを渡す代わりに、Optional型のnullを渡すことができてしまう。

public int calculatePrice(Optional<DiscountRate> discountRate){
 // 省略
}

設定を任意としたい引数がある場合には、従来通りnullチェックをメソッド内部で行い、処理を分岐させればいい。一方、nullを許容しない引数については、Javadocコメントにその旨を明記し、実行時にnullが渡された場合に備え、Objects.requireNonNull()等を用いて「防御的プログラミング」を行う。nullを渡さないでくれと言っているメソッドにnullを渡したのであれば、それは利用者側のミスであり、供給者の責任ではない。容赦無くNullPointerExceptionなどをスローして落としてしまえばいい。

参考

*1:nullチェックを怠った結果としてよく見られるのが、ユーザ向けの画面上に表示される"null"の文字列だ。

*2:メソッド名はgetterらしいgetName()よりも単にname()などとした方が良いかもしれない。

Web API の仕様をOpenAPI Specで書いてみて

以前、OpenAPI Generatorの紹介記事を書いた。

ky-yk-d.hatenablog.com

上の記事を書いてから、実際のプロジェクトでOpenAPI SpecでAPIの仕様を書くとともに、その定義ファイルからOpenAPI GeneratorでAngularのクライアントコードを自動生成するということを始めた。まだ課題もあるが、中間報告を書く。

前提条件

今回開発対象としているAPIサードパーティによる利用を想定したものではなく、もっぱら自社で開発するクライアント(Web/モバイル)から利用されるもの。サーバとクライアントを並行で開発しており、APIの仕様を決めるに当たってはクライアントでの利用のしやすさを重視している。

開発チームとしては、サーバでHTMLを生成する種類のWebアプリケーション開発の経験が長いメンバーが多く、Web API開発の知見はチーム内に乏しい。また、これまで仕様書はExcelがメインであったとともに、構成管理ツールとしてもVSS/TFSに慣れ親しんでいるメンバーがほとんどである。

やっていること

現在は、以下の事柄を実施している。

  • OpenAPI SpecによるAPI仕様の記述
  • 上記ファイル(YAML)のGitでの管理
  • ReDocによるHTMLドキュメントの生成
  • OpenAPI GeneratorによるAPIクライアントコードの生成

補足すると、YAMLファイル(およびそこから生成されたHTMLドキュメント)がAPI仕様の正式版ではあるものの、いきなりYAMLファイルを記述するのは辛いので、仕様を検討する過程では一度Excelに記述するようにしている。Excelのフォーマットは、自動生成したHTMLドキュメントの記載項目を参考に作成した。

OpenAPI Generatorのスタブサーバのコード自動生成の機能は、開発の当初の段階では試してみたが、現在は使っていない。クライアントの開発がサーバの開発に先行している場面では、クライアントコードの中にダミーデータを直書きすることで済ませている。また、HTMLドキュメントの生成は、OpenAPI Generatorでも可能だが、見やすいものではなかったためReDocという別のツールを利用している。

github.com

iktakahiro.hatenablog.com

よかったこと:情報の集約

スキーマ駆動開発」というテーマの特集を読んで導入したOpenAPIだったが、ここまでのところで実感している効用はむしろ、「情報の集約」という側面に関するものである。

具体的には、チーム内で(あまりよくないことだが)よく交わされる「〇〇ってどの資料に書いてありましたっけ」という会話が、Web APIの仕様については全く発生しない。

自社はドキュメントをそれなりに作る会社なので、各種の設計書を作成する際に利用できる標準フォーマットがある程度整備されている。しかし、標準的なものがないケースにおいては、まず大雑把な資料が作成され、プロジェクトが進んで情報が増えていく中でより詳細な、あるいは別の側面からの資料が作成される。その結果、フォーマットの異なる複数のファイルに情報が散逸するということになりやすい。

Web APIの仕様についても、社内には標準がないので、当初は上のような管理が困難な状況に陥りそうになっていた。しかし、OpenAPI Specの導入により、YAMLファイルが単一の情報集約点となった。OpenAPI Specでは様々な情報を記述することができるようになっているから、原則としてYAMLファイルに情報が追加されるようになる。

YAMLファイルには記述しづらい情報のために、補足的な資料を作成することがあっても、YAMLファイルが主たる地位を占めることはチーム内で了解されているので、情報が散逸しづらいのだ。また、OpenAPI Specの仕様で「どのような情報を記述できるか」を知ることは、開発の経験が乏しいWeb APIについて「どのような事柄を考慮すべきか」を考える助けにもなっている。

展望と課題:その他の情報の集約と「スキーマ駆動」

「情報の集約」は、OpenAPIの導入に拠らずとも達成されうるものであるし、本来は達成されているべきものだ。抱えている問題のレベルの低いというのは一方で真理だろう。しかし、自分の現場にとっては、OpenAPIという仕様とその周辺ツール群が、その問題を浮き彫りにすると同時に、解決できるものであることを気づかせてくれた。この気づきを承けて、Web APIの定義以外のドキュメントも、なるべく一箇所に集めるように動き始めている。

一方で、先に述べた通り、スキーマという部分でのメリットはあまり享受できていない。また、各種ツールを利用することによるメリットも最大限享受できているとはいえない。あまり色々やろうとしすぎても大変&混乱を招くのでそこは注意したいが、ツールの導入を少しずつ進めていきたいなとは思っている。

WEB+DB PRESS Vol.108

WEB+DB PRESS Vol.108

  • 作者: 中野暁人,山本浩平,大和田純,曽根壮大,ZOZOTOWNリプレースチーム,権守健嗣,茨木暢仁,松井菜穂子,新多真琴,laiso,豊田啓介,藤原俊一郎,牧大輔,向井咲人,大島一将,上川慶,末永恭正,久保田祐史,星北斗,池田拓司,竹馬光太郎,粕谷大輔,WEB+DB PRESS編集部
  • 出版社/メーカー: 技術評論社
  • 発売日: 2018/12/22
  • メディア: 単行本
  • この商品を含むブログを見る

6月22, 23日に、豪華スピーカー陣によるカンファレンス「DevLOVE X」が開催されます

DevLOVE10周年イベント「DevLOVE X」

きたる6月22日(土)・23日(日)の2日間の日程で、株式会社ナビタイムジャパンさまにて、ソフトウェア開発者向けイベント「DevLOVE X」が開催されます。

devlove.wixsite.com

こちらは、ソフトウェア開発者コミュニティ「DevLOVE」の10周年記念イベントです。DevLOVEは、『カイゼン・ジャーニー』の著者のお一人である市谷聡啓(@papanda)さんが2008年に立ち上げられたコミュニティです。僕は、DevLOVEの運営にここ一年弱ほど関わらせていただいていまして、今回の10周年イベントにもスタッフとして参加します。

すでに市谷さんを中心としたスタッフ陣、それに登壇者の方々からTwitter等で告知をしていただいていますが、こちらのブログでも僕の個人的な思いを添えて宣伝させていただきたいと思います。

豪華スピーカー陣のみなさま

今回の「DevLOVE X」は、総勢60名以上のスピーカーをお招きするカンファレンスという形で行われます。すでにタイムテーブルも公開されています*1

f:id:ky_yk_d:20190528212935p:plain f:id:ky_yk_d:20190528212939p:plain

ご覧のような、「何回分の基調講演ができるんだ」という豪華なスピーカーの方々にご登壇いただきます。

togetter.com

完全に個人的なスピーカーのご紹介(一部)

今回のスピーカーの方々には、僕自身、書籍などを通じて学ばせてもらっている方、あるいは直接的に勉強会等でお世話になっている方が多く含まれています。その中でも、僕がこの業界に入ってからの2年間を振り返る上で欠かせない方々を特に取り上げてご紹介したいと思います。

和田卓人(@t_wada)さん

言わずと知れたt-wadaさん。新卒1年目だった2017年11月に『テスト駆動開発』の新訳が出版され、12月に開催されたイベントで初めて生で接しました。テスト駆動開発というプラクティスを通じて、ドライだと思っていたプログラミングが実は人間の心理と深く結びついた営みであることを教えてもらいました。

テスト駆動開発

テスト駆動開発

広木大地(@hiroki_daichi)さん

『エンジニアリング組織論への招待』の著者。2018年の2月に出版された書籍は、「ソフトウェア開発をこういう風に語れるのか、語っていいのか」という気づきを与えてくれました。僕にこの2年間の中で最も大きな影響を与えた人々の一人と言えます。何とか広木さんの影響圏から脱したいともがいている最中です。

横道稔(@ykmc09)さん

omoiyari.fm」のパーソナリティの一人。omoiyari.fmは、僕がアジャイルやマネジメントというものに関心を持つようになる一因となったとともに、カカカカックさんとの出会いを与えてくれた大切な番組です。伝説の第22回に限らず何度も聴き直しているので、2年間で家族と同僚以外で最も長く声を聴いていた人かも知れません。

lean-agile.fm

カカカカック(@kakakakakku)さん

この人がいなかったら僕はいまこの記事を書いていないでしょう。2018年5月から2ヶ月間、ブログのメンタリングをしてもらいました。影響を受けたというよりも、「生活を規定されている」存在です。僕がブログを書くことを止めるか、僕なりのブログに対する向き合い方を見つけるその時まで、それは続くのだと思います。

kakakakakku.hatenablog.com

参加申し込みはDoorkeeperから

以上、甚だ個人的なご紹介を4名のスピーカーの方について書きました。上に挙げた方々以外にも、様々な分野でご活躍のスピーカーのみなさまが参加してくださり、スタッフという贔屓目を差し引いても「豪華だ!」と言ってよいと確信しています。僕もとても楽しみです。

そんな「DevLOVE X」、まだまだ参加申し込みを受け付けていますので、ぜひ下記からチケット(2days + 懇親会チケット付きで10000円です)を入手の上、ご参加ください!

devlove.doorkeeper.jp

*1:画像は2019年5月28日現在。