読書会(APIデザインの極意)第1回議事録

=====================================================================================
Java読書会BOF 「APIデザインの極意 Java/NetBeansアーキテクト探究ノート」を読む会第1回
=====================================================================================

.. csv-table:: 開催概要

   "日時", "2014年10月25日 10:00 - 17:00"
   "場所", "川崎市教育文化会館　第３会議室"
   "出席者(敬称略)", "石黒、井上、今井、岩室、岡田、小棚木、門脇、佐藤、高橋(徹)、高橋(智)、中沢、中島、村山、吉本(書記)"

議事
====

表紙
----

* 原題（Practical API Design: Confessions of Java Framework Architect）の意味は？

  * Java フレームワークアーキテクトの告白？

  * Confessionの意味は懺悔。

  * 日本語タイトルと原題が全然違う。

  * タイトルにNetBeansを付けると、Eclipse信者が買わなそう。

日本語版によせて
----------------

訳者まえがき
------------

序章　なぜ新たなデザイン本が必要なのか
--------------------------------------

* 今年のJavaOne 2014では、21:30のセッションまで。

* 委員会とは？

  * Committeeのことでは？

  * 標準化委員会のようなものか？

* コンポジションによる再利用とは？

  * 継承ではなく、移譲を使うということ。

* ノートブックとは？

  * 日誌ということか？

  * 外国人にとって、ノートブックはどのようなものをイメージするのだろう。

第1部　理論と正当性
--------------------

第1章　現代的なソフトウェア構築の技芸
--------------------------------------

1.1　合理主義、経験主義、無知
-----------------------------

1.2　今までのソフトウェアの発展
-------------------------------

* 図1-1の、仕事を求めているという内容は皮肉なのか？

  * HTMLを書く人はプログラマーとは言わないということか？

1.3　巨大なビルディングブロック
-------------------------------

* 後方互換といえば、Java9で-souorceと-targetに1.4が指定出来なくなるが・・・。

  * Java9で、1.4向けのコンパイラが出来なくなるということ。

  * 1.4のバイナリが、Java9で動かないということではない。

  * 後方互換が無くなるという訳ではない。

1.4　美しさ、真実、優雅さ
-------------------------

1.5　さらなる無知
-----------------

第2章　APIを作成する動機
------------------------

2.1　分散開発
-------------

2.2　アプリケーションのモジュール化
-----------------------------------

2.2.1　直線ではないバージョン付け
---------------------------------

* 仕様バージョンは、使用バージョンの誤植？

  * Javaにもspecific versionとimplementation versionがあるので、これで正しいと思う。

2.3　すべては、コミュニケーション次第
-------------------------------------

2.4　経験的プログラミング
-------------------------

* Java8から追加されたOptional型を返すようにすると、ドキュメントを見なくてもNULLを返す可能性があることが分かる。

* JSR308より、@Nullableや@NonNullを型に付けると、チェッカーフレームワークがあれば警告を出してくれる。

* Listの要素がNULLか空かどうかは分からない。

  * Java7から入っているObjectsクラスを使えばいいのでは？

2.5　最初のバージョンは常に簡単
-------------------------------

* Windowsの次期バージョンが9から10に変わったのは、Javaのバージョンチェックが、"Windows9"まで一致すればWindows95かWindows98と判断してしまうロジックのためと言われている。

第3章　優れたAPIを決定づけるもの
--------------------------------

3.1　メソッドとフィールドのシグニチャ
-------------------------------------

3.2　ファイルとその内容
-----------------------

3.3　環境変数とコマンドラインオプション
---------------------------------------

3.4　APIとしてのテキストメッセージ
----------------------------------

* Exception.printStackTraceは、Javaの黒歴史を思い出す。

  * Exception.getMessageも同様。

3.5　プロトコル
---------------

* NetBeansのデバックをする場合、起動オプションでユーザーホームを切り替えると設定ファイルが分かれるので、複数起動させることが可能。

3.6　振る舞い
-------------

* APIの実装の部分がAPIには属していない、とはどういうことか？

  * Javadocに書かれていないことはAPIの外ということではないか。

* 契約を変えないことが重要とは？

  * 契約を変えないこと自体も重要だが、契約にはシグネチャだけでなく、内部の振る舞いも含まれると考えることが重要。

3.7　I18NサポートとL10Nメッセージ
---------------------------------

* euc_jaではなく、euc.jpでは？

  * UTF-8にロケールを変えると大丈夫なはず。

  * これまでの経緯から、SolarisでEUC以外に変えるとアプリが動かなくこともある。

3.8　APIの広い定義
------------------

3.9　APIの品質検査方法
----------------------

.. note:: 次回は、p.38「3.9.1　理解しやすさ」から。

[ 戻る ]