新しい機能実装時の設計ポイント

カテゴリーから探す

年別から見る

2020/07/03

プログラム

新しい機能実装時の設計ポイント

はじめに

主にMVCにおける自分なりの(内部)設計ポイントをまとめました。

設計時のポイント

不具合が起きても改修しやすいように
依存性が低い
機能単位で役割などの定義をはっきりさせる

機能をまとめる

今回はAPI連携など他の機能からある程度分離しているものを例とする。

留意点は以下。

大きな機能として一つのファイル(群)にまとめる
Controllerは「受け渡し」の役割だけを担わせる
データ整形であっても「その機能に依存する」限り機能ファイル(群)に集約する
Controllerから呼び出す機能単位で関数を先にInterfaceとして作っておく

以降では、大機能として追加開発の全体を定義して
中機能として「大機能の中で使う機能の種類」を定義し、
小機能として「中機能を実現するための細かな関数単位での処理」を定義することとする。

例えばこんな感じです


  resultAction
  // 支払い連携処理内
  $handler = new NewFeature($this->container);
  $result = $handler->doAPI($data, 'cart');

  // resultの結果によって処理が必要であれば記述

resultAction

// 支払い連携処理内

$handler = new NewFeature($this->container);

$result = $handler->doAPI($data, 'cart');

// resultの結果によって処理が必要であれば記述


  /**
   * @summary API連携する
   * @param   array  data 連携内容のパラメータ
   * @param   string flow dataに対する種別など
   * @return  array       連携結果
   */
  public function doAPI($data, $flow = 'cart')
  {
    switch ($flow) {
    case 'cart':
      $data = $this->cartToModel($data);
      $res = $execAPI($data);
      break;
    }
  }

  /**
   * @summary データモデル置換
   * @param   array  data 連携内容のパラメータ
   * @return  array       共通のデータモデル
   */
  private function cartToModel($data)
  {
    // データ整形 (省略)
    return $reformatData;
  }

/**

* @summary API連携する

* @param array data 連携内容のパラメータ

* @param string flow dataに対する種別など

* @return array 連携結果

public function doAPI($data, $flow = 'cart')

{

switch ($flow) {

case 'cart':

$data = $this->cartToModel($data);

$res = $execAPI($data);

break;

}

/**

* @summary データモデル置換

* @param array data 連携内容のパラメータ

* @return array 共通のデータモデル

private function cartToModel($data)

{

// データ整形 (省略)

return $reformatData;

}

などのようにする。
機能自体に不具合があっても基本的には(上述で示す)Handlerの修正だけで済む。

機能のブラックボックス

前項のHandlerにて複数の機能があるとします。

例えば

商品検索
注文作成(決済連携)

これは「一つの(大きな括りでの)機能」としてのHandler管理に対して、
「商品検索」「注文作成」という枝分かれした機能を「関数」として先に定義しておく。
Controllerなど呼び出される時は必ずここだ、というエンドポイント的な役割。


  /**
   * @summary 商品検索
   * @param   array    params 検索用パラメータ
   * @return  array           検索結果データ
   */
  public function productSearch($params = array())
  {
    // 前処理

    // 連携処理

    // 後処理

    return $result;
  }

  /**
   * @summary 注文作成連携
   * @param   array    params 注文データ
   * @return  array           検索結果データ
   */
  public function order($params = array())
  {
    // 前処理

    // 連携処理

    // 後処理

    return $result;
  }

/**

* @summary 商品検索

* @param array params 検索用パラメータ

* @return array 検索結果データ

public function productSearch($params = array())

{

// 前処理

// 連携処理

// 後処理

return $result;

}

/**

* @summary 注文作成連携

* @param array params 注文データ

* @return array 検索結果データ

public function order($params = array())

{

// 前処理

// 連携処理

// 後処理

return $result;

}

先にこれだけ書いておくことで後からたどりやすくなる。
また「この機能のどの中機能を修正・更新したい」という時に
そこから辿れりやすく、中機能の中で完結するよう運用がしやすくなる。

特に最初に細かく設計をせず
流動的に進める場合に有効である。
予め命名規則なども開発全体でルール作りなどしておくとスムースであろう。

上記の例だと
前処理、中機能でやるべき中枢の処理、後処理
を埋めていくだけで良くなる。
実装当初は何も処理せず、呼び出し側がそれだけで
従来の機能を果たすようにしておくと、後のテストも楽になるであろう。
PHPDocなど各処理の役割に対して実装前に定義しておくと
開発者以外の共有としても好ましいかもしれない。

Author Profile