マルチパラダイムプログラミング

プログラミング言語を個別の機能で比較するのではなく、パラダイムの組み合わせで捉えることが大事です。その上で要件に合わせた言語選定や設計が求められます。本スライドではオブジェクト指向を起点に、マルチパラダイムプログラミングという考え方を紹介します。

Transcript

1. OOPから一歩踏み出そう マルチパラダイムプログラミング Takuya Tonaru
2. 目次 Multi-paradigm programming Object-oriented programming Functional programming Reactive programming
3. 今日の本題 • 伝えたいこと ◦ プログラミングをパラダイムの組み合わせで捉える ◦ 異なるパラダイムを柔軟に取り入れる • 第一歩としてFunctional ProgrammingとReactive Programmingを紹介する
4. Multi-paradigm programming • プログラミング言語は複数のパラダイムを含む ◦ https://en.wikipedia.org/wiki/Comparison_of_multi-paradigm_programming_languag es • 多様なパラダイムを理解して使いこなすことが大事 • パラダイムの取り込み方 ◦ 言語機能でサポート ◦ フレームワークやライブラリでサポート
5. Object-oriented programming • 現代の主流な言語の多くに備えているパラダイム • 基本的な考え方； ◦ オブジェクトは属性と振る舞いで構成されている（いわゆる カプセル化） ◦ オブジェクト同士が相互作用しあって目的の処理を組み上げる • 例） ◦ C++, Java, PHP, Ruby, Go, etc... Object A attribute method Object B attribute method
6. OOP言語でも異なる実装や活用 • プロトタイプ指向のJavaScript • 関数型言語の要素を取り入れたScala • リアクティブプログラミングのフレームワークであるRxJava OOP以外のパラダイムを含んでいる
7. Functional Programming • 基本的な考え方；(*1) ◦ 処理でなく結果にフォーカスする ◦ y=f(x)のような値を受け取り値を返す 関数を中心に捉える ◦ プログラムを結果を表す関数の組み合わせで考える • 手続き型との違い ◦ 手続き型：AならBを実行する　→　処理にフォーカス ◦ 関数型　：AならCになる　　　→　結果にフォーカス * 1: ここでは純粋関数型言語を前提に考える
8. FPの特性 • 副作用のない関数 ◦ 入力に対する結果が変わらない (*2) • イミュータブルなデータ ◦ あるデータにいつ参照しても値は変わらない • 副作用のない関数とイミュータブルなデータでプログラムを組むと 堅牢で壊れにくい * 2: 正確にはIOなど副作用のある処理は分離する
9. FPの特性 • 第一級関数 ◦ 関数をデータのように入力値として関数に渡したり返り値としてもらえる（高階関数） ◦ 結果を関数の組み合わせで表現する • ループ命令がない ◦ 関数の末尾で自身を呼び出す再帰関数で表現可能 ◦ ループという命令ではなく再度自身を呼び出した結果にフォーカスしている • FPは宣言型プログラミングで 可読性が高い
10. FPのパラダイムが取り込まれる理由 • 手続き型のデメリット ◦ 積極的にデータ構造とモジュールに切り出さないとスパゲッティになる ◦ 手続きを延々と並べたメソッドが量産されテストしづらく再利用性が低くなる 　→　プログラマごとにアウトプットの質の差が激しい • OOPのデメリット ◦ 状態を扱うことに秀でている反面、ミュータブルなオブジェクトを共有すると壊れやすい 　→　特に並列処理でオブジェクトを共有して破綻する • FPのパラダイムを導入して堅牢で可読性の高いプログラムを作る
11. 歴史的経緯 (*3) • 1980年代 ◦ PCの普及とともにCやBASICが広く使われる時代、 C++やObjective-Cの登場 ◦ 第二次AIブーム、LISPやPrologなど関数型言語が注目、 Haskellの登場 ◦ 通産省 シグマ計画の大失敗（官僚「１９９０年には６０万人のソフトウェア開発技術者が不足する！」） • 1990年代 ◦ ITバブルと崩壊の時代 ◦ C++が普及しつつあるなか Java、PHP、PythonやRubyが登場、OOPが主流になる • 2000年代 ◦ Webの台頭、情報システムの複雑・巨大化、 CPUのマルチコア化の時代 ◦ FPの再評価、F#やScalaの登場 • 2010年代 ◦ 関数型言語のパラダイムを取り込むのが一般化（ Java、Swift、Elixir、Kotlin, ... etc） * 3: あくまで主観です
12. Java8の例 • 時期 ◦ 2014年 • FPに由来する新機能 ◦ ラムダ式 ◦ Stream API ◦ Optional • Optionalとは ◦ 処理失敗をnullで表さずOptionモナドで包む技法の模倣 ◦ 安易に参照してヌルポでガッしない
13. Reactive programming • データの処理を、データストリームと変更の伝搬で表現するプログラミングパラダイム 処理A 処理B 処理C 処理D DataSource1 Output Stream DataSource2
14. リアクティブ宣言 2014年9月16日版 (v2.0) 求められているのは、システムアーキテクチャに対する明快なアプローチであると我々は考える。そして、必要な 側面の全ては既に独立に認識されている : 求めるものは、即応性と、耐障害性と、弾力性と、メッセージ駆動とを 備えたシステムだ。我々はこれをリアクティブシステム (Reactive Systems) と呼ぶ。 リアクティブシステムとして構築されたシステムはより柔軟で、疎結合で、 スケーラビリティがある。これによって開発 が容易になるだけでなく、変更を受け入れやすくなる。これらは 障害に対してより著しい耐性を持ち、たとえ障害 が起きても災害を起こすことなく優雅に対処する。リアクティブシステムは高い即応性を持ち、 ユーザに対して効 果的な対話型フィードバックを与える。
15. Reactive programmingの特性 • 各Actorは独立した内部状態とライフサイクルを持つ • In/Outは一方通行なメッセージの非同期処理のみ 即応性と耐障害性をもつActor（小さなシステム）を連結させ、大きなシステムを作り上げる Actor In Out
16. 実装例 • 言語 ◦ Erlang ◦ Elixir（Erlang VMで動作） • フレームワーク ◦ RxJava ◦ Spring WebFlux（Java） ◦ Akka（Scala）
17. パラダイムを取り込む • 言語レベルで取り込む ◦ 例）関数型言語を取り込みたい ▪ １．純粋関数型言語である Haskellを使う ▪ ２．関数型言語のパラダイムを言語レベルでサポートしている Scalaを使う • ライブラリで取り込む ◦ 例）リアクティブプログラミングを取り込みたい ▪ WebFluxを使う • 規約で取り込む ◦ 例）安全性の要件を満たすためにイミュータブルなデータを使いたい ▪ コーディング規約でイミュータブルなデータ型に利用を制限する
18. まとめ • プログラミングをパラダイムの組み合わせで捉える • 異なるパラダイムを柔軟に取り入れる • パラダイムの取り込み方 ◦ 言語サポート ◦ ライブラリ ◦ 規約