Object-Oriented Conference プロポーザル一覧

他イベントOK ロングセッション

C言語で設計・実装するオブジェクト指向システム

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

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

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

MVCであなたが感じた「オブジェクト指向じゃない感」は正しい ~MVCとDDDのギャップ~

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

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

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

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

MVCであなたが感じた「オブジェクト指向じゃない感」は正しい ~MVCとDDDのギャップ~

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

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

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

オブジェクト指向で考えるアプリケーションアーキテクチャ設計

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

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

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

ボトムアップで使える!オブジェクト指向のシンプルな考え方

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

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

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

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

Visitor Pattern の Expression Problem を解決する新しいデザインパターン

悉生游漩 StewEucen
デザインパターンのひとつに 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 の断末魔を、みなさんで見届けてくださいな。
2
他イベントOK ロングセッション

オブジェクト指向分析法をデータベーススキーマ設計に応用する

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

Reactコンポーネントでの型とValueObject

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

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

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

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

アジャイル時代のモデリング

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

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

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

classとstructの使いわけ

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

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

※このトークは基本的にSwiftの話をしますが、Swiftと同じようなclassとstructを持つ言語にも通用する…はずです。
2
他イベントOK ロングセッション

Swiftの「プロトコル指向」とは何者?

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

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

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

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

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

PHPでドメイン駆動設計を浸透するためにやったことと現状

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

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

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

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

※若干PHPに傾きよりですが、主題から逸れない内容になっています。
3
他イベントOK ロングセッション

関数型でソフトウェアをつくる

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

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

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

弊社のOOPに対する学習アプローチのご紹介

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

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

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

関心の分離って何?

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

歴史から学ぶ JavaScript の設計の思想と仕方

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

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

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

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

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

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

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

WEBフロントエンドにおけるオブジェクト指向設計の考察

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

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

このセッションでは
・WEBフロントエンドの「設計」についての考察
・昔から語られている技術が、フロントエンドにおいても十分活用可能であること
・具体的な改善アプローチの例
等をお話する予定です。

※ロングセッションの短縮版です。こちらでは、具体的な実装方法を中心にお話する予定です。
3
他イベントOK ロングセッション

WEBフロントエンドにおけるオブジェクト指向設計の考察

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

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

このセッションでは
・WEBフロントエンドの「設計」についての考察
・昔から語られている技術が、フロントエンドにおいても十分活用可能であること
・具体的な改善アプローチの例
等をお話する予定です。
1
他イベントOK ロングセッション

「モジュールとしてのマイクロサービス」と 「分割単位としてのドメイン」について考える

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

異なるモデリングパラダイムから見るオブジェクトモデル

a-suenami a_suenami
オブジェクトとは一体何でしょうか?

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

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

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

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

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