投稿元:
レビューを見る
# 1周目 読み終えた
モダンなスタイルを手に入れることができる。常識レベルまでに定着しているスタイルではない。従うかどうかは別にしても、一度は目にしておいても損はない内容。
## 11章を読んだ ➤ エピローグ
より深く理解するため、より先に進むためのガイド。コンパクトで良い本だった。
## 10章を読んだ ➤ オブジェクトフィールドガイド
これまでの総まとめのような章。この本はWebアプリケーションが念頭に置かれていたことが、今頃になってわかった。どの分野であっても通用するような感覚でいた。そんな万能なものは存在するはずもないだろう。本書は有用なガイドであったと思うし、一度はきっちりこのスタイルに従った設計を行ってみたいと思わされるものではあった。でもたぶん、Webアプリケーション以外では、きっちりはまることはないのではないか睨んでいる。
だからといって価値が下がるわけではない。何も考えずに完全な自己流で開発していたなら、おそらく良い設計はできていない。従うかどうかは別にしても、何かしらの指針となるものが必要だ。それを与えてくれた。まだ読んだだけで何も実践していないので、これからどうなるかに期待したい。
## 9章を読んだ ➤ サービスの振る舞いの変更
一言でいうと、「継承を使うな、コンポジションを使え」になる。もちろん、サービスオブエクとは作成された後に変更されるのは望ましくないので、振る舞いを提供するコンポジションはコンストラクタで与えられることになる。より複雑な振る舞いは、コンポジションを合成することで可能になる。デコレーションを使って既存の振る舞いを装飾することができる。振る舞いを追加するには、イベントリスナが使える。サービスの振る舞いを変更するために継承を使う機会はまったくない。
## 8章を読んだ ➤ 責務の分割
リードモデルとライトモデル。エンティティのプロパティから情報を取り出すためには、クエリメソッドを追加してやるのがストレートな方法となる。この状態は、リードモデルがエンティティに結合されている状態と言える。エンティティは、プロパティを変更することもあるだろうから、データの操作を行うメソッドも持つことがある。この状態は、ライトモデルがエンティティに結合されている状態であり、前と合わせると、リードモデルとライトモデルが混在している状態になっていると言える。
ここで、情報を引き出すためだけのオブジェクトにリードモデルを分離することができれば、エンティティの責務を軽減できる。ライトモデルの分離については何も例が示されていないのでよくわからないままだ。
## 7章を読んだ ➤ タスクの実行
コマンドメソッドでやることを限定するために、多くのことをさせないために、二次的なタスクを切り離す。そのための手段がイベントになるのは、なんとも奇妙に思える。その他もピンとこなかった。
## 6章を読んだ ➤ 情報の取得
コマンドとクエリの分離が大事。SOLID原則とはなにか。フェイクとダミーの違い。
これまでもそうだったのだけど、この章で特に、テ���トがただプログラムが正しく動作することを検証するためだけではなく、コードの品質の向上にも大きく貢献することが分かる。テスト可能にするためには、オブジェクトの内部状態にアクセスできた方が簡単な場合があったとしても、それだけの理由で設計を歪めて内部状態を晒すようにしてはいけない。先に正しい戦略を取ることが重要になる。歪んでいない形でテスト可能にすることにより、コードもよりよい形を取るようになる。オブジェクト設計においては、テストは重要な地位にあることが伝わってくる。
## 5章を読んだ ➤ オブジェクトの使用
メソッドのテンプレート。短い章だった。事前条件と事後条件という単語が出てくる。特に事前条件を重視している。メッソッドの最初で、無効な入力に対するチェックを行う。無効なものが検出されたら、すぐに例外を投げる。例外の種類と、構築する方法も解説されている。今まで、例外についてちゃんと考えたことがない。そもそもあまり使ってこなかった。ここでのガイドは今後のスタイルに影響を及ぼすものになるだろう。あと何週化する予定だが、しっかり記憶にとどめておきたい。
## 4章を読んだ ➤ オブジェクトの操作
エンティティとバリューオブジェクトについて、ミュータブルにするかイミュータブルにするか。基本的なガイドは、まずイミュータブルであることを優先するが、エンティティはミュータブルでも良い。バリューオブジェクトはミュータブルである必要性はないので、イミュータブルであるべきである。エンティティはビジネスドメインで存在するもので、時間の経過とともに変化していくのは自然なことだと考える。じゃあバリューオブジェクトの値を変更したいときはどうするかというと、自身のコピーを作成して、それに変更を加えて返す、モディファイアメソッドを提供する。メソッドの名前にも注意を払わないといけない。命令的な生ではなく、宣言的な名前にする。この手法は、画一的でシンプルな解決策を提供するものだが、現実そううまくいくのだろうか、疑念が拭い去れていない。まだ浸透しているスタイルとは言い切れないので、複数のプログラマが集まったとき、といういつすることにもちょっとしたハードルがあるだろう。それでも、理想的なスタイルであるのは同意できる。
## 3章を読んだ ➤ ほかのオブジェクトの作成
2章のサービスオブジェクト以外のオブジェクトを指す。それらは、バリューオブジェクトとエンティティに分けられる。とあるが、どこまでがバリューオブジェクトで、どこからがエンティティなのか境界がはっきりと示されていない。直感的に、単純な値を表現するものがバリューオブジェクトなのだと考えればよいのだろう。いろいろなアドバイスがあるが、もっとも重要なのはデータの一貫性を保証することに注力することだ。別の言い方をすると、オブジェクトが構築されたら、不正なデータを保持していないことを保証する。そのためには、コンストラクタで入力データを検証するのが有効な手段となる。例外を投げる、あるいはアサーションをかける、あるいは入力データを新しいオブジェクトとして抽出し、事前に正しいデータである状態のものを入力とする、などが基本的な戦略になる。
2章のサービスほど抜け落ちていた領域ではなかった。それでもとても有益な内容だった。シンプルだが、というよりシンプルだからこそ、これからどういう心構えで設計していけばいいのか道筋が見えてきた気がする。ずっと求めていたのはこういうものだった。
## 2章を読んだ ➤ サービスの作成
オブジェクトの種類をサービスとそれ以外の2つに分類する。サービスのオブジェクトはどう扱われるべきかを、はっきりと示している。最初から言語にサービスを直接表現できるような能力が備わっていればよいのだが、不幸にもそうはなっていない。そんなことをしても言語の汎用性は失われてしまうので、当然のことではある。ともかく、そのため、この概念的なオブジェクトをコードで正しく表現するのはプログラマの負担となる。どのようにコードにするか以前に、サービスが存在していることを認識していないと話にならない。そこをクリアして初めて設計とスタイルの話に進むことができる。この章だけで値段分は回収した、そう思わされるくらいためになる内容だった。
## 1章を読んだ ➤ オブジェクトを使ったプログラミング入門
実在する言語ではなく、解説のための読みやすい架空の言語を用いている。PHPとJavaを混ぜたようなものとなっている。これから読み進めるにあたって必要となる、前提となる基礎を共有するための章となっている。これらは、オブジェクト指向を積極的にサポートするだいたいの言語が備えているもので、〜言語入門というような本でもよく取り上げられるもので、おなじみのものでもある。本書を読み進めるのに必要となる前知識はこれだけであるとも捉えられる。たったこれだけのことを、うまく使いこなすことができれば良い。たくさんのことや秘伝のテクニックを覚えるのではなく、正しい作法が身につけられれば良い。このタイトルの、スタイルガイドというフレーズはうまく内容を言い表しているように思わされる。
投稿元:
レビューを見る
オブジェクト指向プログラミングをしている人は是非読むべき
記載順とは異なるが、
・まえがき
・序文
・訳者あとがき
・10.8 抽象、具象、レイヤ、および依存関係
から読み始めると良いと思う
投稿元:
レビューを見る
オブジェクト設計の基本が学べる。
オブジェクト設計されたプログラムを触ったことがあれば、
各章のまとめを読んで、分からないところを読むと良いかもしれない。
各章に問題があって、クイズみたいで楽しい。