いいコードを書くための勉強会（単一責務の原則について）

ある大学サークルの勉強会資料

単一責務の原則についてまとめた

Transcript

1. いいコードを書くための勉強会 単一責任の原則
2. Q コードを書く時,または実装の方針を考えている時に意識している ことはありますか？？
3. A 僕はSOLIDを意識しています！
4. SOLID???
5. 今回のゴール ・SOLID原則の一つである単一責任の原則について知る ・いいコードを書くモチベーションのきっかけをつくる ・リファクタリングや設計に入門するイメージを持つ ・アプリの設計をしたくなる
6. 今回のゴールじゃない ・MVCやMVVMなどの設計パターンについて学ぶ MVC
7. SOLID原則とは ソフトウェア構築時に従うべきガイドラインで、ソフトウェアの拡張性や保守性を高めるた めの5つの原則を指す。 ・S (Single Responsibility)　単一責任の原則　👈 ・O (Open-Closed)　オープン・クローズドの原則 ・L (Liskov Substitution)　リスコフの置換原則 ・I (Interface Segregation)　インターフェイス分離の原則 ・D (Dependency Inversion)　依存性逆転の原則 今回はS(単一責任の原則)について詳しく触れていきます
8. 単一責任の原則
9. 単一責任の原則 ・各クラスはそれぞれ一つだけの責務を持つべきである ・変更するための理由が、一つのクラスに対して、一つ以上あってはならない
10. 単一責任の原則（解説） アクターとモジュールを用いて解説します ・アクター 　システムにアクセスする利用者や外部システムが、システム（主体）に対して果たす役割を示したもの。 ・モジュール 　クラス、構造体、関数など、ロジックが詰まっているもの
11. 単一責任の原則（解説） Employeeは以下の3つのメソッドを持ってい る。 ・calcuratePay() 　給料の情報をCFOへ報告 ・reporyHour() 　社員の労働時間をCOOへ報告 ・save() 　データベース内の情報をCTOへ報告 https://zenn.dev/chida/articles/2e42d7eddcf185 アクター モジュール
12. 単一責任の原則（解説） Employeeクラスは3つのアクターに対して責務 を負っているため、単一責任を違反している。
13. 単一責任の原則（解説） PayCalculator calculatePay() HourReporer reporyHours() EmployeeSaver saveEmployee() 解決例 それぞれのメソッドを別クラスに移動し、アクターに対 する責務を一つにする。 今回の例だとこれで単一責任の原則を満たす。 CFO COO CTO
14. 単一責任の原則が満たされてなかったら ・ある責務の変更が別の責務に影響を及ぼす ・テストをする際に、変更を加えていない異なる責務にも対応する必要がある
15. 単一責任の原則の注意点 各クラスはそれぞれ一つだけの責務を持つべきである 👆この言葉をそのまま覚えているとちょっと危険？？ 飽くまで、一つのアクターに対して、一つのモジュールを持たせるべきだという原則であ る。
16. 単一責任の原則の注意点 誤った例 PayCalculator calculatePay() 左の図は、ただひたすらに、モジュールの責務を分 割している。 それぞれのモジュールの責務が小さければ小さい ほど良いというものではない。 多すぎるモジュールは逆に拡張性や保守性落とす 場合がある ”一つのアクターに対して、一つのモジュールを持たせるべきだ”の意味を きちんと理解して覚えましょう まだ分割できそう まだ分割できそう
17. 単一責任の原則（まとめ） ・単一責務の原則は”変更するための理由が、一つのクラスに対して、一つ以上あって はならない”という原則 →”一つのアクターに対して、一つのモジュールを持たせるべき” ・理由は、責務が多いと、拡張性や保守性を低下させてしまうため ・テキトーに責務を分割するのではなく、しっかりと原則の意味を理解しよう！
18. 単一責任の原則（おまけ） ビジネスへの関心が薄く理解が浅いと単一責任設計が困難 アクターの求める責務を理解しないとそもそも単一責務にできない。 そのためには、アクターが関わるドメインの知識は最低限必要である ってことだと思う 詳しくは👇で https://qiita.com/MinoDriven/items/76307b1b066467cbfd6a
19. さいごに ・今回学んだことは設計を始める前の事前知識 ・設計をするためには、他にも学ぶべきことがたくさんあります。 ・SOLID原則の他にもさまざまな、原則や思考？があるので調べてみてください (DRY原則、KISS原則など)　 情報工の講義では、ソフトウェア工学とかが近いかも？
20. 良いコードが何かを知らなければ、、、 https://note.com/cyberz_cto/n/n26f535d6c575
21. クソコードを書くことに批判的になりすぎない ”クソコードを書きまくって後で悩む ”を繰り返して学んでいきましょう
22. 今回の勉強会が少しでもいいコードを書くことや設計に関する モチベーションにつながるといいなぁと思います。 今回学んだことはすぐには成果が出ないかもしれないですが、と ても大切でどの領域にも通づることです。
23. 参考 Clean Architecture 達人に学ぶソフトウェアの構造と設計 https://www.kadokawa.co.jp/product/301806000678/ 設計を知るための第一歩を踏み出そう https://speakerdeck.com/macnekoayu/she-ji-wozhi-rutamefalsedi-bu-wota-michu-sou