トーク

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

過去に失敗した代表例から今ならどう設計するか、という観点でお話します。中心になる戦術面のトピックは以下です

• 軽量DDDの功罪
• ドメインモデル貧血症対策
• 集約の境界定義の善し悪し

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

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

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

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

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

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

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

コード例はPythonで、 https://github.com/ftnext/python-image-processor にて開発中です。
構成は https://gist.github.com/ftnext/b77cadb7f49741f4654dec0ac2df6bfb にあります

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

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

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

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

もしかしたらこだわり過ぎかもしれない。意地悪な揚げ足取りになっているかもしれない。単なる言葉遊びかもしれない。そんな不安を抱えるときもありますが、このセッションを経て「言葉」について一緒に語り合える人が生まれたら何よりです。

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

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

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

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

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

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と向き合ってきた私から色々と伝えることができればと思っています。

【このセッションで持ち帰れるもの】
・PofEAAで書かれたActive Recordのパターンはどういうものなのか
・RailsのActive Recordが強力と言われる由縁は何なのか
・Active Recordがもたらしたギャップと合わせるべき使い方

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

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

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

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

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

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

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

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

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

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

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

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

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

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

主な内容：

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

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

取り上げる予定の言語：

Prolog, SQL, Erlang,
Lisp, Smalltalk,
Shell Script, Perl, PHP, Ruby, Python
JavaScript, IO,
C , C++, Go, Rust,
Haskell, Elm
Java, C#

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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