読書会(APIデザインの極意)第2回議事録
[ 戻る ]
=====================================================================================
Java読書会BOF 「APIデザインの極意 Java/NetBeansアーキテクト探究ノート」を読む会 第2回
=====================================================================================
.. csv-table:: 開催概要
"日時", "2014年11月29日 10:00 - 17:00"
"場所", "川崎市教育文化会館 第3会議室"
"出席者(敬称略)", "遠藤、小棚木、石黒、井上、平山、高部、今井、岩室、高橋(徹)、高橋(智)、中澤、村山、吉本、田邊(書記)"
議事
====
3.9.2 一貫性
-------------
* "登録する方法として仮にオブジェクトに対するファクトリがあるならば、すべての種類のファクトリは1つの登録方法を使用すべきです。"の意味がちょっとわかりづらい。
* ネーミングサービスの統一の話?
* 複数のファクトリがあったとしても、使い方が同じようにしておくべき、という意味?
* org.w3c.dom の API が変わったというのはいつ?
* 新しいメソッドを既存クライアントが使わなさそうであれば、コンパイルは通るという意味で JDK 8 のデフォルトメソッドは 1 つの解。
* ただし、ただ UnsupportedException を返すだけとかなら、コンパイルで怒られた方が実行時にわかるよりは嬉しい気がする。
* Jigsaw も依存への1つの解決策になりそうだが、OSGi が対抗勢力らしい。
* 実際問題インターフェースの一貫性を保つのは難しい。Java はすごい。
* ライブラリのクライアントには API としてインターフェースを見せたいが、実装を禁止させる方法が欲しい。
3.9.4 単純な仕事は簡単でなければならない
------------------------------------------
* javax.mail が Java SE にないのはもったいない。せっかくのマルチプラットフォームなのに。
* "JavaMail API" という本がある
* http://www.amazon.com/JavaMail-API-Elliotte-Rusty-Harold/dp/1449367240
3.9.5 投資の保全
----------------
* この節は API 提供者の最大のミッション
* 今動いているもののことを考えると、問題が合っても現行 API を変えるのは難しい。
* だいたい API というものは、使ってみて問題が初めてわかることの方が多い。
4.2.1 ソース互換性
-------------------
* ワイルドカードで import 指定するのはやはりあまりよくない(static インポートは別として)
* IDE が出る前までは手で import 文を書いていた。たいへんだ。
4.2.2 バイナリ互換性
---------------------
* ソースコードからビルドできない時は、クラスファイルをいじって自分で jar に差し替えて利用することがある。
4.5 APIのライフサイクル
-----------------------
* コマンドライン解析 API とやらの現在(8.0.1)はどうなっているのだろう? 使われている?
* バージョンの数字に意味をもたせるのは正直わかりづらいが、他に方法があるか
* API はアプリケーションから使うもの、SPI はライブラリ自体の実装を交換可能にするもの
* Deprecated になったライブラリも別途ダウンロードできるようになっているのはうれしい
5.1 フィールドよりメソッドが優れている
---------------------------------------
* "かつて、ある.NETアーキテクトが、パフォーマンスのためにカプセル化を犠牲にする必要があると告白するのを聞いたことがあります。" って本当? かなり昔の話?
5.2 コンストラクタよりファクトリが優れている
---------------------------------------------
* なんでもかんでもファクトリというのも大げさだと思う。コンストラクタ, ファクトリがそれぞれ適切である場合を見極た上で適用するべきでは。
5.3 すべてをfinalにする
-----------------------
* final だと困るような API に出会った時は、作者に final をやめてもらうように改善要求する(正論)
* API 作者からするとメソッドは簡単に追加できるし final にしておくのは楽。
5.5 フレンドのコードからのみアクセスを許可する
-----------------------------------------------
* api パッケージに Item と AccessorImpl , api.impl パッケージに Accessor ?
* static 初期化子によって setDefault をクライアントが呼ぶこと(2回目の setDefault)を禁止できてるのがミソみたい
* 確実に static 初期化子が実行されるために Class.forName(name, initialzie, loader) していると思われる。
* OpenIDE-Modules-Public-Packages: api.** とは?
誤記など
--------
4.6 徐々に改善
--------------
* "アップブレード"
* 書籍版にはヤングパイオニアの訳注がない
第2部 実践的設計
------------------
Column 本物のソースが必要！
---------------------------
* "ソースをからダウンロードすることができます。"
^^^^^^
5.4 不適切な場所にセッターを用意しない
---------------------------------------
* AbstractionAction AbstractAction の誤記?
.. note:: 次回は、書籍の83ページ「5.6 オブジェクトの作成者に多くの権利を与える」から。
[ 戻る ]