日本ソフトウェア科学会第 36 回大会 (2019 年度) 講演論文集

GitHub 上の Java コードにおけるメソッドチェイン利用の定量的な分析
中丸 智貴

千葉 滋

メソッドチェインスタイルでのプログラム記述は広く受け入れられていると言われている. しかしながら, そのことを示す定量的な結果は我々の知る限りでは存在しない. 本研究では「メソッドチェインスタイルが広く受け入れられているかどうか」を定量的に明らかにするため, メソッドチェインの出現数の経年変化を調査した. 分析の結果, ソー
スコード 1 行あたりの長さ 2 以上のメソッドチェインの出現数は 2008 年から 2018 年まで増加し続けていることが明らかになった. また, チェインされていないメソッド呼び出し数に対する, チェインされたメソッド呼び出し数の比率が 2008 年から 2018 年の間に 15%から 28%まで増加していることも明らかになった.

1 はじめにメソッドチェインスタイルでの記述は広く受け入れられていると言われている [3–5, 7, 9, 14, 15]. メソッ// Java Stream APIstrList . stream (). filter ( s -> ! s . isEmpty ()). map ( s -> s + " . " ). collect ( toList ());

ドチェインスタイルとは, 図 1 のように, メソッド呼び出しを一つの式中で連鎖させるプログラミングス

図1

メソッドチェインスタイルでの記述タイルである. メソッドチェインスタイルでの利用に適したインターフェイス (ﬂuent interface) を持つラ

く受け入れられているかどうか」を定量的に明らか

イブラリは, 様々なオブジェクト指向言語において開にするための調査を行なった. 我々は GitHub 上の発されている [8, 12, 13]. また近年 ﬂuent interface を3,461 個のレポジトリの各年末リビジョンから Java持つライブラリの構築を支援するツールが研究者にソースコードを抽出し, それらの中のメソッドチェイ

よって提案されている [4, 7, 9, 14, 15].

ン出現数の経年変化を調査した. 分析の結果, ソース

しかしながらメソッドチェインスタイルが広く受け

コード 1 行あたりの長さ 2 以上のメソッドチェイン入れられていることを示す定量的な結果は, 我々の知の出現数は 2008 年から 2018 年まで増加し続けている限りでは, 存在しない. 統合開発環境などにメソッることが明らかになった. また, チェインされていなドチェインスタイル支援機能を追加するにもコストがいメソッド呼び出し数に対する, チェインされた呼びかかることや, 研究者の作ったツールを製品レベルに出し数の比率が 2008 年から 2018 年の間に 15%からするのにもコストがかかることなどを考えると, 現実28%に増加していることも明らかになった.のプログラマの需要を定量的に示すことは重要である. 客観的な情報を元に開発の是非や優先度などを判2 背景断できるようになるからである.

メソッドチェインスタイルは広く受け入れられていそこで本研究では「メソッドチェインスタイルが広ると言われている. メソッドチェインスタイルで記述

東京大学大学院 情報理工学系研究科

することでソースコードの可読性が向上すると考え

This is an unrefereed paper.

られているためである. 具体的には, 同じレシーバを繰り返して書かずに済む [6, 9], 意味的にまとまりのある部分を一つの式にまとめることができる [9, 14],左から右に自然言語のように読める [1], などが可読性の向上点として挙げられている. 中間変数が減ることもメソッドチェインスタイルが支持される理由に挙げられる [6]. 中間変数が減れば, 中間状態の命名に悩む機会が減り, どのような変数が存在するのかを気にする機会が減るなどして, 生産性が高まると考えられるためである.
メソッドチェインスタイルと, それを実現するライブラリ実装方法には様々な欠点も指摘されている. 具

List < String > list = new ArrayList ();list . add (c r e a t e R a n d o m S t r i n g () // Length 1); // Length 1
list . stream (). map ( str -> {return str. replace ( " foo " , " bar " ). replace ( " baz " , " qux " ); // Length 2}). forEach ( str ->System . out . println ( str ); // Length 1); // Length 3

図2

メソッドチェインとその長さ

体的には, 多くの 統合開発環境が提供する行レベルのbreakpoint 設定機能ではデバッグが行いにくい [6],3 手法

ﬂuent interface を持つライブラリは継承による機能本研究ではメソッドチェインの出現数の経年変化の拡張が困難である [2, 11], ﬂuent interface の構築は開傾向を元に「広く受け入れられているか」を考察す

発コストが高い上に維持コストも増大させる [2,9,11],る. 現在いくつの出現があるかという情報のみから広などが指摘されている.

く受け入れられているかを判断するのは困難である

上述したような定性的な議論はこれまでも行われてと考えたためである. 本研究ではメソッドチェインがいるものの, メソッドチェインスタイルが広く受け入増加傾向にあるのか, 減少傾向にあるのかを観察するれられていることを定量的に示した結果は未だ存在しことで結論を導くことを目指した.

ない. メソッドチェインスタイルの最大の利点である

調査に用いるデータセットは, GitHub 上の 3,461

可読性についての議論は主観的な部分が大きく, 広く個のレポジトリの各年末リビジョンから抽出した Java受け入れられている根拠とするには説得力に欠ける.

ソースコードの集合である. データセット中のソース

ライブラリ提供者にとっては ﬂuent interface の提供コードには, ソースコードが含まれるリビジョンの年,は負担が大きいと言われることを考えると, メソッドソースコードが含まれるレポジトリ名が対応づけら

チェインスタイルで利用し易いライブラリは少なく,れている. データセット構築に用いる 3,461 個のレポ

結果的にメソッドチェインスタイルの記述は少ないとジトリは, 2019 年 6 月 16 日から 2019 年 7 月 16 日も考えられる. また, 仮に広く受け入れられているこの間に, スター数の多い 1000 個の Java レポジトリとは認めるにしても, 実際どの程度のメソッドチェイを取得する GitHub API のレスポンス含まれていたンが書かれているのかは未知である.

レポジトリである.

メソッドチェインスタイルの利用に関する定量的な本研究では, メソッドチェインを 1 つ以上のメソッ情報は, 基盤的ソフトウェア開発や研究の方針決定に役ド呼び出しの連鎖と定義する. また, 連鎖したメソッ立つ. 例えば, メソッドチェインの途中に breakpoint

ド呼び出しの数をメソッドチェインの長さとして定義を設定する機能の提供がどれだけユーザの需要を満する. 例えば図 2 の Java コードには, 長さ 1 のチェたすかを統合開発環境の開発者が見極めることがでインが 3 個, 長さ 2 のチェインが 1 個, 長さ 3 のチェきるようになる. また, 研究レベルで存在する ﬂuentインが 1 個含まれている. 我々の定義では全てのメinterface の構築を支援するツール [4, 7, 9, 14, 15] がソッド呼び出しはメソッドチェインの一部となる. 通

どれだけ現実で役立つのか, それらのツールを製品レ

常長さ 1 のチェインはメソッドチェインとは呼ばれベルにする必要があるかを判断できるようにもなる.

ないが, 後の分析での取り扱いの都合から, メソッドチェインとして取り扱った.

2018
2008

# per line

10 10.8

10 30.6

10 50.4

10 710 9# per line

2016
2012
2008
230.2
101
Length1001021030.012018
2012

10 110 3

図445
Length678

メソッドチェインの相対出現数

フには比較のため 2018 年の分布も合わせてプロットしている.

10 5

図 3 からわかるように, 新しい年ほど多くメソッドチェインが出現していることが観察できる. 特に

10 710 9

2008 年には存在しなかったような極端に長いメソッドチェインが 2012 年, 2016 年には現れていることが101100Length102103

観察される.
どの年においても対数スケールにおいて線形な分

2018
2016

10 1
# per line

1.0

布が現れていることも特徴的である. 対数スケールにおいて線形であるとは, 1 行あたりの出現数を n, チェインの長さを l として

10 3log n = a log l + b10 5という形で表現できるということである. この式を変10 7n = Cla

形するとという形になり, 長さが長くなると出現数は急速に減

10 9101
Length100
図3102103

長さ vs. 1 行あたりの出現回数少していることがわかる. 現象が冪乗則 (Rich-get-richer 現象) に従う場合対数スケールで線形な分布が現れることが知られている [10]. しかし対数スケールで線形な分布になることは, 必ずしも現象が冪乗則に従っていることを示しているわけではない [10]. その

4 結果と考察ため「メソッドチェインの出現分布は冪乗則に従う」

図 3 のグラフは 2008 年, 2012 年, 2016 年時点でと結論できないが, このような分布の生成過程のモデのメソッドチェインの出現数分布をプロットしたもの

ル考案と「冪乗則に従うのか」の検討は興味深い今後である. 横軸はメソッドチェインの長さ, 縦軸はソーの課題である.

スコード 1 行あたりのメソッドチェインの出現数であ

対数スケールでは観察を行いにくかった出現数の増り, どちらの軸も対数スケールを用いている. 各グラ加量を具体的に知るため, 2018 年時点で 30%以上のがある. 具体的には以下に挙げるような点の調査と分

chained/non-chained

0.30析が必要である:0.25• プログラマが実際にメソッドチェインについて

0.20

どのような印象を持っているのか? インタビューを行う必要はないか?

0.15• Java 以外の言語ではどのような傾向が見られる0.10のか? Kotlin のような Java に比べて文法が柔

0.05

軟な言語でも同様に増加傾向にあるのか?

0.00• GitHub においてスター数が上位のレポジトリ

8200
図50201

2 014
2Year201

6201201

8

チェインされたメソッドの割合

はライブラリコードが多いが, アプリケーションコードでも前節と同様の結果になるのか?

• メソッドチェインとして記述できるのに, メソッドチェインスタイルで記述していない箇所は減少しているのか?

レポジトリ出現していた長さ 1 から 8 までのメソッド• 特定の規模の大きいレポジトリがメソッドチェチェイン出現数のさらに詳細な観察を行なった. 図 4

インを多用しているだけで, 多くのレポジトリでは, 2018 年の出現数を 1 とした場合の 2008 年, 2012増加していないのではないか?

年, 2016 年における相対的な出現回数をまとめた図• 一部の頻繁に使われるライブラリが ﬂuent in-である. 図 4 では縦軸横軸共に通常スケールを用いterface を提供しているだけで, 様々な部分で均ている.

等にメソッドチェインが均等に増えているわけで

図 4 から, 長さ 4 から 8 のチェインは 2008 年からはないのではないか?

2018 年で 10 倍程度, 2012 年から 2018 年に 2 倍以上• 2012 年から 2016 年の間に大きく出現数に変化に増加していることがわかる. 2016 年から 2018 年のが起こっているように観察されるが, Java プロ増加量はそれ以前ほどに大きくないものの, 25%程度

グラミングを取り巻く環境に変化があったのか?

は増加していることが観察される. 長さ 2 と長さ 3 のさらにこの結果を現実世界のソフトウェア開発に大チェインは長さ 4 以上の場合ほどの変化はないもの

きく役立てて行くには, 以下のような調査と分析も必の, 大きな増加が観察される.

要になる:

図 5 はチェインされていないメソッド呼び出し数に• 非常に長いチェインはどのようなチェインか?

対するチェインされているメソッド呼び出し数の比率• 既存研究 [4, 7, 9, 14, 15] などでは型を用いた構をまとめた結果である. 例えば図 2 の Java コードの文検査が提案されているが, この技術を応用でき場合, チェインされているメソッドは 5 個, チェインる場所はどれだけ存在するか? 特に文脈自由文されていないメソッドは 3 個と考え, 比率は約 166%

法の検査技術が必要になる箇所はどれだけ存在となる. 図 5 からも, 年々メソッドチェインスタイルするか?

で記述される場合が増えていることが観察される.

6 まとめ
5 今後の課題

本研究では「メソッドチェインスタイルが広く受け前節に示した結果から, メソッドチェインの出現数入れられているかどうか」を定量的に明らかにする調が増加傾向にあることが観察された. しかしながら査を行なった. 調査の結果, メソッドチェイン利用は「メソッドチェインが広く受け入れられているのか」

大きく増加していることが明らかになった. さらなるという問いを考える上ではさらに分析を進める必要調査による今回の結果の検証は今後の課題である.

参 考 文 献[ 1 ] Bodden, E.: TS4J: A Fluent Interface forDeﬁning and Computing Typestate Analyses, Proceedings of the 3rd ACM SIGPLAN International
Workshop on the State of the Art in Java ProgramAnalysis, 2014.
[ 2 ] Bugayenko, Y.: Fluent Interfaces Are Bad for
Maintainability, https://www.yegor256.com/2018/03/13/fluent-interfaces.html.
[ 3 ] Gil, Y. and Levy, T.: Formal Language Recognition with the Java Type Checker, Proceedings of30th European Conference on Object-Oriented Programming, 2016.
[ 4 ] Gil, Y. and Roth, O.: Fling — A Fluent API
Generator, Proceedings of 30th European Conference on Object-Oriented Programming, 2019.
[ 5 ] Grigore, R.: Java Generics Are Turing Complete, Proceedings of the 44th ACM SIGPLAN
Symposium on Principles of Programming Languages, 2017.
[ 6 ] Ilari Kajaste et al.: OOP - Method chaining- why is it a good practice, or not? - Stack
Overﬂow, https://stackoverflow.com/questions/1103985/method-chaining-why-is-it-a-good-pra
ctice-or-not. (Accessed on 08/02/2019).
[ 7 ] Levy, T.: A Fluent API for Automatic Gener-ation of Fluent APIs in Java, PhD Thesis, Israel
Institute of Technology, 2017.
[ 8 ] Michael Bayer et al.: SQLAlchemy - The
Database Toolkit for Python, https://www.sqlalc
hemy.org/. (Accessed on 08/02/2019).
[ 9 ] Nakamaru, T., Ichikawa, K., Yamazaki, T., andChiba, S.: Silverchain: a ﬂuent API generator, Proceedings of the 16th ACM SIGPLAN International
Conference on Generative Programming: Concepts
and Experiences, 2017.
[10] Newman, M. E.: Power laws, Pareto distributions and Zipf’s law, Contemporary physics, Vol. 46,
No. 5(2005), pp. 323–351.
[11] Pivetta, M.: Fluent Interfaces are Evil, https://ocramius.github.io/blog/fluent-interfaces-areevil/.
[12] Skymind, Inc.: Deeplearning4j, https://deeplearning4j.org/. (Accessed on 08/02/2019).
[13] The jQuery Foundation: jQuery, https://jquery.com/. (Accessed on 08/02/2019).
[14] Xu, H.: EriLex: An Embedded Domain Speciﬁc
Language Generator, 2010.
[15] Yamazaki, T., Nakamaru, T., Ichikawa, K., andChiba, S.: Generating a ﬂuent API with syntax checking from an LR grammar, Proceedings ofthe ACM on Programming Languages, No. OOPSLA(2019).