Object-Oriented Conference トーク一覧

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

O/RマッパーとOOPの落とし穴とその回避法

渡辺祐 nabedge
Object-Relational-Mappingフレームワークは、文字通りオブジェクト指向プログラミング言語とRDBMSの架け橋となるはずの基本ツールです。しかしその使い方を間違えれば、待っているのは技術的負債との気が遠くなるほど長い戦いです。JVM系言語におけるO/RマッパーのObjectとRelationalの間にあるべき設計思想は?MVCフレームワークとの適切な境界線は?境界線を優しく自動制御する方法は?転職サイトの開発現場から、生の声をお届けします。
1
採択 他イベントOK 2020/02/16 11:50〜 共2-101 ロングセッション

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

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

オブジェクトの無い世界

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

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


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

過去の失敗例から再考するモデル駆動設計

かとじゅん j5ik2o
過去に失敗した代表例から今ならどう設計するか、という観点でお話します。中心になる戦術面のトピックは以下です
- 軽量DDDの功罪
- ドメインモデル貧血症対策
- 集約の境界定義の善し悪し
他イベントOK ロングセッション

原則を振り返って納得する例外処理10の不思議

もちだ mike_neck
例外を無視してはいけないと言われるけど、例外処理に何をすればよいのかわからない。

オブジェクト指向プログラミングを始めた頃にこのような疑問を持ったことがある人は多いのではないかと思います。このセッションでは例外の定義・例外処理の原則を振り返ることによって、初心者・初級者が抱く例外処理にまつわる10の疑問に答えていきます。例外処理がよくわからない初級者の方だけでなく、例外処理を雰囲気でやってしまっていたため初学者に質問されてもなんとなく経験と勘でしか答えられない中級・ベテランの方も納得いただける(かもしれない)セッションです。
8
採択 他イベントOK 2020/02/16 15:00〜 共1-301 ショートセッション

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

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

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

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

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

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

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

契約による設計事始め

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

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

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

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

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

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

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

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

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

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

CSSの命名規則とオブジェクト指向

しんくう shinkufencer
CSSはその管理のしにくさからいろいろなアプローチが試されてきました。その中でオブジェクト指向を取り入れたOOCSSが生まれ、それを参考にした命名規則が様々登場しました。

本セッションではOOCSSとそこから続くいくつかのオブジェクト指向とCSSの命名規則の考え方をプログラマの視点から追っていきます。

【このセッションで持ち帰れるもの】
・CSSが抱える問題点とそれに対してのオブジェクト指向的なOOCSSというアプローチの考え方
・OOCSSとそれらに影響を受けたCSSの命名規則と考え方
2
他イベントOK ロングセッション

変更しやすいコードを目指して、構造化プログラミングのコードをオブジェクト指向で書き直す(Python編)

nikkie ftnext
「オブジェクト指向をやってみたいけど、どこから始めればいいか、具体的にどう書けばいいかわからない」
という方に向けて、
構造化プログラミングで手続き的に書かれたコードをオブジェクト指向で書き替える方法を示します。

私自身はPythonの入門書で学習して、構造化プログラミングで手続き的に書けるようになりました。
また、Javaに代表されるオブジェクト指向に関わる言語の経験はほとんどありません。
業務でPythonを書く中でコードの変更に時間がかかり、オブジェクト指向を身に着けて「動作し、変更しやすいコード」が書けるようになりたいと痛感しています。

この裏には、Pythonの入門書でオブジェクト指向に踏み込む本が少ない状況があると考えています。
私のようにPythonで本格的にプログラミングをする人にとって、変更しやすいコードを書くための情報が不足しているという課題があります。

オブジェクト指向を身につける方法として、先輩エンジニアから『ThoughtWorksアンソロジー』の「オブジェクト指向エクササイズ」を教わりました。
エクササイズに沿って入門書のコードを変更することで、少しずつオブジェクト指向がつかめ始めています。

私がエクササイズに沿ってどのようにコードを書き換えたかをとことん具体的に共有することで、
変更しやすいコードが書けないという課題を抱えた方が、オブジェクト指向に挑戦するきっかけが提供できると考えています。

コード例はPythonで、 https://github.com/ftnext/python-image-processor にて開発中です。
構成は https://gist.github.com/ftnext/b77cadb7f49741f4654dec0ac2df6bfb にあります
3
採択 他イベントOK 2020/02/16 14:00〜 共1-301 ショートセッション

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

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

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

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

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

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

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

オブジェクト指向の前に、言葉にこだわる。

大平道介 mohirara
本セッションが目指すのは「言葉に手を抜かず、きちんと考える人」を増やすことです。

セッション内のトピックは大きく次の3点です。

1. 言葉にこだわるとはどういうことか
2. 言葉にこだわると何が嬉しいのか
3. 言葉にこだわるための戦略と具体的な戦術

言葉にこだわることで表現力の高いオブジェクト指向プログラミングが実現される。
そんな体験から発見した「言葉とオブジェクト指向プログラミングの重要な関係性」を発表します。

もしかしたらこだわり過ぎかもしれない。意地悪な揚げ足取りになっているかもしれない。単なる言葉遊びかもしれない。そんな不安を抱えるときもありますが、このセッションを経て「言葉」について一緒に語り合える人が生まれたら何よりです。
6
採択 他イベントOK 2020/02/16 15:30〜 共1-301 ショートセッション

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

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

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

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

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

Eclipse Collectionsで学ぶオブジェクト指向の実装パターン

伊藤博志 itohiro73
Javaのオープンソースソフトウェアとして公開されているEclipse Collectionsは、「コレクション」というドメインを扱ったフレームワークで、オブジェクト指向のプラクティスが詰まっています。

本セッションではEclipse Collectionsの元プロジェクトリードが実際のソースコード例を用いながらさまざまなプラクティスを紹介していきます。
カプセル化、継承、ポリモーフィズムといったオブジェクト指向の基礎を起点に、クラスやメソッドの名前付けやテストにおけるオブジェクト指向の考え方に至るまで解説します。
3
他イベントOK ロングセッション

DDDにおける戦略的設計と戦術的設計

伊藤博志 itohiro73
ドメイン駆動設計において、エンジニアにとって最初にとっつきやすいのは戦術的設計と呼ばれる概念かと思います。エンティティや値オブジェクト、サービスやリポジトリなど、コードレベルで実装をイメージしやすいため、軽量DDDとしてここからDDDを導入し始めることも多いでしょう。

しかしながら、中長期的に継続的に成長していくソフトウェアを開発するには戦略的設計が重要な役割を果たします。短期的にはメリットがある戦術的DDDに取り組んでいたとしても、戦略的設計を行なっていなかったがために後々陥ってしまう落とし穴もいくつか存在します。

本セッションでは、ドメイン駆動設計においてなぜ戦略的設計が重要なのか、戦略的設計のプロセスを通らずに戦術的設計を行なった場合どういう弊害が起こりうるのかをわかりやすい例を挙げながら解説していきます。また、戦略的設計を推し進めていくためのプラクティスも共有します。
5
他イベントOK ショートセッション

MVCとGUIアーキテクチャのいま2020

しんくう shinkufencer
オブジェクト指向言語のSmallTalk向けに考え出されたMVC。そのMVCの概念ができてから、その派生で様々なGUIアーキテクチャの考え方が登場してきました。またWebブラウザ、スマートフォンアプリなど、表示の機構も様々に変化し、その時の時流や技術のトレンドを取り込み枝葉が分かれるように進化を遂げています。

本セッションではそんなGUIのアーキテクチャに関して2020年時点でどんな経過をたどってきたのか15分で紹介します。

【このセッションで持ち帰れるもの】
・通常のアーキテクチャとGUIアーキテクチャの違い
・MVCから派生した様々なGUIアーキテクチャパターンの概要
・MVCから別れたFlux,Reduxなどのパターン
3
他イベントOK ショートセッション

ざっくり見るパターンとしてのActiveRecord、RailsとしてのActiveRecord

しんくう shinkufencer
(ロングセッション向けのセッションをショート向けに要所だけ抜き出したものとなります)
Active Recordは書籍「Patterns of Enterprise Application Architecture(PofEAA)」で「DBのテーブル等の列をラップし、DBアクセスをカプセル化し、ドメインロジックを追加するオブジェクト」としてオブジェクト指向を使ったデザインパターンの一つとして世に知れ渡りました。
ですが現在ではRuby on Railsの普及に伴い、デザインパターンとしてではなく、Railsの機能名としてのActive Recordのことを指す場面が多く見受けられます。また、そんな中ででRailsを使って様々な設計技法にチャレンジしようとすると、Active Recordが阻害要因となり、断念されるケースが多く見かけます。

そこで本セッションではもともとPofEAAで語られたActive Record、そしてRailsで実装されているActive Recordを通して、本来パターンとしてのActiveRecordはどういう場面で一番真価を発揮し、またRailsのActiveRecordがどんな形でブロッキング要因になっているのかを紐解いていければと思います。

Railsを利用している人にはパターンとしてのActive Recordのパターンとしての特徴を、利用していない人には何故ここまでRailsの中心と言われるようなものになっているのかを、設計手法を考えながら業務でのRailsと向き合ってきた私から色々と伝えることができればと思っています。
2
他イベントOK ショートセッション

オブジェクト指向以前

Masayuki Asanuma as_masa
オブジェクト指向言語にある程度慣れてくると、次にオブジェクト指向らしく設計・実装するにはどうすれば良いのかという壁にぶつかりませんか?動物が、人が、車がとかの例では、なかなかオブジェクト指向らしく設計・実装するイメージが沸かないと思います。
また、オブジェクト指向に長けた人のソースコードを読むと、理路整然に記述されており感動したことがありませんか?

壁に悩む人やオブジェクト指向に長けた人を見ていて、オブジェクト指向らしくするにはその前に習得しておく考え方があると考えるようになりました。
それは抽象・構造・関連です。
おそらく皆さんが過去に何らかの形で習得していたり、普段活用している考え方だと思います。

本セッションでは、オブジェクト指向以前に習得しておくべき抽象・構造・関連の考え方と活用の仕方について時間の許す限りお話します。
3
採択 他イベントOK 2020/02/16 17:30〜 共1-301 ショートセッション

経験者がいない状態で、戦略的DDDを現場でやってみた話

岡本滉平 koko72_flavor
DDD、という単語を昨日まで知らなかった自分がいきなりBounded Contextを探すことになった。

超展開でDDDの世界に引き込まれ、社内に有識者がいるのかも分からない状況から戦略的DDDをやった話をします。
大まかなアジェンダは以下を考えています。
・そもそもDDDって?
・実際にドメインを分割する活動の中でやったアプローチの紹介
・私なりに戦略的DDDをやった結果わかったこと

DDDの本はとんでもなく分かりにくいし、戦略的DDDの部分は特に抽象的すぎてもはや何が書いてあるのか全く分かりませんでした。
もちろん、どう実践すればいいのかなんて全く分からず、途方に暮れていました。
このトークを通じて、戦略的DDDがやりたい、知っているけど最初何したらいいか分からない。という方の悩みが解決できればと思っています。

したがって、実際にやったこととその振り返りをメインで話します。
具体的には、以下の内容と分かったことを詳細に話します。
・本を読む。ネットサーフィンする。
・twitterでDDDで有名な人にいきなり質問をして得られたリプライのご紹介。
・自作のワークショップを企画してやってみる。
・休日に人を集めてEventstormingとやらをやってみる。


戦略的DDDの理論についてはなるべくシンプルに説明し、実際にとったアプローチを中心にお話しようと思います。
イメージがしやすく、最初の一歩が踏み出しやすいよう、なるべく具体的に話します。よろしくお願いします!
他イベントOK ショートセッション

変更しやすいコードを目指して、構造化プログラミングのコードをオブジェクト指向で書き直す(Python編)

nikkie ftnext
「オブジェクト指向をやってみたいけど、どこから始めればいいか、具体的にどう書けばいいかわからない」
という方に向けて、
構造化プログラミングで書かれたコードをオブジェクト指向で書き替える方法を示します。
15分の中で「この書き換え指針に基づき、こう書き換えた」とどんどん紹介していきます。
コード例はPythonで、 https://github.com/ftnext/python-image-processor にて開発中です。
以下に構成を示します。

- 自己紹介 (1min)
- 背景:入門書は構造化プログラミング (1min)
- 課題:入門書のように書けるようになったが保守しにくい (1min)
- 解決策:オブジェクト指向 (1min)
- アプローチ:『現場で役立つシステム設計の原則』『ThoughtWorksアンソロジー』の「オブジェクト指向エクササイズ」を参考に入門書のコードを書き直す (1min)
- 対象のスクリプト紹介 (2min)
- パスで指定した画像を縮小する
- 画像の入ったディレクトリも指定可能
- 概要:対象の画像を洗い出し、縮小する処理を呼び出す
- 以下書き換え方
1.対象と保存先を扱うクラスと縮小処理を表すクラスに分けて設計(1min)
2.ディレクトリ指定のために、対象と保存先のファーストクラスコレクションを作成:マジックメソッドの上書きとUserListの使用の2通り(2min)
3.保存先の指定を追加→ファーストクラスコレクション作成を修正(1min)
- 変更しやすさ:サブコマンドでグレースケールにもできるように→共通インターフェースを持つグレースケール処理クラスを作る(抽象クラス使用)(2min)
- まとめ(1min)
- 質疑(1min)
1
  • 1 (current)
  • 2
  • 3
  • 4
採択者
仮採択 非採択 重複 Type: 初心者向け Type: 設計 Type: フロントエンド Type: 体験談 Type: テスト Type: 歴史 Type: 実装 Type: 概念 Type: DDD Type: 上級者向け