Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Javaで学ぶSOLID原則
Search
Negima
May 29, 2026
Technology
460
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Javaで学ぶSOLID原則
Negima
May 29, 2026
More Decks by Negima
See All by Negima
AI時代でも性能試験はつらかった
negima
0
26
AIを導入する前にやるべきこと
negima
3
520
Other Decks in Technology
See All in Technology
Introduction to Sansan, inc / Sansan Global Development Center, Inc.
sansan33
PRO
0
3.2k
医療の現場を変革に挑戦した半年間の軌跡 - PythonとAIで現場を変える / From Code to Care
soudai
PRO
1
640
「ミスを許さない手順書」を作ってみた 〜 個人的にはこれ以上できることはあまりなさそう/20260827-ssmjp-operation-procedure-update
opelab
13
9k
アクセスキー流出時の対応で再認識した攻撃側と防御側の非対称性について
kazzpapa3
1
440
APIセキュリティを組織で実現するには~注力する点と設計・実装に入れたい対策~
riiimparm
2
720
『自分で判断できるか』を基準に、プロダクトのハンズオン研修でAI利用の線を引いてみた / Where We Drew the Line on AI in Hands-on Training
honyanya
1
440
最新技術に積極チャレンジ!EKS共通基盤のこれまでとこれから
daitak
0
250
Kiro Crew で始める マルチエージェント開発
miu_crescent
PRO
0
200
サイボウズ 開発本部採用ピッチ / Cybozu Engineer Recruit
cybozuinsideout
PRO
12
86k
Contract One Engineering Unit 紹介資料
sansan33
PRO
0
20k
DMMブックスのNext.js化を加速させるAI活用 / Migrating DMM Books to Next.js with AI
kentarom
0
170
MCPを待つな、パスキーを拡げよう(OAuth/OIDC Numa (Immersion) Workshop 2026)
oidfj
PRO
0
350
Featured
See All Featured
The Cult of Friendly URLs
andyhume
79
7k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
46
3k
Designing for Timeless Needs
cassininazir
1
460
Facilitating Awesome Meetings
lara
57
7.1k
Raft: Consensus for Rubyists
vanstee
141
7.7k
GitHub's CSS Performance
jonrohan
1033
470k
My Coaching Mixtape
mlcsv
0
300
Code Review Best Practice
trishagee
74
20k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
16k
Large-scale JavaScript Application Architecture
addyosmani
515
110k
How to Talk to Developers About Accessibility
jct
2
530
Music & Morning Musume
bryan
47
7.3k
Transcript
May 30, 2026 #JJUG CCC 2026 Spring Negima Javaで学ぶSOLID原則 X:@negimaboy_1293
$ whoami Negima(根本 銀河) 2023卒 • NTTデータフィナンシャルテクノロジー 決済イノベーション事業部 • クレジットカード会社向けサービスのSRE・性能改善・AI導⼊⽀援など
• ソフトウェアアーキテクチャの話が好き
セッションをしようと思った背景 • 業務であるツールをJavaで開発しており、AIでコーディングさせていた • そのツールは特定チームが作成する資材のインプットとなるドキュメントが 更新されると通知(mattermost、もしくはteams)を⾶ばすというもの • 上記の通知機能を眺めていたら⼤きな問題点を2つ⾒つけた
セッションをしようと思った背景 通知機能 個々の通知ロジックを呼び出す Usecaseクラス プラットフォームごとの 具体的な通知ロジックを定義しているクラス
セッションをしようと思った背景 通知機能 ※説明の都合上、実コードより簡略化しています
セッションをしようと思った背景 パッと問題点・修正案を出せたわけではなかった (最近諸々をAIに任せすぎて設計の勘が鈍っていた) 「爆増する低品質なコードをどう整理して、どう修正すればいいんだっけ︖」 整理の⽅法について体系的にまとめられている SOLID原則を復習してみた
SOLID原則について SOLID原則の起源 • Robert C. Martin(またの名をボブおじさん)などが提唱していた、 OOPを前提とした数々のソフトウェア設計原則をまとめたもの • 「SOLID」とはその5つの設計原則の頭⽂字であり、 2004年頃Michael
Feathersが命名したとされている Robert C. Martin⽒
SOLID原則について S → 単⼀責任の原則(Single Responsibility Principle) O → オープン・クローズドの原則(Open Closed
Principle) L → リスコフの置換原則(Liskov Substitution Principle) I → インターフェイス分離の原則(Interface Segregation Principle) D → 依存性逆転の原則(Dependency Inversion Principle) 「SOLID」を構成する5つの設計原則
SOLID原則について S → 単⼀責任の原則(Single Responsibility Principle) O → オープン・クローズドの原則(Open Closed
Principle) L → リスコフの置換原則(Liskov Substitution Principle) I → インターフェイス分離の原則(Interface Segregation Principle) D → 依存性逆転の原則(Dependency Inversion Principle) 「SOLID」を構成する5つの設計原則
SOLID原則について オープン・クローズドの原則(OCP) - Ϟδϡʔϧɺ֦ுʹରͯ͠։͍͍ͯͯɺมߋʹରͯ͠ด͍ͯ͡ͳ͚ΕͳΒͳ͍ɻ 機能追加は既存コードの修正ではなく、 新規コード追加で対応できるようにすべき
SOLID原則について オープン・クローズドの原則(OCP) Badな例(家電を追加したい場合) 家の配線 家電 家電と直接配線を 繋いでいる場合は、 家電を追加するたびに配線を 組み替えないといけない +
SOLID原則について オープン・クローズドの原則(OCP) Goodな例(家電を追加したい場合) 家の配線 コンセントの規格に さえ合わせれば 家電が追加されても ⼯事しなくて良くなる コンセント (interface)
コンセントという共通規格を挟むことで 配線を変更せずに追加できる
SOLID原則について 依存性逆転の原則(DIP) ্ҐϨϕϧͷϞδϡʔϧԼҐϨϕϧͷϞδϡʔϧʹґଘͯ͠ͳΒͣɺ ྆ํͱநʹґଘ͖͢Ͱ͋Δɻ நৄࡉʹґଘͯ͠ͳΒͳ͍ɻৄࡉ͕நʹґଘ͖͢Ͱ͋Δɻ ※上位モジュールとは呼び出す側、下位モジュールとは呼び出される側 直接モジュールを呼び出すのではなく 抽象レイヤーを介して呼び出す
SOLID原則について 依存性逆転の原則(DIP) Badな例(家電を買い替える場合) 家の配線 家電 家電と直接配線を 繋いでいる場合は、 買い替え前と同じ規格の 家電でないと⼯事が必要
SOLID原則について 依存性逆転の原則(DIP) Goodな例(家電を買い替える場合) 家の配線 家電 配線はコンセントしか ⾒えない コンセント (interface) 家電がコンセントに
依存する →依存の向きが 逆転する 配線が家電に依存せず、双⽅がコンセント(抽象)に依存する
先ほどの通知機能は この2つの原則に 違反していました
SOLID原則に基づく修正 通知機能 ※説明の都合上、実コードより簡略化しています プラットフォームに 仕様変更が発⽣した際 本クラスも修正しないといけない (DIP違反) 新規プラットフォーム追加の際に case⽂を追加しないといけない (OCP違反)
SOLID原則に基づく修正 家の配線 →NotificationServiceクラスの notifyメソッド 家電 →プラットフォームごとの クラス コンセント(interface) →ない 家電の例に通知機能を当てはめてみる
プラットフォームごとのクラスを抽象化する⽅針で修正
SOLID原則に基づく修正 通知機能(修正後) 各プラットフォームの抽象 個々のクラスではなく 抽象化されたリストに依存 ※抽象化にあたりchannelクラスとclientクラスで処理を切り出した
SOLID原則に基づく修正 通知機能(修正後) 先ほどのコンセントに 相当するinterface
SOLID原則に基づく修正 通知機能(修正後) NotificationChannelの 実装クラス作成だけで プラットフォームの追加が できる
SOLID原則に基づく修正 通知機能(修正後) 抽象に依存することで プラットフォームの 追加・仕様変更を吸収できる リストから動的に通知対象を特定することで プラットフォーム追加によって 本メソッドを修正する必要がない
SOLIDを再学習してみて • コードをどう整理・抽象化するかをSOLIDを⽤いて決定することができた • 低品質なコードが⼤量に⽣成されるAI時代において、レビュワーである⼈間が コード整理のToBeを持っていることは極めて重要であると感じた • AI⾃体にもSOLID原則をハーネスとして取り⼊れ、整理されたコードを⽣成するよう 予防することも重要 SOLIDはAI時代においても重要な観点であると⾔える
まとめ • SOLID原則とはOOPを前提とした5つのソフトウェア設計原則 • SOLID原則を理解することでコードをどのように整理・抽象化するかといった 指針を⽴てることができる • 低品質なコードが⽣成されるAI時代において、コードを整理するToBeを与えてくれる SOLIDは引き続き重要な概念である
参考⽂献 • SOLID原則 実践ソフトウェア設計 • 達⼈プログラマー(第2版): 熟達に向けたあなたの旅 • SOLID原則完全に理解した︕になるための本 •
イラストで理解するSOLID原則 OCP、DIP以外の原則も 詳しく解説されているので ぜひ
Enjoy your hacking︕