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

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

パターンとしてのActiveRecord、RailsとしてのActiveRecord

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

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

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

【トークのトピック】
・PofEAAで書かれたActive Recordのパターンはどういうものなのか
・RailsのActive Recordが強力と言われる由縁は何なのか
・Active Recordがもたらしたギャップ
2
他イベントOK ロングセッション

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

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

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

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

この発表では依存関係という切り口から、ドメイン駆動なアーキテクチャ設計を継続的に維持・改善していくための手法を、Java とアーキテクチャテストツールの ArchUnit を用いて紹介します。
3
他イベントOK ショートセッション

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

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

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

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

この発表では依存関係という切り口から、ドメイン駆動なアーキテクチャ設計を継続的に維持・改善していくための手法を、Java とアーキテクチャテストツールの ArchUnit を用いて紹介します。
2
他イベントOK ロングセッション

オブジェクト指向(メッセージ指向)を知っていますか?

takasek takasek
オブジェクト指向プログラミングといえば、「継承・カプセル化・ポリモーフィズムで成り立つやつでしょ?」と思われがちです。
クラスという言語機能によりデータとふるまいを定義し、インスタンス化し組み合わせ、可能ならば静的型検査による早期エラー発見を行うプログラミングパラダイム。父の名はビャーネ・ストラウストラップ。
そうですね、その認識は間違っていません。OOCの多くのセッションでは、クラス指向のオブジェクト指向の背景や技法、実践例について詳らかに語られることになります。

しかしそれとは根本的に違う、もうひとつの「オブジェクト指向」があることをご存知でしょうか?
いえ、「もうひとつの」という形容ではあまりに不十分かもしれません。「オブジェクト指向」という言葉は、最初にアラン・ケイが提唱したときには、こちらの「メッセージ指向」のことを指していたのですから。

本セッションは、以下のような内容で構成されます。

- メッセージ指向のコンセプトの紹介
- Smalltalk-72の実践
- 同じAppleプラットフォーム上で動作し互換性のある2言語による実装の比較
 - Objective-C: メッセージ指向
 - Swift: クラス指向の側面が強い
- 現代のプロダクトでのメッセージ指向のコンセプトの適用例
 - アクター理論などの紹介
 - 実例のデモ

■FAQ
Q. オブジェクト指向(プロトタイプベース)は知っていますか?
A. いえ…。
Q. Swiftをクラス指向というと語弊があるのでは?
A. その話は https://fortee.jp/object-oriented-conference-2020/proposal/dc44aa41-7c73-4eaf-af35-2655afb52d9a でやりましょうか。
8
他イベントOK ショートセッション

フレームワーク依存による潜在リスクをgRPCで強引に脱却する

塚本 久博 hihats
ActiveRecordパターン + MVCのような設計パターンにおいて、たとえばFormとDBテーブルの1レコードを1:1の密結合とすることを是としている場合、「その後の変更をクラス内で閉じたい」という私達の欲求は叶えられなくなっていきます。
さらに、多くの開発者に使われるWebアプリケーションフレームワークであればあるほど、各々の開発者がキャリアの中でそれまで積み上げたサービスオブジェクトの定義があり、それが形式知化されないまま開発が進んでいったりします。
そうなると、本来同じところにいるはずのクラスの役割が、どうしても異なるレイヤーに散らばりがちで、コードの見通しが悪くなる。さらにそれをルールで縛ることによる軋轢が生まれてしまうこともあります。

そもそもクラス設計をルールで縛ったところで、それが守られる保証もありません。「スピード優先」というお題目により蔑ろにされることもしばしば目にしてきました。

これは私たちが常に頭を抱えがちな問題ですが、そこでgRPCを利用することによって、強制的にAPIの出力(protocol buffer)をドメインオブジェクトと一致させ、「技術的にコードが複雑さを持ちにくくすること」と、「開発者間の齟齬をなくす」という両方の問題を解消できる可能性を提示してみます。

【メインとなる対象層】
- 開発現場で、オブジェクト指向設計に対する考え方のミスマッチで困っている
- チーム内のエンジニアの経験年数の差や設計スキルの差が大きくて標準化のコストが高い
- マイクロサービスアーキテクチャに興味あるけどどこから手をつけるかわからない
1
他イベントOK ロングセッション

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

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

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

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

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

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

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

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

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

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

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

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

※ショートセッションで採択の場合には、実践例を中心にご紹介したいと思います。
4
他イベントOK ショートセッション

クラス設計から学ぶコミュニケーション

広高 yutanpo_it
【概要】
人とのコミュニケーションをクラスの視点から考え、より伝わるコミュニケーションを取る方法を学ぶ

【対象者】
・オブジェクト指向 初心者〜
・人とのコミュニケーションに悩みを感じているエンジニア
・伝え上手、聞き上手になりたいエンジニア
・専門知識を素人に伝える事に難しさを感じているエンジニア

【内容】
仕事を振られたとき、初めての人と話すとき、やりとりで困った事にある人を対象に
クラスの視点からどのようにコミュニケーションを取ると良いか、なぜコミュニケーションが取れないかを解説し、
どのように人とコミュニケーションを取ると良いかをお話します。
また専門知識を相手にいかに短時間で理解してもらうかを「例え話」を元にお話します

【リスナーのゴール】
・社内外でのコミュニケーションを円滑に取れるようになってもらう
・話して伝わる楽しさを感じてもらう
・コミュニケーションに対する苦手意識を少しでも減らす

【なぜ私が話すのか】
・高齢者、小学生向けプログラミングスクールのメンターを通じて「素人にIT知識を伝える」のが上手
・周りの様々なレベルのエンジニアに合わせて「彼らの理解しやすいコミュニケーション」を取るのが上手
・エンジニアに「伝わる楽しさ」を知ってもらうためにコミュニティ運営をしているから
1
他イベントOK ロングセッション

クラス設計から学ぶコミュニケーション

広高 yutanpo_it
【概要】
人とのコミュニケーションをクラスの視点から考え、より伝わるコミュニケーションを取る方法を学ぶ

【対象者】
・オブジェクト指向 初心者〜
・人とのコミュニケーションに悩みを感じているエンジニア
・伝え上手、聞き上手になりたいエンジニア
・専門知識を素人に伝える事に難しさを感じているエンジニア

【内容】
仕事を振られたとき、初めての人と話すとき、やりとりで困った事にある人を対象に
クラスの視点からどのようにコミュニケーションを取ると良いか、なぜコミュニケーションが取れないかを解説し、
どのように人とコミュニケーションを取ると良いかをお話します。
また専門知識を相手にいかに短時間で理解してもらうかを「例え話」を元にお話します

【リスナーのゴール】
・社内外でのコミュニケーションを円滑に取れるようになってもらう
・話して伝わる楽しさを感じてもらう
・コミュニケーションに対する苦手意識を少しでも減らす

【なぜ私が話すのか】
・高齢者、小学生向けプログラミングスクールのメンターを通じて「素人にIT知識を伝える」のが上手
・周りの様々なレベルのエンジニアに合わせて「彼らの理解しやすいコミュニケーション」を取るのが上手
・エンジニアに「伝わる楽しさ」を知ってもらうためにコミュニティ運営をしているから
1
他イベントOK ロングセッション

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

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

クリーンアーキテクチャを読んで学ぶオブジェクト指向

綺麗なコードを書きたいという一心でオブジェクト指向を学び始めた僕が、最初に手に取った本である「Clean Architecture 達人に学ぶソフトウェアの構造と設計」を基に、オブジェクト指向について学んだことをお話していきます。(クリーンアーキテクチャ自体についてはそれほど触れない予定です)
2
ショートセッション

オブジェクト指向思春期への誘い〜オブジェクト指向の楽しみ方、学び方〜

ふー fuubit
私がゼロからどのようにオブジェクト指向思考を学び、思春期になっていったのか。オブジェクト指向を学んでみて良いなと思っていること、楽しいなと思っていることなどをお話します。私自身の経験をお話しすることで、これからオブジェクト指向を学びたい人に役立てていただけるセッションになればと考えています。
1
他イベントOK ショートセッション

オブジェクト指向プログラミングを言語化する

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

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

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

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

■本セッション想定聴講者
- プログラム初学者
- オブジェクト指向プログラミングがよくわからない人
- 「あー、オブジェクト指向ね。わかるわかる。説明は出来ないけど」な人

■本セッションに向かない聴講者
- オブジェクト指向を掌握してる方
- オブジェクト指向を利用して正しくプログラムが書ける方
1
他イベントOK ショートセッション

デザインパターンから学ぶオブジェクト指向

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

各デザインパターンの概要をご説明した後で、実例としてAndroid OSのアプリケーションフレームワークで適用されている部分をご紹介します。

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

■ 紹介予定のデザインパターン(当日までに増減する可能性があります)
- Builder
- Singleton
- Adaptor
- Proxy
- Mediator
- Observer
2
他イベントOK ロングセッション

ビジネスロジック実装パターン

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

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

「オブジェクト指向入門」に入門してみよう

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

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

主な内容:

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

オブジェクト指向プログラミングを学ぶのにもっとも良い言語は何か?

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

取り上げる予定の言語:

Prolog, SQL, Erlang,
Lisp, Smalltalk,
Shell Script, Perl, PHP, Ruby, Python
JavaScript, IO,
C , C++, Go, Rust,
Haskell, Elm
Java, C#
4
他イベントOK ロングセッション

オブジェクト指向プログラミングの現在・過去・未来

増田 亨 masuda220
オブジェクト指向プログラミングの歴史を振り返りながら、現在の状況と今後の方向性について考えてみます。

- 黎明期
- GUIとオブジェクト指向ブーム
- UMLとオブジェクト指向モデリング
- アジャイルムーブメントとオブジェクト指向プログラミング
- 関数型プログラミングとオブジェクト指向プログラミング
- ドメイン駆動設計とオブジェクト指向プログラミング
- マイクロサービシズとオブジェクト指向プログラミング

かつては、オブジェクト指向の本質といわれたものが、いまでは、わき役になったり、アンチパターンとされるものもある。
そういう流れの中で、これからのオブジェクト指向プログラミングは、どういう方向に進む可能性があるのか、考えてみましょう。
7
他イベントOK ショートセッション

デザインにオブジェクト指向を適用する

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

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

なぜクラスの継承はアンチパターンなのか

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

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