トーク

「あー、オブジェクト指向ね。わかるわかる」本当にそうでしょうか。

なんとなくわかったふうに思っている事が、説明すると実際はうまく伝えれなかったりすることがあると思います。

オブジェクト指向プログラミングを正しく言語化を行い、共通認識を共有することを本セッションの目的とします。

実コードも添えたPHPを例に、正しいオブジェクト指向プログラミングを学びましょう。

■本セッション想定聴講者

• プログラム初学者
• オブジェクト指向プログラミングがよくわからない人
• 「あー、オブジェクト指向ね。わかるわかる。説明は出来ないけど」な人

■本セッションに向かない聴講者

• オブジェクト指向を掌握してる方
• オブジェクト指向を利用して正しくプログラムが書ける方

本トークでは、普段よく利用しているデザインパターンの中でいくつか概要を説明します。

各デザインパターンの解説とオブジェクト指向の考え方、そしてその実例としてAndroid OSのアプリケーションフレームワークへの適用例をご紹介します。

教科書で学んだだけでは、デザインパターンの実際の適用シーンがイメージし辛いかと思いますので、Android OSだとこのように利用されていますよという具体例を示すことで、オブジェクト指向とデザインパターンについての理解が進むための参考になれば頂ければ幸いです。

■ 紹介予定のデザインパターン（規定時間に納める目的で、当日までに増減する可能性あり）

• Builder
• Singleton
• Adaptor
• Proxy
• Mediator
• Observer

業務アプリケーションによく登場する、ビジネスロジック（ビジネスルール）を、オブジェクトで表現する場合の実装パターンをカタログ的に紹介します。
なお、実装言語は、Javaです。

• 顧客
• 顧客とのコミュニケーション
• 商品
• 価格と割引
• 注文処理
• 在庫とアベイラビリティ
• スケジュール
• 契約、方針、ルール
• 基本パターン（金額、数量、日付、区分、セット、マップ、リスト）

バートランドメイヤー著「オブジェクト指向入門(OOSC)」の要点を紹介しながら、オブジェクト指向プログラミングの考え方とやり方を解説します。

オブジェクト指向プログラミングの初心者から、初心に立ち返ってオブジェクト指向プログラミングを考えなおしてみよう、というベテランエンジニアまで参考になる内容にしたいと思います。

主な内容：

Part A: 諸問題　-- オブジェクト指向プログラミングの動機
Part B : オブジェクト指向への道 -- モジュール性、シームレス性、直接的な写像
Part C : オブジェクト指向の技法 -- クラス、オブジェクト、契約による設計、継承、型付け
Part D : よりよい方法の選択 -- 方法論、クラスの見つけ方、オブジェクト指向分析、オブジェクト指向の教え方
Part E : すすんだ話題 -- 並行、分散、永続化、GUI
Part F : 実践の環境　-- Simula から Java へ

一般的には、オブジェクト指向のプログラミング言語とはされていない言語も含めて、さまざまな言語を取り上げながら、オブジェクト指向プログラミングを学ぶ、という観点から、それぞれの言語の特徴をまとめてみます。

取り上げる予定の言語：

Prolog, SQL, Erlang,
Lisp, Smalltalk,
Shell Script, Perl, PHP, Ruby, Python
JavaScript, IO,
C , C++, Go, Rust,
Haskell, Elm
Java, C#

オブジェクト指向プログラミングを学ぶ上で誰もが「クラスの継承」という操作を学び、複数のクラスが持つ共通部分を1つのインターフェースに括り出すために利用してきたと思います。
しかし、ただコードの共通化を目的とした継承は往々にしてアンチパターンとなり、巨大な基底クラスが悪い未来を我々に運んでくることはすでに多くのソフトウェアエンジニアが認識している事実でしょう。

本セッションでは、なぜオブジェクト指向でよく語られる継承という操作がアンチパターンと呼ばれるのか、また本来どういった対応が正しいのかを、サンプルコードを交えて説明します。

今日では、実用的なアプリケーションのためのプログラミングはオブジェクト指向を前提としてC++やJavaやそれ以降に登場した多くのプログラミング言語のような、オブジェクト指向言語により行われるのが主流になっています。一方で、動作環境における様々な制約などから依然としてC言語も幅広く使われているという現状があります。

C言語はオブジェクト指向を構文として直接サポートしてはいませんが、構造体や関数ポインタなどの既存の構文やプリプロセッサのマクロを駆使して、オブジェクト指向を担うシステムを設計・実装することが可能です。C++をはじめとするオブジェクト指向のネイティブコンパイラ型言語で、コンパイラが自動で面倒を見てくれるようなオブジェクト指向の仕組みの細部を、あえてC言語で設計・実装・考察することによって、クラスやオブジェクトなどの、オブジェクト指向の実現に必要な要素が、メモリやCPUのような低レベルのレイヤーでどのように動作していくのかといった、基礎的な側面を垣間見ることができます。

本セッションでは、C言語から利用可能な既存のオブジェクト指向システムを簡単に紹介しつつ、自作のライブラリ(https://gitlab.com/melioprojects/meliogarden)の中で独自に設計・開発しているオブジェクト指向システムを詳細に紹介します。そのライブラリの中で、クラス、継承、(ある程度の)多態性などといったオブジェクト指向の実現に必要な要素を、C言語でどのように実装したのかを、その考え方や問題点(そして解決可能なものについてはその戦略・選択肢)も含めて解説していきます。また、実装していく中では避けがたい大量のボイラープレート・コード(不可欠だが本質でない記述)を、プリプロセッサのマクロを用いて可能な限り簡単に表現していく取り組みについても説明していきます。

2000年代前半のJava + Strutsブームの頃から多くの会社が「Java/MVCでオブジェクト指向で開発しています」と標榜していました（Javaの部分はPHPでもRubyでもなんでもいい）。しかしクラスとオブジェクトを利用していればオブジェクト指向なのだろうか。

近年のドメイン駆動設計（DDD）の流行によるオブジェクト指向設計の再発見により、オブジェクト指向設計を再勉強している方は多いと思いますが、オブジェクト指向の説明で必ず出てくる「モノがクラスで、モノの振る舞いはクラスに含まれる」という説明に対して、過去に「オブジェクト指向設計で開発していた」とされたMVCが異なる設計になっていると疑問を感じないだろうか。Controllerなんて振る舞いが独立したクラスになっているじゃないか、Modelに振る舞い――Controllerが受け持つ各種制御や、Viewが受け持つ表示制御――を持たせるべきなのではないだろうか、と。

MVCとDDDにはなぜギャップがあるのか。そのギャップを視点――関心の切り口――に「仕組みのとしての視点」「課題解決（ビジネス）としての視点」という違いがあるという目線で解説します。
そして今後DDDに基づいた設計をしたときにマイクロサービスアーキテクチャ、さらにはマイクロフロントエンドの概念に続く道について今改めて理解を整理したいと思います。

※ショートセッションで採択の場合は具体例を省略した要点のみのエッセンシャル版で発表したいと思います

2000年代前半のJava + Strutsブームの頃から多くの会社が「Java/MVCでオブジェクト指向で開発しています」と標榜していました（Javaの部分はPHPでもRubyでもなんでもいい）。しかしクラスとオブジェクトを利用していればオブジェクト指向なのだろうか。

近年のドメイン駆動設計（DDD）の流行によるオブジェクト指向設計の再発見により、オブジェクト指向設計を再勉強している方は多いと思いますが、オブジェクト指向の説明で必ず出てくる「モノがクラスで、モノの振る舞いはクラスに含まれる」という説明に対して、過去に「オブジェクト指向設計で開発していた」とされたMVCが異なる設計になっていると疑問を感じないだろうか。Controllerなんて振る舞いが独立したクラスになっているじゃないか、Modelに振る舞い――Controllerが受け持つ各種制御や、Viewが受け持つ表示制御――を持たせるべきなのではないだろうか、と。

MVCとDDDにはなぜギャップがあるのか。そのギャップを視点――関心の切り口――に「仕組みのとしての視点」「課題解決（ビジネス）としての視点」という違いがあるという目線で解説します。
そして今後DDDに基づいた設計をしたときにマイクロサービスアーキテクチャ、さらにはマイクロフロントエンドの概念に続く道について今改めて理解を整理したいと思います。

複雑なシステムの設計を行う際には、そのシステムを様々な観点（ビュー）を通して観ることで、そのシステムを構成するコンポーネントを把握することが重要です。それらの各コンポーネントがどのような責務を担い、周囲のコンポーネントとの間でどのような相互作用を期待するかを整理することが堅牢なシステムの実現に繋がります。コンポーネントが責務を持ちそれらの相互作用で大きな価値を提供する構造は、まさにオブジェクト指向の世界観と重なります。

本セッションでは、Webアプリケーションを１つのシステムとみなして、それを構成する複数のコンポーネントをどのように分割し、どのような関係性に整理するのがよいか考える過程をお話する予定です。具体的にはアプリケーションを支える基盤的な横断的関心事を題材に、モデリングを通じて責務を整理していく予定です。

本セッションを通じて、オブジェクト指向をプログラミング以外の場面でも活用できるイメージを持ち帰って頂けると嬉しいです。

オブジェクト指向については、書籍も多数出版されており、勉強会も各地で開かれています。しかし、オブジェクト指向という理論的な枠組みと、実際のプログラミング言語を使って、オブジェクト指向でプログラムを書くことの間には「知識や経験」の大きな隔たりがあります。

また、実際の現場においては、自身のおかれている立場や既存コードベースの問題から、良い設計とは程遠いプログラミングを強いられることもありえます。

本トークでは、ボトムアップでオブジェクト指向を考えて、実際にプログラムを書くときに押さえておく「簡単な」ポイントについて解説します。オブジェクト指向が「ちゃんと」分かっていなくても、また既存コードベースが手続き型に近いような状態であっても、シンプルな決まりを守っていくだけでプログラムの品質は上げられます。

オブジェクト指向で良いプログラムを書くにはどうしたら？とお悩みの方が「これだけ単純だったら、自分でも実践できそう！」そう思っていただけるトークです。

デザインパターンのひとつに Visitor Pattern があります。このパターンには、古くから Expression Problem が存在していましたが、この問題を Java で type safety に解決する新しいデザインパターンを発見しました。Dispatcher Pattern と呼んでいます。

以下のリンクで前半部分が読めます。
日本語
https://qiita.com/StewEucen/items/37696bf0372d65833311
英語
http://steweucen.hatenablog.jp/entry/2018/05/19/150313

ある人のご指摘で、この内容では 80% しか解決できていないのが判明しています。残りの 20% を解決する方法は発見済みですが、まだブログなどで公表していません。

ちょうどよい機会なので、OOC の場を借りて完全版を発表したいと考えました。Expression Problem の断末魔を、みなさんで見届けてくださいな。

オブジェクト指向の分析手順から導き出した、勘と経験に頼らないデータベース設計の手法を紹介します。リレーショナルデータベースを使う場合、テーブルやフィールドとその関連づけなど、スキーマを構築しなければなりません。ある程度経験があって反射的に設計ができる方々もたくさんいらっしゃいますが、その一方で問題のあるスキーマで構築してしまうような事例も時折見られます。要求をそのままスキーマにしてしまったり、求められるがままに設計をしてしまったりして、後からうまくできないことが見つかってしまったという経験を持つ方も多いと思います。レイヤーアーキテクチャの原則だと、最下層に相当する部分の設計がスキーマであり、そこは安定していて変化がないことを前提としています。しかし、どうしてもうまく動かないとなると、スキーマの変更と上位レイヤーの調整という大変な作業になってしまうような改変をしなければなりません。そこでそうならないように、システム構築の最初にきちんとスキーマを作りましょうということになるのですが、その「きちんと」行う方法は、オブジェクト指向の方法論を応用できます。課題をオブジェクト指向分析法で分析をし、そこからスキーマを定義する方法を紹介します。何がフィールドになるのかという基準や、なぜ中間テーブルが必要になるのかということの説明を試みます。言い換えれば、データベースのスキーマを作る前提でのオブジェクト指向分析法です。「常識」や「慣習」といった不確かな基準でなく、スキーマの1つ1つを定義する理由を考え、納得の行く設計をしたいと考えている皆さんには、ヒントになる手法でしょう。データベース設計にこれから取り組む方や、一歩踏み込んだスキーマを目指す方に、聞いていただきたい内容です。

React.js/React Nativeでのコンポーネントの定義と分割の方法、そしてデータの型に関する問題についての考察を紹介します。

Reactのようなコンポーネント指向Viewライブラリでの実装において、コンポーネントの分割・定義については単純な分解の単位分けではなく、「ユーザがアプリケーションを操作する上でUIをどう捉えどう操作するか」を分析することが重要です。
分析をもとにコンポーネントをオブジェクトに定義したり、単純なGUIの部品などに分類し、それぞれに属する値や操作を整理することでユーザ目線の情報設計・ UI設計を実践できると考えています。

しかし、コンポーネントのpropsやstate、状態管理の値などはプリミティブ型が基本となっています。
これでも基本的な型の恩恵を受けている様ではありますが、アプリケーションの内容や規模によっては値の制限や制約を表しているとは言い難いと思います。

このセッションではそうしたコンポーネントを定義し分割する方法とそれに扱う値の型定義についてValueObjectを活用した方法とその恩恵についてお話できればと思います。

SwiftやC#を始め、最近の多くのオブジェクト指向言語を支えているclassとstruct。彼らは同じように抽象化に使え、同じようにプロパティーやメソッドの定義ができます。そんな同じような機能を持つclassとstruct、実際コードを書く時どっちを選ぶべきか？

このトークはSwiftを用いて、classとstructの根本的な違いである「参照型」か「値型」かを切り口に、classとstructの使いわけを話していきます。

※このトークは基本的にSwiftの話をしますが、Swiftと同じようなclassとstructを持つ言語にも通用する…はずです。

オブジェクト指向（以下OOP）は偉大です。我々はクラスの継承を使って共通の処理を切り出し、コードの再利用性を高め、しかも人間がより読みやすい抽象度の高いプログラムが書けるようになりました。

しかし同時にOOPは問題点もあります。親を継承した子供は親について把握せずにメソッドをオーバーライドするのはバグの温床にもなるし、そして何も考えずにとりあえず共通しそうな処理を親に詰め込むと気がつけばゴッドクラスを生み出してしまいがちです。

これらの問題点を解決すべく、Objective-Cに代わるアップルの新しい公式開発言語Swiftに、今までのOOPが残されつつも、アップルは新たに「プロトコル指向（以下POP）」という概念を導入しました。クラスを継承するOOPとは違い、POPはありとあらゆる型がプロトコルに適合するアプローチをとることによって、共通処理のコード再利用と、継承による暗黙な動作共有の解消を両立させました。

では、POPは一体どのようなものですか？POPのProtocolはこれまでのProtocolや他言語のInterfaceとは何が違うのか？POPは一体我々にどんな恩恵をもたらすのか？POPは銀の弾丸になるのか？

このトークは、これまでのOOPやObjective-Cの歴史を振り返りながら、SwiftのPOPについての技術的な話と、ちょっとエモい話をしていきます。

JavaScriptやGo、PHP、Rubyなど、毛色の違う様々な言語でオブジェクト指向と闘ってきました。

そんな中、最近ではTypeScriptを使い、関数型の考え方でプログラミングをしています。いわゆるclassを使うことは(ほとんど)なくなり、純粋関数を組み合わせて、宣言的にコードを書いています。では、オブジェクト指向を忘れてしまったのか？いえ、そうではありません。関数型であるからこそ、オブジェクト指向のエッセンスが随所ににじみ出る、そのような思いをひしひしと感じています。

オブジェクト指向の真髄は、「コンポーネント化」であり、小さいまとまりでソフトウェアをつくりあげることです。関数型であることとオブジェクト指向で書くことは矛盾しません。昔ながらのコアな設計を柱としながら、開発効率の高い関数型で開発する。そのあたりを、他の言語などと比較しつつ、詳しく話したいと考えています。

OOPの良さは書籍からの情報収集だけではなかなか分かりません。
弊社が過去にオブジェクト指向設計の読書会を実施したところ「現実のプロダクトのどこにどう当てはめればいいのか分からない」といった感想が挙げられました。

そこで一部の有志で「理論と実践をつなげる」という目的を掲げて、読書よりも実践とディスカッションを重視した勉強会を開始しました。
Robert C. Martinの書籍で扱われている給与システムの例を題材に、OOPの知識を活用しながら、実際に動くシステムをモブプログラミングで作り上げています。
またOOPだけでは語ることのできない現実のシステム開発を、CleanArchitecture・DDDなどの知識を駆使し、参加者それぞれの学習のサイクルを回すようにしながら進めています。

今回の発表では読書会・実践による勉強会それぞれを経験した立場から、弊社流のOOPに対する学習アプローチについて皆様が持ち帰れるようになるべく一般化して発表させていただこうと思っております。

10年前 iPhone が誕生し, スマートフォンの時代になった今, 我々が望むものは, 実はモバイルアプリではないでしょうか？

現代のフロントエンド, もっと言うと JavaScript の開発では, コンポーネント指向による開発がほぼデファクトスタンダードになりました. それは, Facebook 社が生み出した JavaScript フレームワーク「React」の誕生を皮切りに, 一気に全世界的にコンポーネント指向が普及し, 現在に至ったと思っています. web ページの各要素・パーツをコンポーネントという単位に区切り, そこで JS や CSS のスコープを閉じることで, 再利用性も高めつつ責務を分ける, そして開発者は各コンポーネントを配置していく作業にシフトしていきました.

一方でモバイルアプリの開発を見ると, やることは大きく以下の２つだと思います.

・buttonなどのパーツの配置　※スタイリングも含む
・イベントハンドラの設定

これは今我々フロントエンドエンジニアがやっている開発と, 酷似していると思いませんか？また, web の大きな流れとして, はじめは web だったのが, モバイルが誕生しモバイルファースト（レスポンシブ対応も含む）と言われる時代になり, それにより PWA や AMP という技術も産まれました.

このことから, web の進化はモバイルアプリの開発に寄っていると思えます. これ以外にも, パフォーマンス改善・UXUI の設計・アクセシビリティ・push 通知など色んな要素を考えないといけませんが, それはモバイルアプリケーション開発でも同様です.

以上を加味し, 一度 JavaScript フレームワークの歴史を振り返りつつ, 今後のフロントエンドの設計や開発に思いを語ってみたいと思います.

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

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

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

発表概要（予定）
・現代のWebフロントエンド模様
・Webフロントエンドの責務分担考察
・Webフロントエンドアーキテクチャ考察

※ロングセッションの短縮版を予定しています。