Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
Javaで学ぶSOLID原則
Search
Negima
May 29, 2026
Technology
540
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
振り返りこそエンジニアの本領
negima
0
420
AI時代でも性能試験はつらかった
negima
0
41
AIを導入する前にやるべきこと
negima
3
560
Other Decks in Technology
See All in Technology
サーバーレスをどこまで使う? WebRTC対戦ゲームで選んだVPSとの共存設計
kaidouji85
0
210
新機種発売前に見直そう!端末移行で再ログインが要るアプリ・要らないアプリは何が違うのか 〜シームレスに再開できる設計と実装〜
zozotech
PRO
0
220
今話題のAI「Jev」って何? 宇宙最速で学ぶ会
minorun365
PRO
30
17k
AI時代の「技術的負債」の変質ー概念の終焉と再解釈、エージェントと共に向かう先
nwiizo
1
2.9k
開発投資の期待値を上げるプロダクトロードマップづくり ~プロダクトエンジニアが越境して事業を伸ばす~
kekekenta
1
230
なぜ「決定性」が 決定的に重要なのか? Durable Execution 基盤の数理的理解 #serverlessjp / ServerlessDays Tokyo 2026
ytaka23
3
960
C#コードの結合を可視化する Roslyn解析による設計改善と リファクタリング判断
dora56
0
230
時うどん〜Socket.getifaddrsで学ぶネットワーク編 / Tokiudon: The Socket.getifaddrs Edition
coe401_
3
180
Claude in Chrome 入門 / Introduction to Claude in Chrome
cielo1985
0
870
負債のメタファと2026年 / Debt Metaphor in Agentic Engineering Age 202609 Edition
twada
PRO
10
4.4k
AI coding 整合正規方法
philipz
0
390
山手線を徒歩で一周してわかった、 位置情報アプリは「足」が最強のデバッガー
hinakko
0
170
Featured
See All Featured
Joys of Absence: A Defence of Solitary Play
codingconduct
1
520
Speed Design
sergeychernyshev
33
2.1k
A Tale of Four Properties
chriscoyier
163
24k
Believing is Seeing
oripsolob
1
220
The Pragmatic Product Professional
lauravandoore
37
7.4k
JAMstack: Web Apps at Ludicrous Speed - All Things Open 2022
reverentgeek
1
600
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.8k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
287
14k
Rebuilding a faster, lazier Slack
samanthasiow
85
9.6k
Rails Girls Zürich Keynote
gr2m
96
14k
Navigating the moral maze — ethical principles for Al-driven product design
skipperchong
2
550
Into the Great Unknown - MozCon
thekraken
41
2.7k
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︕