見出し画像

Object-Oriented Conference 2024に参加してきました

Jimmy

2024/3/24（日）に開催された「Object-Oriented Conference 2024」に参加してきたので、その内容と学んだことを共有します。

おことわり

  • 今回のレポートは非公式的なものであり、自分なりに整理したものです。

  • 「こんなこと言っているんだな～」と思ってみていただければと<(_ _)>

Object-Oriented Conferenceとは

Object-Oriented Conference はオブジェクト指向をテーマに、アイデアを共有し、議論を深めることで、みなさんの知見を深めるためのイベントです。
オブジェクト指向といっても、分析設計から、現場で活かすためのプラクティスなどさまざまなテーマがあります。ソフトウェアの設計やプログラミングパラダイムの歴史について語るもよし、既存の設計手法に問題定義するのも、ネタに全振りするのもなんでもOK！です。参加者の皆様がそれぞれの新たな発見に出会えるようなイベントを目指しています。

OOC2024公式サイトから抜粋

今回が初参加でした。

聴講したセッションで学び/気づきになった部分

私がセッションを聴講して、とくに学び/気づきになった部分を共有します。
※講演全体の概要ではないです。
※見出しに概要もしくは発表資料のリンクを添付したので、気になる方はそちらを参照してください。
※このイベントは動画公開もあるとのことでした。

オブジェクト指向のリ・オリエンテーション　～歴史を振り返り、AI時代に向きなおる～

SOLIDの原則などを理解していない場合はDDDを導入するべきではない

OOPの活用レベルを5段階で表現していました。

よくドメイン駆動設計がよいというお話を聞くので、導入してみようと思っていましたが私はまだ段階3のところだなと思い、まずはオブジェクト指向の理解を深めていこうと感じました。

クソコード動画『カプセル化 Mk-II』で考える、上手くカプセル化できない理由

クソコード動画に共感

講演序盤にクソコード動画『カプセル化 Mk-Ⅱ』が上映されました。

この動画の内容がおもしろく、実業務で「この感じあの動画と同じだな～」と思う機会があるのだろうなと思いました。

関心の分離は目的の分離である

システムは何かしらの目的を達成するための手段であり、目的ごとにカプセル化していくべきとのことでした。
また、手段と目的は1:1で1つの手段に複数の目的が紐づいていると、バグが発生しやすいとお話していました。

普段の業務は共通化できるところはまとめようとしていたため、まとめるときは目的が複数ないか確認していこうと思いました。
これはテスト分析でも同じかもな。。と感じました。

モデリングの抽象化は存在論的な抽象ではなく、目的論的な抽象を行うべき

存在論的な抽象の場合は、目的にある要素をうまく抽出できないため、適切なカプセル化ができないとお話していました。

私はモデリングするときに取り敢えず、存在で分けてから考えていたので、ここは早速試してみたいと思いました。
存在で分割してモデリングした気分になっていたので、カプセル化の観点では目的を重視したいと思います。（目的はいろいろ考慮しないといけないので取り敢えず、存在から進めていた）

DDDはなぜ難しいのか / 良いコードの定義と設計能力の壁

設計力が低い時はデータベース駆動設計の方が開発を進めやすい

データベース駆動設計≒ORMを使った開発のことです。
この設計方法ではプログラミングに適した構造になっていない（DBとクラスは一致しない）ため、複雑なシステムになると保守性が下がりやすくなります。
ただ、データモデルさえすれば開発が進むため、設計力が低い場合は無理にDDDを導入するよりこの開発方法の方が良いとのことでした。

ただ、データモデルさえすれば開発が進むため、設計力が低い場合は無理にDDDを導入するよりこの開発方法の方が良いとのことでした。
私も設計力が高くないため、無理にDDDをやるべきではないんだなと学びました。

設計力を鍛えるには基礎力を固めるのみ

設計力を向上させるための近道はなく、地道にインプット/アウトプットを繰り返したり、設計スキルが高いに人に見てもらっていたとのことでした。

イベント全体の感想

ランチ無料券や有志の寄稿集（BOOTHで配布中）などがあり、ほんとに無料でいいの？という印象を受けました。

まだまだオブジェクト指向の理解ができていないなと感じました。
自分のコードを見ると適切にカプセル化できていなかったり、SOLIDの原則を守っていなかったりと、全然できてないので少しずつ改善していこうと思いました。

多くのセッションで「何を解決したいのかを把握しよう」「目的を確認しよう」というようなメッセージがあったなと感じました。
普段の業務で実装に集中している時はこのことを忘れてしまいがちなので、
変更要望や新しい要件に取り組むときには、目的という部分をまず考えていきたいです。
（と宣言して早速実装どうしようか考えてしまったときがありましたが。。）

次回も都合が付ければ参加したいと思います。

この記事が気に入ったらサポートをしてみませんか？