単一責任の原則と"Why me"

ジーズアカデミー Advent Calendar 2022の16日目の記事を担当させていただきます。
ツイッターは"はやはる"って名前でやっています。
昨日はFUKUOKA DEV12期で同期のあべべくんの記事でした！

"一旦簡単にしてみる" や "完璧にはできなくても10％の部分を模倣し再現していく"など
「確かに！」って思うことを熱く書いていて、通勤時間に読んで朝から元気をもらいました。
とっても明るくて、いつも楽しそうに課題発表していてムードメーカーなあべべくんからバトンを貰い、
16日目の記事を書きたいと思います。

自己紹介

FUKUOKA DEVコース12期生として2022年10月にG'sの門を叩いたG's大好き現役生です。
先生方、チュータ方々もそうなのですが福岡・山口の同期が大大大好きピです。

調べたら最近講義で習ったPHPと同い年でした。
二人の娘がいて、「つよつよエンジニアパパ」になりたいと思っており、
課題にひぃひぃふぅ言いながらも楽しいG's生活を過ごしています。

　　
過去にオブジェクト指向やデザインパターン等の設計について勉強したことがあり、
その経験から「設計って楽しい！」って感じています。
(使いこなせるとは言っていない(´；ω；`)ｳｩｩ)

今日はデザインパターンではないですが、
プログラミング設計の5つの原則「SOLID」の中の「単一責任の原則(SRP)」に絡めながら、
G’sに入学して最近思うことを書けたらなって思います。

(好きなデザインパターンはFacadeとChainOfResponsibilityです！！)

SOLIDとは

まず、SOLIDをWikipediaを調べると・・・

SOLID（ソリッド）は、ソフトウェア工学の用語であり、特にオブジェクト指向で用いられる五つの原則の頭字語である。ソフトウェア設計をより平易かつ柔軟にして保守しやすくすることを目的にしている。

SOLID

と書いてます。
「コードを効率良く書く考え方を5つまとめて、ハッピーセットになったんだ。」くらいの理解です。

SOLIDは

1. 単一責任の原則 (Single-responsibility principle)
2. 開放閉鎖の原則（Open/closed principle）
3. リスコフの置換原則（Liskov substitution principle）
4. インターフェース分離の原則 (Interface segregation principle)
5. 依存性逆転の原則（Dependency inversion principle）

の5つからなり、それらの頭文字をとって「SOLID」です。
この記事でお話する" 単一責任の原則"は上記の１番になります。

単一責任の原則(SRP)　とは

単一責任の原則をWikipediaを調べると・・・

プログラミングに関する原則であり、モジュール、クラスまたは関数は、単一の機能について責任を持ち、その機能をカプセル化するべきであるという原則である。モジュール、クラスまたは関数が提供するサービスは、その責任と一致している必要がある。

単一責任の原則
と書いてあります。

ふむふむ。
1つのクラスはたった一個の関心事に責任を持ちなさい。
って書いています。

つまりスーパとかでよく見るこれ。
↓

あんまり自信がないけど最近話題のTwitterを題材に
アンチパターンを書くとこんな感じ？

Tweet.java

public class Tweet{
    private String content; //本文
    private Ueser user; //投稿者
    private Data tweetTime; //投稿時間
    private int likeCount = 0; //いいねの数
    private int retweetCount = 0; //リツイートの数

    //コンストラクタ
    public Tweet(String content,Ueser user) { /*処理*/ }

    //いいねの数を管理 →Tweetクラスの責任の範囲内★GOOD★
    public int setlikeCount() { /*処理*/ } 
    public int getlikeCount() { /*処理*/ } 

    //リツイートの数を管理 →Tweetクラスの責任の範囲内★GOOD★
    public int setRetweetCount() { /*処理*/ } 
    public int getRetweetCount() { /*処理*/ } 
 
    //ユーザのフォロー/フォロワー一覧を返す → Tweetクラスの責任の範囲外！！ ×BAD
    public String[] getFollowing(String user) { /*処理*/ }
    public String[] getFollowers(String user) { /*処理*/ }
}

Twitterというサービスをもし自分が作るなら、
まずは"Tweetクラス"と"Ueserクラス"と"TimeLineクラス"に分けて作ります。

そうすると「"Tweetクラス"は"Tweet"のことしか関心事や責任を持っちゃダメ！」
っていうのが単一責任の原則です。
じゃないとどんどんクラスが大きくなって、ちょっとした仕様変更でも
コード修正の影響がすごく大きくなってしまいます！

上記コードの最後2つの
・getFollowingメソッド（フォローしている人を返すメソッド）
・getFollowersメソッド（フォロワーを返すメソッド）
は明らかにUesrが管理するべきことを処理していて、Tweetクラスが管理することじゃなさそうです。
なので最後の2つのメソッドは単一責任の原則に違反しています。

「Tweetクラス」はTweetのことだけ
　(本文や投稿者、いいねの数、リツイートされた数、投稿時間など)に責任をもって、
「Userクラス」はUserのことだけ
　(アカウント名、プロフィール、フォロー、フォロワー、など)に責任をもって、、
「Timelineクラス」はタイムラインのことだけに責任を持ちましょう。
ってのが「単一責任の原則」です。

今回は自己理解のために、超カンタンに
自分なりにTwitterサービスのクラス設計を考えてTweetクラスだけ説明しました。

設計に詳しい方、ご指摘ありましたらコメントお願いします。
設計の話とか好きです！そういう話ができたら嬉しいです！

Why me

話はすっごい変わって最近のG'sのお話をします。
入学してもう2か月経ち、前期講義も終了し、中期に突入しました。
そしてプログラミングと並行して、企画も本格的に始まりました。

僕は正直今Why me迷子状態です。
「Why meってなんだ。自分ってなんだ。自分はなにがしたいんだ。。。
Why meってなんだ。Why meってなんだ。」
そんな自問自答を日々繰り返しています。

そんなある日、ふと単一責任の原則を思い出しました。

『そうか。プログラムもたった一個の関心事しか責任を持ったらいけないように、
　きっと僕たちも一個の関心事しか責任を持ったらいけないだ。
　そりゃ、
　"仕事してお金を稼いで家に入れる"とか、
　"お風呂最後に入ったらお風呂掃除する"とか、
　"娘が風呂から上がったらミルクを160CC作って飲ませる"とか、
　小さな責任はいっぱいあるけど、
　でも大きな軸となる自分の人生の責任はたった１個のはずで
　それこそが"Why me"なんじゃないか！』と感じました。

自分独自の解釈なんですが、
昔知ったプログラミングの設計と、
今直面している"Why me"が繋がった感じがしてすごく嬉しかったです。
全然何も進展していないんですけど、自分が今まで頑張って学んできたことが
繋がった気がして、少しだけ先が明るくなった気がしました。

家族に一言

こんなことを言ってまだWhy me迷子中で
自分の人生の単一責任は分かってないけど
家族に対しては結構勝手に単一責任を考えちゃっていて、

二人の娘たちには、
「自分の人生を思いっきり楽しむこと！
　(あと、初デートはディナーじゃなくてランチで済ますこと) 」
妻には、
「これからも楽しく仲良く笑顔で暮らすこと！」
と勝手に押し付けてる単一責任を本人たちに言うことはできず、ここで吐露します（笑）。

最後に

拙文をここまで読んでくださった方ありがとうございました。
　　
あなたの人生の単一責任はなんですか？
たった一つの関心事しか責任を持ったらいけないとすれば、何に責任を持ちますか？

　　
　　
P.S.大好きな同期のみんなへ
僕と一緒にいっぱい悩んでください。
いっぱい"Why me"について話し合いましょう。
春に「やりきった～」と言って笑って卒業しましょう！