Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んだ

クリーンアーキテクチャを読みました。

設計界隈でよく耳にするこのクリーンアーキテクチャですが、一度は読んでおきたいと思い読みました。

他の姉妹本？のようなものも読んでいました。

難しい。文章が抽象的で難しい。

javaのコードもたくさん載っていますが、量が多く、全部読むのは時間がかかります。

Javaの文法でよくわからないのがあります。

次のものは、この本を含め、設計の本を読んでいく中でJavaの文法でわからないものです。

public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello World!");
    }
}

String[] argsこの辺が？？となっていたのですが、こちらのサイトの説明でわかりました。引数を文字型で配列で指定しているんですね。

わかりやすく参考になりました。 www.task-notes.com

ArrayList<String>こういうのもなぞ。

次のサイトを参考に調べました。単に、ArrayListクラスの型を表していてさらに文字列型であるということなんですね。

Javaは少し、本読んだだけで、雰囲気で読んでいるので知識の穴があります。

PHPの型よりも詳細に指定できるんですね。

SRP：単一責任の原則

OCP：オープン・クローズドの原則

LSP：リスコフの置換原則

ISP：インターフェイス分離の原則

DIP：依存関係逆転の原則

全部、ちゃんと理解できませんでした。

「そのクラスやメソッドにひとつのことをさせる」のではなく

「そのクラスやメソッドを変更する理由はたったひとつでなければならない」

ということだと理解しました。よくひとつのことをさせると勘違いされているとこの本には書いてました。

変更する理由はひとつでなければならないは直感的でなくてソース書いてからもし、変更するなら理由はひとつだろうか？と考える必要があるのでしょうか。

ただ、これをちゃんとやるとごった煮クラスやごった煮メソッドを作らなくてよくなり、可読性、メンテナンス性があがると思います。

ごった煮コード読むのがつらく、時間がかかります。

なので、この原則はとても有効だと思います。

ある勉強会でもこの原則が一番大事とも聞いたおぼえがあります。

既存のソースを変更せず、ソースを追加して、拡張させるというようなことだ。

これは、自分の好みにあっています。出来上がって動いてテストしても大丈夫なソースはできるだけ修正したくありません。

そのソースをそのまま利用して、他の機能を追加していければ理想です。

脱線します。

本を読みながら、これは、たくさんある理論・手段のうちのひとつだなと考えるようになりました。

バグがでない読みやすいコードを早く書くというのが、プログラマの目的なような気がします。

もっと上を見ると、儲かるコードを早く書くというのがあるのが本質かもしれませんが、プログラマは儲かるという不確定なことに関して、範囲外な気もします。

どっちも正解なような気がしますが、僕は、ある種職人的なアーティスト的にプログラマを捉えているので、前者のほうが好みであります。