skillup

技術ブログ

プログラミング全般

オブジェクト指向 クラスの設計と業務ロジックの整理

投稿日:

本日も引き続き「現場で役立つシステム設計の原則」を読み進めてます。

本日は主にクラスの作り方について。

クラス設計と業務ロジック

要点

  • データを入れるだけのクラスを書かない
  • データとメソッドを一か所にまとめる
  • 関連するロジックを3層(アプリケーション層、データ層、プレゼンテーション層)で使うとそれぞれの構造に依存したメソッドができてしまう
  • 上記問題点を解決するため3層の関心ごとと業務ロジックを分離する
  • 下手に汎用ライブラリ(Util系)にメソッドを集めすぎない
  • コントローラー側は基本メソッドを呼び出すだけ、データは受け取るだけ
  • 必ずインスタンス変数を使って処理を行う(オブジェクト指向の原則はまとめる、隠す、たくさんつくる)
  • 関連するデータとメソッドを一か所に「閉じ込める」意識を持つ
  • クラスが肥大化したら分ける→ロジックとメソッドが完全に密接するようにする(凝縮度を高くする)
  • なるべく小さい単位に分ける注文クラスとかはだめドメイン単位で分ける
  • 大きいクラスのまとまりをパッケージとして管理する。例えば注文(Order)などとという業務単位は大きすぎるため、通常はパッケージとして管理し、関連する関心ごとをクラスとして設計する。
  • 3層アーキテクチヤでクラスの設計+業務の関心事(ドメインモデル)でクラスを設計する

感想

これまでの自分のやり方なんですが、MVCモデルによって作られたフレームワークで仕事を進めることが多かったのでこれを踏襲する形で仕事はしていました。

ただクラスという概念を有効活用できていませんでしたね・・本書ではただデータを入れるだけのクラスをデータクラスと呼びこの活用法を批判していますが、データだけを格納したクラスを使うとロジックがあちらこちらに分離して変更コストが馬鹿になりません。

私の場合、モデルにあたる部分の担当が多すぎて、基本DBからデータとってコントローラでひたすらハッシュでぐるぐる回して画面に吐くという処理を繰り返していました・・これだとテストもコントローラに依存するのでやりにくいですしね・・・

この本でいわれているように同じようなロジックがあちこちらに散在しているというような問題点が頻発していました。対応策としてはやはり業務ロジックをMVCに従ってかかないということですね。このために必要な考え方がドメイン駆動設計なのだと思います。

-プログラミング全般
-

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

no image

フレームワークのマイナーバージョンチェンジの影響に関して

ここ1年ぐらいPHPのフレームワークはLaravelを使っていますが、マイナーバージョンの影響に悩まされることがたまにあります。 以前、遭遇した事象としてはログイン連携が急にできなくなりました。 La …

no image

ファジープロジェクト対策 その1

5月ぐらいから着手していたプロジェクト(顧客管理ソフト)が終焉を迎え、検証段階に入ったので、記して置きたいことなど。 数ヶ月程度ですが、自分が携わったプロジェクトの中では過去最大クラスのものでした。 …

no image

コレクションの頻出処理に関して

PHPでコレクションを使っていますが、慣れると本当に便利ですね・・・まあforeachとかでグリグリやってもいいのですが、無駄にコードが長くなります。 自分がコレクションでよく使う再頻出のメソッドなど …

no image

正規表現に関して

SQLネタをいろいろと書いておりますが、ちょっとワンポイント的なネタで正規表現について書きたいと思います。 平均的なものは知っているつもりでしたが、シェルの正規表現について知らなかったのでちょっとメモ …

no image

バッチスクリプトで気をつけたい点

実務でバッチ処理を作る際に気をつけるべきと思ったこと。 基本的にエラーをいかに捉えていかにログに吐くかを最初に考える。まずはエラーありき。失敗するもの、想定した値がこない、あるいは値がないを前提として …