読書会(Java 8 Lambdas: Pragmatic Functional Programming)第2回議事録

============================================
Java読書会BOF 「Java 8 Lambdas」を読む会第2回
============================================
.. csv-table:: 開催概要

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

議事
====

About the Author (著者について)
===============================

Colophon (奥付)
===============

CHAPTER3 Streams (続き)
=======================

A Common Pattern Appears (共通パターンの出現)
---------------------------------------------

reduce
^^^^^^

* reduceは訳すべきか?

  * 無理に訳すとわかりにくいのでそのままでよいのではないか。
  * 「map-reduce」は訳していない。
  * そのままの場合reducingやreductionはどう表現すべきか?

    * 「リデュース」でいいのでは。

* 本書はサンプルコードの引数名に意味のある命名をしているので読み易いと思う。

    * よくあるサンプルコードだと1文字程度のことが多い。

* p.30の「functional and imperative versions」は「functional version」と「imperative version」の意味ではないか。

* p.30の「asList」はstatic import。

* p.30はIntegerの代わりにintを使えないか?

  * Java8ならばOK。

Putting Operations Together
^^^^^^^^^^^^^^^^^^^^^^^^^^^

* (4)の「collect(toList())」は「collect(toSet())」の間違いと思われる。エラッタはあるか?

* StreamだとSetやListと違って内部構造を暴露しない。(=ドメインオブジェクトに影響を与えない)

Refactoring Legacy Code
^^^^^^^^^^^^^^^^^^^^^^^

* 条件分岐やループが無いので、サイクロマチック複雑度は大きく下がる。

* カバレッジを満たすのもより楽になるかもしれない。

Multiple Stream Calls
---------------------

* collect()に渡しているtoList()やtoSet()が何をやっているかわからない。

  * 内部状態を持つCollecotrクラスのオブジェクトを返している。
  * これがオブジェクトを収集してコレクションを返している。

* 3番目の「よくない点」はNGとは言えないのではないか。

  * 変数に名前を付けることで対象が何かを明確にできるので、むしろ可読性を上げることができるケースがある。
  * コレクションではなくStreamのままなら、処理自体は変わらないので問題はないのではないか。

* Stream/Lambdaさとデバッグが大変そう。

  * 途中で変数に入れてもStreamだと中身が見えない。中身を取り出すと処理が進行してしまう。
  * メソッドチェーンされた途中の状態をデバッガでするには、現状ではコードを書き換える必要があるのではないか。
  * 1行で書くとブレークポイントは外側に設定されるのではないか。
  * lambdaの中で改行すればlambdaにブレークポイントを設定できそう。

Higher-Order Functions
----------------------

* 「be accidental」は何と訳すべきか? ⇒ 「しかたがない」くらい?

Good Use of Lambda Expressions
------------------------------

* lambda式内のthisは無名クラスのthisとは異なる。(バイトコードレベルでも)

  * 実態は定義元クラスのprivate staticメソッドで、this相当は引数で渡される。

    * 現状のFindBugsでは意味不明なエラーで怒られる。(trunkだとOKとのこと)

* Java8では静的解析ツールが壊滅状態。

  * PMDはがんばってる。
  * (前述の通り) FindBugsはtrunkではlambda対応している。
  * CheckStyle はだめらしい。
  * メトリックス収集系もだめらしい。
  * Eclipseは、本体は対応しているが、プラグインはだめらしい。

Key Points
----------

Exercises (練習)
----------------

Advanced Exercises
------------------

CHAPTER4 Libraries
==================

Using Lambda Expressions in Code
--------------------------------

* lambda式は、簡単に置き換えて良いほどパフォーマンスインパクトはないのか?

  * InvokeDynamicの初期化コストは必要なのではないか?
  * lambda式を渡す処理を通過する度に新たなオブジェクトが生成されるのではないか? ⇒ 外部の変数をキャプチャしなければ問題ないらしい。(MLより)

Primitives
----------

* 「boxed type」は「ボックス型」がよいのではないか。

  * 普通は「ラッパー型」と呼ぶことが多い。

Overload Resultion (オーバーロードの解決)
-----------------------------------------

* 「specific type」=「具体的な型」?

@FunctionalInterface
--------------------

* 「back in Chapter 2」⇒ p.9「Functional Interfaces」で示したことを指している?

* 「Functional Interface」=「関数的なインターフェース」?

Binary Interface Compatibility
------------------------------

* interfaceの定義を変更したとき、それをimplementsしているソースはコンパイルが通らないが、バイナリは問題ないか?

Default Methods
---------------

* 「assumptions」=「前提」?

Default Methods and Subclassing
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

* クラスにprivateメソッドが存在し、インターフェースにシグネチャが一致しているデフォルトメソッドを追加するとどうなるか?

  * コンパイルはNG?
  * バイナリ互換性はOK?

Multiple Inheritance (多重継承)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

* 同じシグネチャのデフォルトメソッドを持つインターフェースを多重継承したとき、呼び出し側の変数の型に応じて、呼び出され側のメソッド実装を呼び分けることはできるか?

  * Javaでは不可なので、コンテクストを設定して明示的に呼び分けるか、アダプタクラスを用意して呼び分ける必要がある。

The Three Rules
^^^^^^^^^^^^^^^

Tradeoffs
^^^^^^^^^

Static Methods on Interfaces
^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Optional
^^^^^^^^

* lambda式で値があるときにだけ呼ばれるようにできるはず。(要確認)

Key Point
^^^^^^^^^

Exercises
^^^^^^^^^

Open Exercises
^^^^^^^^^^^^^^

CHAPTER 5 Advanced Collections and Collectors
=============================================

Method References
-----------------

Element Ordering
----------------

Enter the Collector
-------------------

* 「Enter」=「入門」?

Into Other Collections
^^^^^^^^^^^^^^^^^^^^^^

To Values
^^^^^^^^^

(次回は p.64「Partitioning the Data」から)

(以上)

[ 戻る ]