【読書】『現場で役立つシステム設計の原則』感想レポート

脱脂綿

こちらの本を読んだ感想レポートです。今回はABDではありません。

この本に期待していたこと

DDDおよびClean Architectureでオブジェクト指向というものに触れてきたものの、オブジェクト指向そのものへの不理解があるなと思って手にしました。

エリック・エヴァンズのドメイン駆動設計を参考にされているようで、DDDの理解を深めるのにも役立ちました。

3行概要

データとロジックを一体にして整理することが重要
業務を分かっている人間が設計・実装するべき
リファクタリングとコード規約でオブジェクト指向を実践していく

学び0:「そもそも何故オブジェクト指向が必要なのか」

最終章に書いてあったことではありますが、そもそも問いの出発点となるべき所なので先頭に書きます。

筆者自身、オブジェクト指向の良さを実感するのは「なかなか難しい」と認めています。これを実感するには、ある程度の規模のプログラムを実際にオブジェクト指向で設計して、何度も修正や拡張を繰り返す機会が必要ということです。

ただオブジェクト指向の良さには懐疑的であっても、手続き型プログラミングを続けているのは辛いという気持ちは私は既に持っています。それは1章から3章に掛けて、手続き型プログラミングとオブジェクト指向プログラミングの対比を色々と見てきたためです。

・getter , setterだらけ（それは本当にカプセル化なの？）
・よく分からないUtilクラスやCommonクラス
・やめて欲しいswitch文

そういった読み辛い上に修正もし辛いコードと戦うのはもう止めて、Tell, Don't Ask. ができる世界に行きたいというのが、自分の中でオブジェクト指向を進めるモチベーションになっています。

学び1:「データとロジックを一体にする」

恥ずかしながら、DDDの勉強などしていながら、値オブジェクトやエンティティを作りたい理由がようやくこの本を読んで腹落ちしました。

また、これまで自分の意識にあったのは手続き型プログラミングだったなと確認できました。

どういった基準でクラス分けしていくのが良いのか？　という事を漠然と不安に思っていたのですが、この言葉がひとつの基準になってくれそうです。

学び2:「なぜドメインオブジェクトが重要なのか」

これは本にそのまま書いていた事ではないのですが、7章の「画面とドメインオブジェクトの設計を連動させる」に書いてあった内容が印象的でした。

以下は「画面表示ロジックに直接書かれた業務ロジック」として例示されていたコードです。

if (amount > 100000 && orderDate.before(localData.now()))
    classAppend('important'); //強調表示するCSSクラスを追加

まあ実際こういうのよく見るよね！　と同時に、言われてみればこれ業務ロジックだったわ！　という今更な感想を持ちました。

上記は画面の例ですが、注意深く業務ロジックを保護していかなければ、アプリケーションの至る所に染み出してしまうという事がよく分かった例でした。

学び3:「データベースとオブジェクトは違うものとしてマッピングする」

データベースとオブジェクトは、どちらかがどちらかをリードするものではないという事です。「オブジェクトはオブジェクトらしく、テーブルはテーブルらしく」という言葉が使われていましたが、まさにその通りであると思います。

「楽々ERDレッスン」という本でも、DBAとプログラマが互いに早く仕様を決めてくれとデッドロックに陥る話が挙げられていました。

データベースもオブジェクトもそれぞれドメイン知識からそれぞれ「らしい」設計にした後、互いの差異はDDDにおけるリポジトリやファクトリによってマッピングしていく事で、互いに疎結合な設計にしていく事ができるようになるはずです。

学び4:オブジェクト指向の学び方

オブジェクト指向の学び方として、オブジェクト指向に則ったリファクタリングをしていくことと、ちょっと過激なコーディング規約に沿ってコードを書いていく事の2つが紹介されています。

ちょっと過激なコーディング規約に関しては、『ThoughtWorksアンソロジー』という本の第5章からの引用だそうですが、以下にも引用してみます。

・ルール1： 1 つのメソッドにつきインデントは1段階までにすること
・ルール2： else 句を使用しないこと
・ルール3： すべてのプリミティブ型と文字列型をラップすること
・ルール4： 1 行につきドットは1 つまでにすること
・ルール5： 名前を省略しないこと
・ルール6： すべてのエンティティを小さくすること
・ルール7： 1 つのクラスにつきインスタンス変数は2 つまでにすること
・ルール8： ファーストクラスコレクションを使用すること
・ルール9： getter 、setter 、プロパティを使用しないこと

特にすべてのプリミティブ型と文字列型をラップすること(値オブジェクトを使えということでしょう)、すべてのエンティティを小さくすること(1メソッド3行まで...)、は難しそうですが、これができると確かにぐっとオブジェクト指向を活かしたコードに近付けそうです。

まとめ

読んでいる端から、「自分がやりたいエンジニアリングってこういうことではないかな」と思うようになりました。

ビジネスサイドの人の運用知識を掬い上げ、自己文書化されたコードを書き、それを素早く改善していく、顧客と喋れるエンジニア。そうなるための基本的な考え方が書かれていたように思います。

いくつかの論調にやや極端さも感じますが、ある意味極端なくらい分かりやすい方が、手続き型に染まり切ったプログラマにはパラダイムシフトを起こしやすいのだと思うので、極端なまままずは受け入れてみたいと思います。

この記事が気に入ったらサポートをしてみませんか？