![](https://cdn-ak-scissors.b.st-hatena.com/image/square/9cbb2a157f22aa970eced1ad43723b99497f3793/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JUU2JTk2JUIwJUU0JUJBJUJBJUUzJTgxJThDU09MSUQlRTUlOEUlOUYlRTUlODklODclRTMlODIlOTIlRTMlODIlQjUlRTMlODMlQjMlRTMlODMlOTclRTMlODMlQUIlRTMlODIlQjMlRTMlODMlQkMlRTMlODMlODklRTMlODElQTclRTclOTAlODYlRTglQTclQTMlRTMlODElOTklRTMlODIlOEImdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzFFMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZzPWE3YmQxYTJmMDNhNjZjZTk1ODBlNWZiNjE5NzVhYzI5%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBrZV9zdWtlMDIxNSZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9MmJjNWMwYmFjN2M3YjE4OTNmNWJmYmIzMGYxNTY2ZTQ%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D4da6d02fdf1b1ae887c5f2454497a051)
エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
新人がSOLID原則をサンプルコードで理解する - Qiita
記事へのコメント0件
- 注目コメント
- 新着コメント
このエントリーにコメントしてみましょう。
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
新人がSOLID原則をサンプルコードで理解する - Qiita
はじめに 私は普段Javaをメインに使っている2年目のエンジニアです。この記事ではSOLID原則について「ぼ... はじめに 私は普段Javaをメインに使っている2年目のエンジニアです。この記事ではSOLID原則について「ぼんやりわかるけど、説明しろと言われると…」という状態の人に向けたものになっています。サンプルコード(Java)を使って具体的な例も記述しているので、参考にしていただければと思います。 S: 単一責任の原則 (Single Responsibility Principle) 【概要】 SRPとして知られる単一責任の原則は、その名前が示すように各クラスやモジュールが持つべきは「1つの責任」だけであるという原則です。具体的には、変更の理由が1つだけであるべきということを意味します。これにより、将来の変更や拡張が容易になり、バグの導入リスクが低減します。 【メリット】 変更の影響範囲が限定的 1つの責任だけを持つクラスを変更すると、その影響はそのクラス内に限定されることが多い 再利用性の向上