Object-Oriented Conference トーク一覧

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

関心の分離って何?

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

DDDはオブジェクト指向を利用してどのようにメンテナブルなコードを書くか

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

デザインパターンの使い方をパタン・ランゲージとの比較から考える

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

契約による設計事始め

丹賀健一 dnskimox
オブジェクト指向プログラミングの古典的な教科書として、バートランド・メイヤー氏の『オブジェクト指向入門』があります。
この書籍の『原則・コンセプト』編では、OOPを実践する上で重要な考え方である「契約による設計」について詳細に解説されています。
契約による設計は、現代のプログラミング言語においては「アサーション機能」として実装されています。
ではこのアサーション機能、いったいどのような考えの元で利用すれば、本来の用途に即した効果を発揮するのでしょうか?
簡単に導入できて非常に強力なツールであるアサーションを用いて、信頼性の高いソフトウェアを作る方法をご紹介したいと思います。
4
採択 他イベントOK ショートセッション

クソコード動画「switch文」

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

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

数理的システム設計-ビジネスと技術制約を繋ぐ手法-

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

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

WEBフロントエンドにおけるソフトウェア設計の考察

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

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

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

発表概要(予定)
・現代のWebフロントエンド模様
・Atomic Designについて
・Webフロントエンドの責務分担考察
・誰が「ロジック」を持つのか
・Fluxアーキテクチャについて
・Webフロントエンドアーキテクチャ考察
1
採択 他イベントOK ショートセッション

オブジェクト指向の「語る」と「示す」

かわべたくや kawakawa
オブジェクト指向を操るとき、私たちは当然のように新しい世界を構築しています。

「鳥(オブジェクト)」が「飛ぶ(メソッド)」

この簡単な例からも色々考えることができます。
・鳥オブジェクトを継承したツバメ・スズメも飛べるのか
・それだと同じく継承したペンギン・ダチョウも飛べてしまうのか
・ペンギンは飛ぶではなく水中では泳ぐなのか
・宇宙空間でも飛ぶといえるのか

しかし、
「鳥が飛ぶ」が成り立つと世界では余計な考えが不要となります。
ペンギン・ダチョウは存在せず、水中・宇宙空間でも無いのです。

つまり、オブジェクト指向は“現実の単語”を足掛りに、現実とは異なる世界を構築していると言えます。
私たちはこの行為を「モデリング」と呼んでいます。

「鳥が飛ぶ」とひとつ語るだけでモデリングされた世界の多数の一面を示すことができます。
では普段モデリングされた世界を私たちはどうやって、語ることによって示しているのでしょうか。
そして、どこまでが語りうることの限界なのか、示せれる限界はどこにあるのか。
時間が許す限り「語る」と「示す」の気づきを発表したいと思います。
5
採択 他イベントOK ショートセッション

Goのソースコードから読み解くオブジェクト指向プログラミング

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

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

【こんな方におすすめ】
・ソースコードを見ながらオブジェクト指向を理解したい
・実用(言語処理系)の実装においてオブジェクト指向の使用例を知りたい
※ Goが未経験の方でも解説しながら進行するため、問題ありません
2
採択 他イベントOK ショートセッション

オブジェクトの無い世界

さっぴー川原 sapi_kawahara
貴方は秘密めいた書籍を拾う、
そのとき、辺り一帯は眩い光りに包まれた。

貴方はオブジェクト概念が無い平行世界に転送されました。
全てのコードにオブジェクトの概念が無いのです、何もかもがコピペされている、そのような世界です。
そんな世界でも最初は何とか生きてこれたが、次第にオブジェクト概念が無いことに苦痛を感じ始めます。
何とかしなきゃ!何とかしなきゃ!
貴方は今まで生きてきたエンジニアの知識を駆使して、このオブジェクトが無い世界に、オブジェクトの概念を広めていこう!


補足:オブジェクトが無い言語が、どうやってオブジェクト構造を構築していくか、それをストーリー仕立てで話していきます。
4
採択 他イベントOK ロングセッション

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

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

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

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

概念投影によるオブジェクト指向設計の考え方とその方法

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

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

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

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

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

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

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

振る舞いからモデリングするオブジェクト指向な開発プロセス

集約のエンティティ pictiny
オブジェクト指向に基づく設計において、メンタルモデルを適切にオブジェクトで表現するために、
オブジェクトの関心や責務を日々意識されているかと思います。

現在私の関わるプロジェクトでは、設計の初期からオブジェクトの責務に対する解像度を上げるため、
要件定義の段階でユースケースを記述する開発プロセスを採用しています。

ユースケースを記述することで、システムが満たすべき振る舞いが明らかになり、オブジェクトの責務に対する理解が深まります。
また、ドメインエキスパートと仕様を議論するツールとしても実用性があります。

対象のオブジェクトが複雑である場合はユースケース記述に加えて、CRCという手法を実施してモデリングをしています。

本発表では、ユースケース記述やCRCを使ったモデリングによるオブジェクト指向の開発プロセスと、
それらを実践している現場のプラクティスをご紹介します。

主なトピック
- ユースケース記述から始める要件定義
- ユースケースを使ったドメインエキスパートとのコミュニケーション
- CRC(クラス、責務、コラボレータ)を使ったモデリング
- DDDに取り入れた事例紹介
3
採択 他イベントOK ショートセッション

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

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

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

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

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

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

「神クラス」問題の本質を、「サブジェクト-オブジェクト」二重化エンティティモデルで理解する

たなかこういち Tanaka9230
「神クラス」とは、一つのクラスに余りにも多くの機能性を装備してしまい、コードが肥大化した様子を示すアンチパターンである。幾重にもSRP違反になってしまっている状態である。「神クラス」は、幅広いユースケースへ懸命に対応しようとする中で生み出されてしまう。

「神クラス」は、いわゆる業務系システムにて生じがちで、対して、技術的な装置、例えばHTTP Server、複合機の制御システム、などでは生じにくい。

業務システムではなぜ神クラスが出現しやすいか?業務システムのクラスの外部仕様は業務担当者の脳内にある。素朴に客観的に存在するとみなせない。対して、技術的な対象は、素朴に客観的に存在すると見なせる。業務システムでは、系の本質はむしろ利用者(=クライアント)の脳内イメージそのものなので、系に対する要求発生源を単一に収斂させることができない。

ここに、系のクライアントの脳内イメージを「サブジェクト」と称し、複数のクライアントの「サブジェクト」を調停・統合・合意したモデルを「オブジェクト」と称したとき、いわゆる「エンティティ」は、本質的にサブジェクト-オブジェクトの二重構造を取るというモデルを提示する。
8
採択 他イベントOK ロングセッション

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

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

オブジェクトライフサイクルとメモリ管理を学ぼう

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

Mathematicaで一から作り上げるオブジェクト指向プログラミング環境

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

オブジェクト指向のその前に - 凝集度と結合度

そな太 sonatard
1990年代以降オブジェクト指向プログラミングの普及により、クラス設計、インターフェース設計、GoFのデザインパターンなどが提唱され、近年ではMVC系、DDD、Clean Architectureなどのアーキテクチャの議論が盛んに行われています。

これらももちろん大切ですが言語やアーキテクチャに依存せず、多くのプログラマが必ず検討をする設計として「関数分割」が存在しています。
関数分割の基準については、上記のデザインパターンやアーキテクチャでは議論されていません。

関数の実装は世のプログラマの全員が毎日行うことであり、欠かせない設計であると言っても過言ではありません。

しかし「テスタビリティが高い関数にする」のような基準に留まり、明確に言語化されていることが少ないです。

そこで本セッションではこの関数分割の良し悪しを測る指標として提唱されている凝集度と結合度を紹介します。
これらは構造化プログラミングをベースとした近代の多くの言語すべてに適用できる概念です。

本セッションにでは、以下を理解することができます。

- 7つの凝集度と7つの結合度について
- 関数分割の基準
- レビュー時のレビュアーとレビュイーの納得感
- 凝集度、結合度を理解することで、気がつくことができる見過ごされがちな問題
- 新しく提案されたアーキテクチャが、凝集度や結合度の観点で改善されているということ(近年ではReact Hooksが該当します)

また現実の世界では、論理的凝集と時間的凝集が現場で見過ごされて採用されてしまうケースが多いです。関数にフラグを渡して処理を分岐していませんか?
実際に発生するケースとその問題点を詳細に紹介することで、理論だけではなくより具体的に日常の開発で役立てていただければと思います。
9
採択 他イベントOK ショートセッション

DDD を支えるアーキテクチャテスト

かわなみゆう kawanamiyuu
ドメイン駆動設計はオブジェクト指向設計原則のうえに成り立つ設計プラクティスです。

つまり、ドメイン駆動でシステムを設計することは「オブジェクト指向設計をちゃんとやる」ということにほかなりません。検討の対象はクラスだけではありません。もう少し大きな単位、パッケージ/モジュール/レイヤー、まで視野を広げます。

依存関係が注意深く設計され、単一の責任を持ったモジュールやパッケージが、境界付けられたコンテキストをかたちづくります。レイヤーやパッケージの依存関係の逆転により、ドメインは自身の関心の範囲内でビジネスロジックの実現に集中できます。

この発表では依存関係という切り口から、ドメイン駆動なアーキテクチャ設計を継続的に維持・改善していくための手法を、Java とアーキテクチャテストツールの ArchUnit を用いて紹介します。
2
  • 1 (current)
  • 2
採択者
仮採択 非採択 重複 Type: 初心者向け Type: 設計 Type: フロントエンド Type: 体験談 Type: テスト Type: 歴史 Type: 実装 Type: 概念 Type: DDD Type: 上級者向け