トーク

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

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

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

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

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

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

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

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

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

私自身は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に取り組んでいたとしても、戦略的設計を行なっていなかったがために後々陥ってしまう落とし穴もいくつか存在します。

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

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

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

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

(ロングセッション向けのセッションをショート向けに要所だけ抜き出したものとなります)
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と向き合ってきた私から色々と伝えることができればと思っています。

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

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

本セッションでは、オブジェクト指向以前に習得しておくべき抽象・構造・関連の考え方と活用の仕方について時間の許す限りお話します。

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

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 でやりましょうか。

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

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

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

【メインとなる対象層】

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

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

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

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

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

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

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

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

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

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

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

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

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