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
350
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
3
470
Other Decks in Technology
See All in Technology
Data + AI Summit 2026 イベントレポート: 「AIがビジネスで意思決定するデータ基盤」へ
nek0128
0
120
[2026-07-15] AI Ready なはずだったアーキテクチャと、見えてきた課題・次に目指す状態
wxyzzz
6
3.3k
ポストモーテム! DDoSからサイトは守れた。 でもビジネスは守れなかった。
bengo4com
1
2.9k
Databricks 生成AIガバナンス実践ワークショップ / LLMOps-workshop
databricksjapan
0
100
環境凍結という Toil を倒す -セルフサービス型 Ephemeral テスト環境の 設計と実践
shirouz
1
2.3k
Keeping applications secure by evolving OAuth 2.0 and OpenID Connect
ahus1
PRO
1
160
実装だけじゃない! CCA-F取得エンジニアが教えるClaude Code開発プロセス活用術
diggymo
2
700
SREとQA 二人三脚で進めるSLO運用/sre-qa-slo
sugitak
0
540
脱金融のフューチャー・デザイン / Future Design Beyond Finance
ks91
PRO
0
150
ruby.wasmとPicoRuby.wasmに対応した仮想DOMライブラリを作ってる話 #kaigieffect_kaigi
sue445
PRO
0
150
LLM/Agent評価:トップ営業の発言を「正解」にする 〜暗黙的正解による評価を営業資産に変える〜
takkuhiro
1
220
凡エンジニアがこの先生きのこるためには。〜TypeScript完全に理解したい〜
alchemy1115
2
180
Featured
See All Featured
Making the Leap to Tech Lead
cromwellryan
135
10k
GraphQLの誤解/rethinking-graphql
sonatard
75
12k
Conquering PDFs: document understanding beyond plain text
inesmontani
PRO
4
2.9k
Between Models and Reality
mayunak
4
370
Efficient Content Optimization with Google Search Console & Apps Script
katarinadahlin
PRO
1
690
A Guide to Academic Writing Using Generative AI - A Workshop
ks91
PRO
1
350
How to build a perfect <img>
jonoalderson
1
5.8k
Producing Creativity
orderedlist
PRO
348
40k
The Spectacular Lies of Maps
axbom
PRO
1
850
Believing is Seeing
oripsolob
1
170
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.5k
Navigating Weather and Climate Data
rabernat
0
320
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︕