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

[ 戻る ]


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

.. csv-table:: 開催概要

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

議事
====

表紙
----

* 原題(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 理解しやすさ」から。


[ 戻る ]