トーク

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

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

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

オブジェクト指向言語の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)

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

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

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

【メインとなる対象層】

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

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

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

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

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

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

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

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

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

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

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

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

■本セッション想定聴講者

• プログラム初学者
• オブジェクト指向プログラミングがよくわからない人
• 「あー、オブジェクト指向ね。わかるわかる。説明は出来ないけど」な人

■本セッションに向かない聴講者

• オブジェクト指向を掌握してる方
• オブジェクト指向を利用して正しくプログラムが書ける方

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

各デザインパターンの解説とオブジェクト指向の考え方、そしてその実例としてAndroid OSのアプリケーションフレームワークへの適用例をご紹介します。

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

■ 紹介予定のデザインパターン（規定時間に納める目的で、当日までに増減する可能性あり）

• Builder
• Singleton
• Adaptor
• Proxy
• Mediator
• Observer

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

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

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

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

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

※ショートセッションで採択の場合は具体例を省略した要点のみのエッセンシャル版で発表したいと思います

オブジェクト指向については、書籍も多数出版されており、勉強会も各地で開かれています。しかし、オブジェクト指向という理論的な枠組みと、実際のプログラミング言語を使って、オブジェクト指向でプログラムを書くことの間には「知識や経験」の大きな隔たりがあります。

また、実際の現場においては、自身のおかれている立場や既存コードベースの問題から、良い設計とは程遠いプログラミングを強いられることもありえます。

本トークでは、ボトムアップでオブジェクト指向を考えて、実際にプログラムを書くときに押さえておく「簡単な」ポイントについて解説します。オブジェクト指向が「ちゃんと」分かっていなくても、また既存コードベースが手続き型に近いような状態であっても、シンプルな決まりを守っていくだけでプログラムの品質は上げられます。

オブジェクト指向で良いプログラムを書くにはどうしたら？とお悩みの方が「これだけ単純だったら、自分でも実践できそう！」そう思っていただけるトークです。

デザインパターンのひとつに Visitor Pattern があります。このパターンには、古くから Expression Problem が存在していましたが、この問題を Java で type safety に解決する新しいデザインパターンを発見しました。Dispatcher Pattern と呼んでいます。

以下のリンクで前半部分が読めます。
日本語
https://qiita.com/StewEucen/items/37696bf0372d65833311
英語
http://steweucen.hatenablog.jp/entry/2018/05/19/150313

ある人のご指摘で、この内容では 80% しか解決できていないのが判明しています。残りの 20% を解決する方法は発見済みですが、まだブログなどで公表していません。

ちょうどよい機会なので、OOC の場を借りて完全版を発表したいと考えました。Expression Problem の断末魔を、みなさんで見届けてくださいな。

React.js/React Nativeでのコンポーネントの定義と分割の方法、そしてデータの型に関する問題についての考察を紹介します。

Reactのようなコンポーネント指向Viewライブラリでの実装において、コンポーネントの分割・定義については単純な分解の単位分けではなく、「ユーザがアプリケーションを操作する上でUIをどう捉えどう操作するか」を分析することが重要です。
分析をもとにコンポーネントをオブジェクトに定義したり、単純なGUIの部品などに分類し、それぞれに属する値や操作を整理することでユーザ目線の情報設計・ UI設計を実践できると考えています。

しかし、コンポーネントのpropsやstate、状態管理の値などはプリミティブ型が基本となっています。
これでも基本的な型の恩恵を受けている様ではありますが、アプリケーションの内容や規模によっては値の制限や制約を表しているとは言い難いと思います。

このセッションではそうしたコンポーネントを定義し分割する方法とそれに扱う値の型定義についてValueObjectを活用した方法とその恩恵についてお話できればと思います。

SwiftやC#を始め、最近の多くのオブジェクト指向言語を支えているclassとstruct。彼らは同じように抽象化に使え、同じようにプロパティーやメソッドの定義ができます。そんな同じような機能を持つclassとstruct、実際コードを書く時どっちを選ぶべきか？

このトークはSwiftを用いて、classとstructの根本的な違いである「参照型」か「値型」かを切り口に、classとstructの使いわけを話していきます。

※このトークは基本的にSwiftの話をしますが、Swiftと同じようなclassとstructを持つ言語にも通用する…はずです。

OOPの良さは書籍からの情報収集だけではなかなか分かりません。
弊社が過去にオブジェクト指向設計の読書会を実施したところ「現実のプロダクトのどこにどう当てはめればいいのか分からない」といった感想が挙げられました。

そこで一部の有志で「理論と実践をつなげる」という目的を掲げて、読書よりも実践とディスカッションを重視した勉強会を開始しました。
Robert C. Martinの書籍で扱われている給与システムの例を題材に、OOPの知識を活用しながら、実際に動くシステムをモブプログラミングで作り上げています。
またOOPだけでは語ることのできない現実のシステム開発を、CleanArchitecture・DDDなどの知識を駆使し、参加者それぞれの学習のサイクルを回すようにしながら進めています。

今回の発表では読書会・実践による勉強会それぞれを経験した立場から、弊社流のOOPに対する学習アプローチについて皆様が持ち帰れるようになるべく一般化して発表させていただこうと思っております。

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

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

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

発表概要（予定）
・現代のWebフロントエンド模様
・Webフロントエンドの責務分担考察
・Webフロントエンドアーキテクチャ考察

※ロングセッションの短縮版を予定しています。

今やテストのないプロダクトは大きなリスクを抱えて当然な世情であり、
テストを整備しながら開発を進めることは普通に意識してなければならないと思います。
開発速度をなるべく落とすことなくこれを推進するには工夫が間違いなく必要ではないでしょうか。

自分が現在所属している開発プロジェクトでの実装過程で、UnitTestの量産を支援する、
かつテストデータのコードによる整備を必要最小限に抑えるちょっとした仕組みを編み出しました。

オブジェクト指向プログラミングの特徴の１つである継承を大いに利用したこの仕組みについて、
ご紹介させていただければと思います。