プリンシプルオブプログラミング実践編②凝集度/結合度

1. 次のコードは、メール送信の方法が直接固定されています。結合度の観点から、どの改善が望ましいでしょうか？


function sendPasswordReset(user, token) {
  const url = `https://example.com/reset?token=${token}`;
  const message = `こちらからパスワードを再設定してください: ${url}`;
  SmtpClient.send(user.email, message);
}

A. URLを https ではなく http にする
B. SmtpClient に直接依存せず、メール送信を抽象化したインターフェースに依存する
C. message を短くする
D. user.email を使わないようにする

2. 次のコードは、設定値への依存の仕方があまりよくありません。結合度の観点から適切な改善はどれでしょうか？


function connectDb() {
  const client = new DbClient({
    host: 'db.example.internal',
    port: 5432,
    user: 'app_user',
    password: 'secret'
  });
  return client;
}

A. DbClient のクラス名を短くする
B. host や user などの設定値を、直接コードにベタ書きするのではなく設定オブジェクトや環境変数から受け取る
C. port を 3306 に変更する
D. password を空文字にする

3. 次の関数は、複数のオブジェクトにまたがって状態を更新しています。結合度/凝集度の観点から、どのような設計リスクがありますか？


function completeTask(task, user, project) {
  task.completed = true;
  task.completedAt = new Date();

  user.completedTaskCount++;

  project.lastActivityAt = new Date();
}

A. Date コンストラクタを2回呼んでいること
B. task, user, project の3つの集約にまたがる更新ロジックを1つの関数にまとめており、複数のものと強く結合している
C. completed フラグを true にしていること
D. project に lastActivityAt を持たせていること

4. 次のコードは、法則的には「デメテルの法則（LoD）」に違反しやすいパターンです。結合度の観点から、最も問題になりやすい点はどれでしょうか？


function getCustomerCity(order) {
  return order.customer.address.city;
}

A. return を使っていること
B. city を使っていること
C. order → customer → address → city とオブジェクトチェーンをたどりすぎて、内部構造に依存していること
D. 関数名が get から始まっていること

5. 次のクラスは、「メール送信」と「テンプレート生成」を同じ場所で行っています。凝集度/結合度の観点から、どの設計が望ましいでしょうか？


class MailService {
  constructor(client) {
    this.client = client;
  }

  sendWelcomeMail(user) {
    const body = `ようこそ ${user.name} さん`;
    this.client.send(user.email, body);
  }

  sendByeMail(user) {
    const body = `ご利用ありがとうございました ${user.name} さん`;
    this.client.send(user.email, body);
  }
}

A. MailService を2つに分割し、1つは send 専用、1つはテンプレート専用にする
B. テンプレート生成を別クラスや関数に切り出し、MailService は「送る」責務に集中させる
C. user.name を使わないようにする
D. client を new するようにする

6. 次のコードは、UI層からドメインロジックへアクセスする際の結合の仕方を示しています。結合度を下げるために、最も有効な改善はどれでしょうか？


function onClickSaveButton() {
  const user = collectFormData();

  // ドメインロジックを直接 new
  const service = new UserService();
  service.save(user);

  alert('保存しました');
}

A. collectFormData を onClickSaveButton の外に移動する
B. UserService のインスタンスを引数やDIコンテナから注入し、UIコードが new しないようにする
C. alert のメッセージを変更する
D. function ではなくアロー関数を使う

7. 次のコードは、1つの関数が多くのフラグ引数に依存しています。凝集度/結合度の観点から、どのような問題がありますか？


function renderList(items, showHeader, showFooter, highlightActive, allowDelete) {
  // たくさんの条件分岐で描画を切り替える
}

A. items が配列であること
B. 関数の引数としてフラグが多すぎて、1つの関数に多くの役割が詰め込まれている
C. highlightActive を true にしていること
D. allowDelete を false にしていること

8. 次のコードは、「凝集度が低いクラス」の例です。どこが問題でしょうか？


class Utils {
  static formatDate(date) { /* ... */ }
  static calculateTax(price) { /* ... */ }
  static validateEmail(email) { /* ... */ }
  static sendMail(to, body) { /* ... */ }
}

A. static メソッドが使われていること
B. クラス名が Utils であり、日付、税金計算、バリデーション、メール送信という関係の薄い機能が1つのクラスに詰め込まれていること
C. メソッド名が英語なこと
D. コメントがないこと

9. 次の2つのクラスは、互いにお互いを new しています。結合度の観点から、どのような問題がありますか？


class A {
  constructor() {
    this.b = new B(this);
  }
}

class B {
  constructor(a) {
    this.a = a;
  }
}

A. クラス名が1文字で短すぎる
B. A と B が循環参照しており、互いに強く結合している
C. constructor を使っていること
D. this を保存していること

10. 次のクラスは、ログ出力と業務ロジックが混ざっています。凝集度/結合度の観点から、どのような改善が望ましいでしょうか？


class PaymentService {
  constructor(http) {
    this.http = http;
  }

  async pay(order) {
    console.log('PAYMENT START', new Date(), order.id);

    const result = await this.http.post('/payments', { orderId: order.id });

    console.log('PAYMENT END', new Date(), order.id, result.status);

    return result;
  }
}

A. console.log を減らし、1か所だけにする
B. ログ出力を別のロガーに委譲し、PaymentService は「支払い処理」に集中させる
C. result を返さないようにする
D. this.http をグローバル変数にする

AIが迷わない疎結合設計へリファクタ！
コードレビュー道場 #2：凝集度/結合度

#2 凝集度/結合度：疎結合へリファクタ！目次

コードレビュー道場 #2～密結合な設計を疎結合に変えよ！～

4. 次のコードは、法則的には「デメテルの法則（LoD）」に違反しやすいパターンです。結合度の観点から、最も問題になりやすい点はどれでしょうか？

`function getCustomerCity(order) { return order.customer.address.city; }`

8. 次のコードは、「凝集度が低いクラス」の例です。どこが問題でしょうか？

`class Utils { static formatDate(date) { /* ... / } static calculateTax(price) { / ... / } static validateEmail(email) { / ... / } static sendMail(to, body) { / ... */ } }`

9. 次の2つのクラスは、互いにお互いを new しています。結合度の観点から、どのような問題がありますか？

`class A { constructor() { this.b = new B(this); } } class B { constructor(a) { this.a = a; } }`

密結合な設計を疎結合に変えよ！
採点結果

参考文献・出典

このページの著者

もちもちみかん.comとは

AIが迷わない疎結合設計へリファクタ！コードレビュー道場 #2：凝集度/結合度

#2 凝集度/結合度：疎結合へリファクタ！ 目次

コードレビュー道場 #2～密結合な設計を疎結合に変えよ！～

4. 次のコードは、法則的には「デメテルの法則（LoD）」に違反しやすいパターンです。結合度の観点から、最も問題になりやすい点はどれでしょうか？ function getCustomerCity(order) { return order.customer.address.city; }

8. 次のコードは、「凝集度が低いクラス」の例です。どこが問題でしょうか？ class Utils { static formatDate(date) { /* ... */ } static calculateTax(price) { /* ... */ } static validateEmail(email) { /* ... */ } static sendMail(to, body) { /* ... */ } }

9. 次の2つのクラスは、互いにお互いを new しています。結合度の観点から、どのような問題がありますか？ class A { constructor() { this.b = new B(this); } } class B { constructor(a) { this.a = a; } }