小さく作るのは良いことだと思うが、それは再利用駆動ではない

再利用性を高めるために、Simpleなものを組み合わせて作る、のではない

小さく作ったことの恩恵の一つとして、再利用性がある

再利用駆動で小さく分けると、

「2つの関数で同じ処理をしているから抜き出そう」という安易発想になる

これがたまたま上手くいくこともある

関数の責務などを度外視して、「共通部分」を抜き出しているだけ

直交性もクソもないので、その2つの関数以外では再利用できない、という状況に陥る

共通部分だけに着目した安易な例としては

今、AとBというclassを別々で作っていて

A と B の共通部分あるやん！(赤色)と思って、

の3つにわけてしまう

しかし、将来的に C のようなclassを作りたいとなった時に、

赤 の部分の一部は C からはみ出ているので、 C は 赤 を再利用できない

理想的には、個々の責務を考えて、最初から

の3つで分けるべきだった

「共通しているから切り出す」ではない

というか、「小さく作る」をちゃんと実践していると、

というふうな分けられ方が、自然に為されると思う

あくまでもイメージだが

背反であるべきと主張したいわけではないのでこの図は語弊がある

もちろん、実際のプログラミングの中で、

A 、 赤 、 B の分け方が適切だ、となっている状態で

C を追加する時に 赤 を分割する、ということもあるとは思う

ここで言いたいのは

「再利用目的のために小さく作る」というのは順序がおかしい

似ているとかではなく、責務に従って小さく作るべき

再利用目的で小さく作るわけではない#62d4c02c19827000007c573bのケースは、実装が進んだことで責務が変わった、とも言える

責務に従っているなら、重複があろうと関係ない

「似てる」「同じ」と言った時に、何に対して「似てる」と言ってるかという話か

コードの字面が同じなのか、責務が同じなのか、

これらの概念は全く別物

他の例