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
400
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
18
AIを導入する前にやるべきこと
negima
3
500
Other Decks in Technology
See All in Technology
Genie Codeハンズオン基礎編
taka_aki
1
130
攻撃と防御で学ぶAI時代のプロダクトセキュリティ演習
recruitengineers
PRO
9
3k
トヨタ⽣産⽅式(TPS)⼊⾨
recruitengineers
PRO
3
960
Service Connect 上のサービスに ECS Service の外側から到達できなかった話
ota1022
1
260
同じWAFが、攻撃の“形”は弾く── 正当な“形”の不正は通す
kuroneko13
0
220
MIRU 2026 チュートリアル
keisuke198619
0
970
少人数チームで実現する、大規模AWSサーバーレス基盤における"揺らがない"信頼性運用
maimyyym
1
100
LLM・AIエージェントシステムベストプラクティス
shibuiwilliam
6
1.4k
え?フロントエンドエンジニアの ワイがインフラも!?
puku0x
1
690
DatadogのBits Chatが開発組織にもたらしたもの / What Bits Chat Has Brought Us
sms_tech
1
280
Invisible to AI? Making TYPO3 Sites Quotable by AI Search Systems
wolfgangwagner
0
220
Breaking the Seal: Static Deobfuscation of Compiled V8 JavaScript Bytecode Malware
hshrzd
0
840
Featured
See All Featured
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.5k
The State of eCommerce SEO: How to Win in Today's Products SERPs - #SEOweek
aleyda
2
11k
Design of three-dimensional binary manipulators for pick-and-place task avoiding obstacles (IECON2024)
konakalab
0
540
Joys of Absence: A Defence of Solitary Play
codingconduct
1
440
Context Engineering - Making Every Token Count
addyosmani
9
1.1k
Design in an AI World
tapps
1
280
SEO in 2025: How to Prepare for the Future of Search
ipullrank
3
3.7k
Fireside Chat
paigeccino
42
4k
The Hidden Cost of Media on the Web [PixelPalooza 2025]
tammyeverts
2
470
What’s in a name? Adding method to the madness
productmarketing
PRO
24
4.1k
Making Projects Easy
brettharned
120
6.7k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
49
10k
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︕