JavaOne2013レポート001-Practices and Tools for Building Better APIs(前半)
※JavaOneのレポートを書くにあたり、
ブログが必要だったのでとりあえず一つ開設しました。
JavaOne3日目に聴講した、Peter Hendriks氏の
「Practices and Tools for Building Better APIs」についてのまとめ前半。
本セミナーは、表題の通り
「良いAPIとは何か」について考えを深めると共に、
Javaの最新動向とも関連づけてどのような改善が出来るのか述べている。
下記に話の大枠毎に区切ってまとめていく。
1# 2つの視点
APIの設計を考える上で下記の2つの立場について考えることが鍵である。
それは
Consumer(APIを使う人)とImplementer(APIを実装する人)
であると。
この2つをいきなり並列で出してくることがまず新鮮だった。
我々としては、前者(Consumer)と後者(Implementer)は
それぞれ全く別者として考慮しているからだ。
その上で、下記が大切だと述べた。
1.Reuse(再利用しやすいことが大切)
-先を見据えた実装はとても大切である。APIを設計する場合は、そのAPIの将来像、
あるべき姿について考えることが大切だと考える。これを考えれば、コアなAPIほど再利用出来る形に自然と近づくはずである。
2.Independent change(独立して変更可能であることが大切)
-これは実際に社内のAPIを担当していて感じるが、
様々な用件で、仕様の変更が求められる機会は多々ある。もちろんそこで仕様を変えるかどうかは別問題だが、柔軟な設計であることで仕様変更に耐えられることも事実。
3.Separate concerns(※色々と意味がとれるのですが、リスク分散が大切(としておきます)
-※編集中※
2#APIは使う側にとってはブラックボックス
APIは使用する側にとってブラックボックスになってることが往往としてあるという事。
たしかにその通りで、たしかにAPIの先でエラーが起きたときに、
何が原因でエラーなのか全く分からなくて手詰まりになることは少なくない。
社外連携はもちろんのこと、社内の連携でも、色々なものをまたぐほどに良くわからなくなる。。これは胸が痛い
そういった理由から、とにかく我々は
APIをShape
する必要があるとPeter氏。
個人的にshapeって言葉がぴったりだと思いました。
無駄を削ぎ落として、芸術作品のようなAPIを作りたい。
#3良いAPIとは
#1,#2をふまえた上でPeter氏が良いAPIを次のように定義した。
1.Valuable(always important)
value = benefit - costs
->
ここはやっぱり揺るぎない。
利益を生み出すことはAPIに置いても非常に重要
特に社内APIだと直接ビジネスとの接点が薄い場合もあるので、
忘れがちになる場合もあると思います。コストは計算すると本当に高い
2.Usable(more important if used more)
easy to learn
productive
error-proof
->
使いやすいこと。easy to learnは改めてとても大切だと認識。
easy to learn(学習しやすさ)がAPIを回収する上でコストの面でも
大切だということを再認識させられた。当たり前のことでもこういう事を項目の一つとして、他の観点と同様に重要だと位置づけることが意識の高さだと感じた。
3.Stable(more important if used more and longer)
Able to enhance and grow features without breaking existing consumer code
->
安定していること。
また、安定する為にどのようなコードを書くかということが非常に大切であるとのこと。
2,3についてはコードレベルの話もあるので、その点は後述していきます。
以上で本セッションの前半まとめとさせていただきます。
後半では、良いAPIの定義であるUsableとStableについて実例を
ふまえた説明があったので、引き続きまとめます。
