トーク

オブジェクト指向の設計において「関心の分離」「責務」が重要と語られている。さらに昔からモジュール設計においては「凝集度」と「結合度」が大事だと言われてきた。一方エリックエバンスのDDDでは、ユビキタス言語としてのドメインモデルを使って、ドメインエキスパートとコミュニケーションを図ることが大事だとしいる。つまり、「関心の分離」は要件から仕様化・設計・実装・テスト、さらにアーキテクチャ構築までの一連の活動に関わっている。
今回は「関心とは何か？」「責務との違いは？」など「分ける」ことについて、オブジェクト指向と関数型のマルチパラダイムの視点を加味して、簡単な思考実験を行いながら、物事の捉え方を体感します。
さあ、この無謀とも思える思考実験。「吉」と出るか「凶」と出るか。
モデルベースの用件定義手法であるRDRAをまとめていく時に使った「境界を引く」考え方を説明しながらトライします。

DDDはドメインモデリングを通じてソフトウェアの価値を高めようとする設計・開発手法です。
新しく得られたモデルに関する知見を頻繁にコードに落とし込む必要があるのですが、
それはソフトウェアにとっては非常に高い要求をしていることになります。
そこでDDDでは、オブジェクト指向の手法を利用して、メンテナブルで、拡張性の高いコードを書くことを目指しています。
このセッションでは、DDDではモデリング結果をどのようにコードに落とし、どのような利益を得られるのかを、具体的なコードを交えながら解説します。

ビジネスとしても技術としても合意できる、ビジネス対して十分な拡張性を持ったシステムアーキテクチャがほしい。
これを実現するために設計手法をつくってみました。数理的システム設計と呼んでいます。
自分が作りやすい、自分がマネジメントしやすい「やりやすい設計」を避けるための手法となります。
これは既存手法とは異なり、システムレベルでのよい設計をめざすものです。

この実現のために、パタンランゲージの始祖であるクリストファーアレグザンダー氏の理論をソフトウェアシステム設計に取り入れました。
まずシステムレベルでの分析と設計においては、15の幾何学的特性(美しい設計の根源には15の幾何学的な特性があるとアレグザンダーがみいだしたもの)を活用します。
全体性を重んじ、全体と部分をいったりきたりしながら、設計をすすめていきます。そして、その後にパタンランゲージを適用していきます。

オブジェクト指向の設計・実装方法を利用してフロントエンドを開発する方法を考えます。

Webフロントエンドの「設計」について、多くの場合はUIやコンポーネントといった「画面設計」の方法が語られます。一方、画面の背後に潜む条件や状態といった複雑さをどのように取り扱うかという問題は、それら「画面設計」の方法論にとっては関心の外にあり、これといった解答は与えてくれません。
現代のWebフロントエンドは「表示して終わり」といえるほど単純ではなく、そのアプリケーションとしての複雑さの解決には、「画面設計」とは別の方法が必要です。

この発表では、Webフロントエンドの画面よりも、その背後にあるアプリケーションとその複雑さに注目します。
Webフロントエンドが画面の後ろに抱える複雑さを解決するための方法として、いわゆる「オブジェクト指向設計」が変わらず有効であること、そしてそうした方法論の必要性について、考察した内容をお話します。

発表概要
・現代のWebフロントエンドの難しさ
・Webフロントエンドと「ドメイン」
・Webフロントエンドを「設計」することについて
・Webフロントエンドアーキテクチャ考察

モデリングのパワーを活かしながらアジャイルに開発を進める、軽量モデリングの手法を提案します。
アジャイル開発では、動くコード（そして自動化テスト）が重要な成果物として扱われます。では、設計はどこに行ったのでしょう？モデリングはもういらない？UMLは死んだ？ぼくはそう思いません。

"The code is the truth, but it is not the whole truth." -- Grady Booch

このセッションでは、アジャイル時代に相応しいモデリングの役割について探ってみたいと思います。合わせて、海外で話題の軽量モデリング手法、 C4 Model の概要もお話します。

オブジェクト指向は現代のシステム開発においてスタンダードな方法論の一つですが、「オブジェクト指向とはなんですか？」と問われると明確に答えられる方はわずかではないでしょうか？
理由は「オブジェクト指向」が指す意味が広すぎるからです。
正解がいくつもあるゆえに正解が見つからない、といった状態だと思います。

本セッションでは「概念投影指向」というものを提案したいと思います。
いわゆるオブジェクト指向（の一つ）ですがあえて別名称で紹介します。

システムは人間の代わりに処理等引き受けてくれるものです。
ですが、システムは人間の事を知りません。セマンティックギャップが常に存在します。
システムに人間の事を知ってもらう為に我々プログラマー存在すると言えるでしょう。

その為には、まず我々プログラマーが人間の事を知る必要がありそうです。

例えば、目の前にフレームがついた2枚組のガラスがあったとします。
ほとんどの人はこれを「メガネ」だと認識するでしょう。
でも、例えば今日初めて地球にきた人はそれをメガネとは思いません。
それはなぜでしょうか？
答えは簡単で我々人間がメガネという「概念」を知っているからです。
つまり、存在の前提には概念理解という暗黙の大前提があります。

システムも同じです。メガネ、ユーザーの名前、予約情報、全てオブジェクトとして存在させるには、まずは人間界にある「概念」を知ってもらう（投影する）必要があります。
概念投影指向とはこのような考え方に基づきます。

セッションにて概念投影指向とは何か？そのメリットは？具体的には？（PHPでのサンプルコードとなる予定です）といった部分にフォーカスをあて、あいまいだったオブジェクト指向設計の中でも明確な設計方針を示す事が狙いとなります。

昨今のシステムは、社内外のシステムと連携していて境界定義が難しいといわれています。だから、大きなシステムは人間が制御できるぐらいのサービスに分割する。それがマイクロサービスの考え方の一つです。こういったシステムを分割して構造化する手法は古くから「モジュール化」という手法が有名です。マイクロサービスは現代のモジュールだと考えています。そして、このモジュールは技術的観点よりビジネス的観点で分割したほうがよいといわれるようになりました。具体的にはドメイン駆動設計の「ドメイン」です。これらの「モジュールとしてのマイクロサービス」と 「分割単位としてのドメイン」はシステム設計を語るうえで重要なキーワードです。今回は、モジュール化とドメインの関係性について考察したいと思います。

オブジェクト指向言語によって作成されたアプリケーションでは、ごく限られた例外を除き、インスタンス化されたすべてのオブジェクトはいずれゴミとして消えゆくことが運命づけられます。
今日、多くの言語においてこれらオブジェクトのライフサイクル管理は自動化されており、「オブジェクトがメモリを使う」「オブジェクトが生きている」といった事実への関心が失われつつあるのではないでしょうか。
自動管理の恩恵を享受するあまり、私たち多くのエンジニアは気軽かつ無秩序にオブジェクトを生成しています。
その代償として、時折アプリケーションはメモリリークという牙をむき、私たちに襲いかかります。
このセッションは、普段注目されることの少ないオブジェクトライフサイクルとメモリ管理について、改めて思いを馳せることを目的にします。
オブジェクトが生まれてから消えゆくまでどのような流れをたどるかに着目し、メモリ管理の実装について初心者に向けて解説したいと思います。

Mathematicaは、項書き換え型言語と呼ばれますが、オブジェクト指向言語であるとはされていません。しかし、実は、基本的な関数の組み合わせだけで、一切のスクリプトを用いることなく、OOPを実現することができます。その核心部分がMathematicaで記述された関数の二重呼び出しです。
実現されたクラスそして内部に置かれるメソッドは関数型で表現されるゆえに、コンストラクションはクラス関数の呼び出しとして表され、結果としてインスタンスも関数型で表現されます。
関数型として表現されるゆえに、コンストラクションには連想配列（辞書型）を極めて容易に導入でき、メモリの許す限りの多数の初期化されたインスタンスを生成することができます。
このトークで、たとえMathematicaを知らなくとも、OOPがどのように構成されているかを知ることができます。なぜならば、Mathematicaの関数によりOOPを構成していく過程を見ることで、クラスとメソッドはどのような関係にあるかを知り、どうしてカプセル化が実現されるのかを知り、クラス関数の実行でコンストラクションとインスタンスの関係を知り、複数のクラスの関係から継承とは何かを知り、関数呼び出しの形式からポリモルフィズムを知ることができるからです。ラムダ計算を通じて、クロージャがOOPに包含される様子も目にすることができるでしょう。
そして、OOP環境が関数型として表現されるゆえに、強力なMathematicaのソルバーやグラフィックスと容易に組み合わせることができて、さらには、インスタンスをマルチコアにデプロイすることで並列計算への扉が開かれることを、実例でお示ししましょう。

オブジェクト指向プログラミングの歴史を振り返りながら、現在の状況と今後の方向性について考えてみます。

• 黎明期
• GUIとオブジェクト指向ブーム
• UMLとオブジェクト指向モデリング
• アジャイルムーブメントとオブジェクト指向プログラミング
• 関数型プログラミングとオブジェクト指向プログラミング
• ドメイン駆動設計とオブジェクト指向プログラミング
• マイクロサービシズとオブジェクト指向プログラミング

かつては、オブジェクト指向の本質といわれたものが、いまでは、わき役になったり、アンチパターンとされるものもある。
そういう流れの中で、これからのオブジェクト指向プログラミングは、どういう方向に進む可能性があるのか、考えてみましょう。

オブジェクトとは一体何でしょうか？

モデリングパラダイムとしてはオブジェクトの他にもデータモデルの設計によく使われるERモデルやリレーショナルモデル、または関数型言語のベースになっているラムダ計算などがあります。

それぞれのモデリングパラダイムには得意な表現/苦手な表現があり、本来は解決したい問題領域によってそれらを選択することが好ましいのですが、実際には多くの開発者が、クラスや関数、RDBのテーブルなどといった具体実装や言語機能/ミドルウェア機能に着目しやすく、モデルそのものの表現力について議論されることが少ないように感じています。

温故知新と言われるように、進化し続ける現代のソフトウェア技術の中にいる我々にとっても古くからあるこれらのモデリングパラダイムやそれを切り開いてきた先人たちの思想は学ぶ価値のあるものであり、その上でハードウェアが進化した現代においてそれらのモデルをどのように活用していくかが我々に求められている課題だと考えています。

本発表では、先人たちの思想をなぞりながら、オブジェクトが目指したものは何だったのか今一度再考し、その他のモデリングパラダイムとの共通点・相違点について述べていきます。また、異なるモデリングパラダイムの間に生じてしまうインピーダンスミスマッチをどのように最小化していくかについても一緒に考えていきたいと思います。

以下のような先人たちの名前にピンと来る人はぜひ聞きに来てください。（注: とりあげる人物は予告なく変更になる可能性があります）
アラン・ケイ、ストラウストラップ、バートランド・メイヤー、エドガー・F・コッド、クリス・デイト、ピーター・チェン
※ また、上述したようなモデリングパラダイムの直接の提唱者ではありませんが、ジェームス・コプリエンやリッチ・ヒッキーらの考えについてもとりあげます。