リファラジかじり聞きログ

2024/4/15

かじり聞きしているのをメモっているだけのログです(間違ってメモしてたらすみません)

単一責任原則とactor

主体になっているものが actor として扱う

まずは actor を数えることが大事

複数責任(複数の actor)を持ってるコードをどうリファクタするか

employee とか通販サイトの商品とか例にできる

買う人、商品、宅配業者、Amazon

金額、在庫数とかのプロパティ

下書き状態があるデータ

draft, public など

見る側は1つのエントリである

writer と reader

顧客管理

管理したい目線と情報登録する(客)側の目線

めっちゃフィールドがあるけど大量のnullが入ってる

ユーザーが入れたいのは email とかぐらいなんだけど

ユーザが入力しなくてもお店側がメタデータとして既に入れてることがある

基本状態がnullばかりでやばい

サインアップ情報を user型にするのやばすぎる

バリデーション前の編集情報だから

会員登録しようとする人actor から登録したユーザーのactor がそれぞれある

SRP が 1actor

プロジェクトのユースケースにおいて actor の定義を考えるやり方でいい

コンウェイの法則から導かれている？(あんまり理解できてない)

SRPに反してるかはコードだけ見てもわからない

変更を加えるとき、これってなんのユースケースにおける変更ですか？と答えられない時が危険信号

コードに変更を入れる前から考えるべき点である

いったんコピペして複数同じ個所を作る

DRYよりもSPRを優先する

SPRの観点でまずいなとなるコード

モックを作るうえですべてのプロパティを使わないモックを作っていないか

商品伝票を扱うメソッドだと半分ぐらい使ってないプロパティが出がち

そういう時は商品伝票用の商品という概念を作る

複数の同じ役割の定義が出てきてDRY的にどうか？という話もある

テスト書くところで必要なモックを作る

あらゆるところでSRPが迫っている(?)

それだけを見ると重複するコードが生まれがちである

SRP と DRY がぶつかる瞬間

actor を意識してコード書こうぜという話(汎用的に考えられそうなやつ)

第14回

https://open.spotify.com/episode/2G3JG4fN6vg2miHxqLlp21?si=_aOcuuO4SVGNeAX7u4WTVA

14回

SOLID原則

今回はS(単一責任原則)だけ

プログラミング学ぶ人はみんな通る道とのこと

2000年ぐらいから提唱されている

solid(堅牢)にかぶせた上手い言い方だよね

英語だとSRP

単一責任原則って結局なんなの？

曲解するひとは多い

駆け出し時代は一つのメソッドの中で一つの処理以外呼んではいけないと曲解してた

それだとソフトウェア成立しないじゃん

複数の処理を呼ぶことはもちろんある

責任と責務ってなに？

何を単一にしたらいいのか？

短い関数＝単一原則なのか？

2000年に生まれた哲学がなぜ続いてるのか？

複数責務でいいんじゃないという話にもなったりするのか？

アンクルボブが提唱したSOLID原則の元ネタ

オブジェクト指向が前提としてある

クラスベースじゃなかったらSOLID無視していいのか？

現代で単一責任とどう向き合っていくべきか？

クラスベースじゃない言語

関数言語であることとオブジェクト指向と統一はしていない

結局広い目線でみればオブジェクト指向の原則にのっとってコード書いてるので共存する

ベースの原則の部分は変わってない

オブジェクト指向に則るならば単一責任であるべきという考え方はぶれてない

クラスとかは関係ない

もっと深い部分でどういう風にあるべきかの話

単一責任の「責任」はなんなのか？

クリーンアーキテクチャが今最も普及しているアンクルボブ本らしい

7章のSRP

モジュール変更する理由はたった一つであるべきである

説明になってないなと思ってた

変更する理由ってなに？

色んな理由で変更してない？

↑には話の続きがある

モジュールはたった1人のユーザーステークホルダにおいて責任を負うべきである

それは誰に対する責任であるのか

ユーザステークホルダに対する責任

たった1つのactor

UML(統一モデリング言語)のユースケースの中に actor という概念が出てくる(この actor のことらしい)

伸びてる線において同じ棒人間に線を向けてはならない

actor が違うならユースケースが違うので、そのコードは共通化してはならない

単一の actor に対して要件を満たすコードであるべき

要求の出どころ

この actor のためのコードですと示されているとコンフリクトが起きづらい

↑の概念を理解してれば単一責任と複数責任を見分けられそう

複数責任があるコードを見かけたらどうする？ということを次回考えていこう

15回のメモはまた明日