トーク

みなさんは「OOUI」という言葉を聞いたことがあるでしょうか。
これは「Object Oriented User Interface」と呼ばれるもので、アプリケーションのデザインをする上で画面上のコンポーネントとアプリのデータをオブジェクト指向によって対応付ける方法論です。
オブジェクト指向によってもたらされるデータとアクションの整理された構造がUIに反映されることで、OOUIはユーザーにより分かりやすい直感的な操作性をUIとして提供します。

本セッションでは、例として1つのアプリケーションを取り上げて、オブジェクト指向ベースでオブジェクトを抽出してUIを設計していく中で、OOUIがどのようなプロセスで構築されていくのかを具体的に説明します。

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

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

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

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

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

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

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

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

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

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

デザインパターンのひとつに 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 の断末魔を、みなさんで見届けてくださいな。

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を持つ言語にも通用する…はずです。

今回、（12月時点の）現在進行系で開発が進んでいる案件でLaravelを採用し、
更にドメイン駆動設計の概念を埋め込むような開発手法を取り込んでいます。

しかし「オブジェクト指向」という名前は知っているが内容までは知らず、
かつ古き時代のPHPと現行のPHP7.xの理解が混ざる混沌の中、治水するために奔走した話です。

【概要】

1. PHPとオブジェクト指向：オブジェクト指向の認識を定める
2. ドメイン駆動設計：ドメイン領域を伝え広める（途中経過）
3. ドメイン駆動設計：インフラストラクチャー層、どこまで裁定するか
4. ドメイン駆動設計：形（画面）から入るのを止めさせたかった（失敗談）
5. まとめ：治水、結果は……？

プロダクトのオブジェクト指向が曖昧だったり、
チーム内でドメイン駆動設計を広めようと奮迅されている方への一つの指針としてお伝えできればと存じます。

※若干PHPに傾きよりですが、主題から逸れない内容になっています。

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

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

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

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

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

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

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

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

今やテストのないプロダクトは大きなリスクを抱えて当然な世情であり、
テストを整備しながら開発を進めることは普通に意識してなければならないと思います。
開発速度をなるべく落とすことなくこれを推進するには工夫が間違いなく必要ではないでしょうか。

自分が現在所属している開発プロジェクトでの実装過程で、UnitTestの量産を支援する、
かつテストデータのコードによる整備を必要最小限に抑えるちょっとした仕組みを編み出しました。

オブジェクト指向プログラミングの特徴の１つである継承を大いに利用したこの仕組みについて、
ご紹介させていただければと思います。

【概要】
本セッションでは、Go本体のソースコードを紹介しながら、オブジェクト指向プログラミングを解説します。

【背景】
いまやメジャー言語の仲間入りを果たしたGo言語。Go自体のソースコードはGitHubに公開されており、Russ Coxをはじめとする超一流のプログラマが実装に携わっています。そんなGoは構文自体がC言語に近いため、いわゆるオブジェクト指向とは一線を画すと思われがちです。しかし、ソースコードの随所にはオブジェクト指向のプラクティスが幾つか散りばめられています。「Goらしさ」と「オブジェクト指向」が共存したプログラミングの一例をご紹介します。

【こんな方におすすめ】
・ソースコードを見ながらオブジェクト指向を理解したい
・実用（言語処理系）の実装においてオブジェクト指向の使用例を知りたい
※ Goが未経験の方でも解説しながら進行するため、問題ありません

「オブジェクト指向など知ったこっちゃない」と言わんばかりに、何も設計せずただただswitch文を書き連ねて行った先の地獄を、実体験を踏まえ、面白おかしく皮肉った動画です。
(参考：クソコード動画「共通化の罠」 https://twitter.com/minodriven/status/1127539251761909760 )

動画の中で何がマズかったのか、設計やチームワーク等の観点で解説致します。
そしてこの動画を他山の石として、実際のチーム開発での活用ポイントについても説明します。

GoF（Gang of Four）のデザインパターンは、我々が日々行う設計行為において基礎的な要素を占めています。ですが、一方で「デザインパターンをなんとなく知っている」状態から「デザインパターンを正しく使う」状態へ向かうには、大きな壁があると感じています。
その壁をどうよじ登れるかを考える上で、デザインパターンが何に影響を受けたのかを理解することは大きなヒントになるはずです。それは、建築家アレグザンダーの「パタン・ランゲージ」という概念です。「パタン・ランゲージは何を解決しようとしたのか」・「デザインパターンとパタン・ランゲージの差異は何か」といった点を理解することで、デザインパターンのより深い理解に繋がります。
そこから、デザインパターンにおいて「理解すればいい点」と「実践値から磨くべき点」がそれぞれどこなのかを抑える、使い方の言語化を試みます。