<輪読会> オブジェクト指向実践ガイド -第1章オブジェクト指向設計-

オブジェクト指向実践ガイド（書籍）

輪読会メンバー

  • Izumi Haruya

github.com

  • Sekine Yutaro

github.com

第1章オブジェクト指向設計

世界は手続き的な一方で、オブジェクト的でもある

  • オブジェクトとは、もの・実態
  • オブジェクト指向ソフトウェアの設計では、世界をオブジェクト間の自発的な相互作用の連続として捉え、発想の転換が求められる
  • まず、オブジェクト指向的な世界に没入するのが大事

    視点の置き方が原因になりがち

1.1設計の賞賛

楽しさと生産性を天秤にかける必要がない。

  • どちらかが上がると楽しいから共存できる

アプリケーションは可変であるとは

  • 後から要件が変わること
  • 変更が容易なアプリは書くのも拡張も楽しい
  • 変更を拒むアプリは逆...
    • コストがかかる
    • 苦痛である

設計が解決する問題

オブジェクトが知識を持ち過ぎていると、扱いにくい

上記を理解する比喩は以下

オブジェクトが知識を持ちすぎているとき、オブジェクトは自分のいる世界に対して多くのことを望みます。そういったオブジェクトは気難しいので、物事が変わらずに「ただそのように」あるべきことを求めます。そして、その望みがそのままそのオブジェクト自身の制約となってしまいます。異なる環境で再利用しようとしても、オブジェクトがそうさせてくれません。そういったオブジェクトはテストするにも苦痛であり、また、複製もされやすいものです。アプリケーションが小さければ、設計が貧弱でも耐えられます。あらゆるものが自分以外のすべてに結合していたとしても、一度にすべてを頭にとどめておくことができるぐらいの量であれば、まだアプリケーションの改善は可能です。 Sandi Metz. オブジェクト指向設計実践ガイド　～Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方

変更が困難な理由

オブジェクト指向のアプリは部品から成る

  • 部品(オブジェクト)の関係性はメッセージと言い換えられる

    メッセージの送り方(関係性の捉え方)が難しいということか(問い) オブジェクト同士を如何に知っているかが重要

  • オブジェクト指向設計は、依存関係を構築・管理する為のテクニックである
  • オブジェクトが加変した時のメッセージの管理が難しい

    できるだけ具体化して管理しやすくするということか(問い)

設計の実用的な定義

  • 設計が難しい理由の1つは、すべての問題が2つの要素を抱えている点にあります。
  • 同じコードにしても、いまユーザーに届けようと計画している機能のコードをただ書くのではなく、その後の変更も受け入れられるものをつくらなければなりません。

    具体的に考えると、コードの読みやすさを意識するということか(問い)

  • 実用的な設計とは、未来を推測するものではなく、未来を受け入れるための選択肢を保護するものなのです。
  • 選択してしまうのではなく、動くための余地を設計者に残すものです。
    • 変更できる余地を残すコード

1.2設計の道具

設計とは、枝分かれする道を進む旅である

  • 未来への決断の連続であり、その決断をする為には原則とパターンが必要

設計原則

SOLID・・・オブジェクト指向設計で最もよく知られる5つの原則

  • 単一責任（SingleResponsibility）
  • オープン・クローズド（OpenClosed）
  • リスコフの置換（LiskovSubstitution）
  • インターフェース分離（InterfaceSegregation）
  • 依存性逆転（DependencyInversion）

原則は重要だが、その原則の起源とは

  • 過去の人達がコードを書く中でコードには良し悪しがあると感じ、それらを科学的に定量化し見える化することに成功

メトリクスとは、様々な活動を定量化し、その定量化したデータを管理に使えるように加工した指標のことです。 簡単に言うと、何かしらデータを収集して、そのままの形ではなくて、計算や分析を加えてわかりやすいデータ（数値）に変換したのがメトリクスです

設計(デザイン)パターン

  • Gang of Four(GoF)→ 『Design Patterns』
  • デザインパターンで大切なこと
    • 設計プロダクトの柔軟性
    • モジュール性
    • 再利用性
    • 理解のしやすさ
  • 正しく理解して利用することが大切
    • 正しいパターンを間違った問題に適用してしまうといったことが起きた。
    • パターンを間違って適用すれば、当然、複雑で混乱を招くコードがつくられる。
    • パターンそのものに責任はない。

1.3設計の行為

設計のルールができたが、それでも問題が発生 - ルールの扱い方が大事

設計が失敗する原因

  • 設計が十分でないから失敗する

    • Rubyなど（動的型付け言語）は影響を受けやすい（設計されていないアプリケーション）
    • パターンは知っているけどうまく適用できていない
      • 最終的に、設計の行為と実装の行為が乖離したとき、オブジェクト指向ソフトウェアは失敗する。

  • [アジャイルソフトウェア運動]（http://agilemanifesto.org/）

    • この反復的な手法は、適切に設計されたオブジェクト指向アプリケーションをつくるためにはまさにうってつけである

設計をいつ行うか

アジャイルの正しい考えとは

  • 顧客にはすぐ見せる(共同作業)がベスト
  • BUFD(全体感・詳細設計)と期限はある程度大事だが、固執しすぎない
  • アジャイルプロセスは「変更が起きることを約束」

    BUFDとは逆の考え方

BUFD：BigUpFrontDesign(前もって全体の詳細設計)

設計を判断する

昔はコードの量でコードの良し悪しが判断されていた。

当時はそれらが良いか悪いか判断すること自体が必要とされていた。

  • メトリクスを測定するGemがある。ただその数値が全てではない
  • 未来には良いと言うこともあるから現在はあまりよくないと言うこともある
  • コスト・機能・時間は、そのどれも定義・追跡・計測するのが難しい
  • 今と未来のトレードオフ（今にこだわりすぎることを技術的負債という）
  • どの期間で設計するか（自身のスキルと結果が出るまでの時間）

1.4オブジェクト指向プログラミングのかんたんな導入

オブジェクトとメッセージだとメッセージの方が重要

  • でも、一旦この節では上記を同等に扱う

手続き型言語

自分の知識・経験に基づく

オブジェクト指向言語

全てはオブジェクトとして振る舞うということ

現場Railsのオブジェクトとインスタンスの説明がわかりやすい

1.5まとめ

(長期でみて)変化に対するアプリケーションの変更が容易にできるかが大事

  • その為には、オブジェクト指向のパターンに適切に基づいた設計が大事
  • 理論より、とにかく実践が大事。ベストの積み重ねが必要

参考書籍

オブジェクト指向設計実践ガイド ～Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方 | Sandi Metz, 髙山泰基 | 工学 | Kindleストア | Amazon