論理的凝集

モジュールが 似た種類の処理 をひとまとめにしているだけで、その中の各処理は 目的が異なる

なんとなくカテゴリが似ているものが集まっているだけ

アンチパターン寄り (凝集度が低い)

gpt-5.icon

具体例①：バリデーション系を全部まとめた関数

code:ts

function validate(value: any, type: "email" | "phone" | "password") {

if (type === "email") {

return value.includes("@");

}

if (type === "phone") {

}

if (type === "password") {

return value.length >= 8;

}

}

どれも「バリデーション」に関係はある

でも 最終目的はそれぞれ別（メールだけチェックしたい、パスワードだけチェックしたい etc.）

具体例②：ユーティリティクラスにいろいろ詰め込み

code:ts

class Utils {

static parseDate(str: string): Date { ... }

static slugify(str: string): string { ... }

static randomString(): string { ... }

static formatMoney(num: number): string { ... }

}

「なんか便利なもの」だけが集まっている

目的はバラバラ

具体例③：バックエンド API 全部入り Controller

code:ts

class UserController {

createUser() {}

login() {}

resetPassword() {}

deleteUser() {}

}

どれも「ユーザー」に関係がある

しかし 目的は完全に別物（認証、作成、削除 etc）

OOP 的にはやりがちだが、凝集度としては 論理的凝集

論理的結合は、モジュールの要素間に何らかの論理的関係を示唆します。例としては、プログラムのためのすべての入出力操作を実行するモジュールや、すべてのデータを編集するモジュールがあります。論理的に結合された「すべてのデータを編集する」モジュールは、通常、以下のように実装されます。編集されるデータ要素がマスターファイルのレコード、更新、削除、追加であるとします。モジュールに渡されるパラメーターには、データとデータの種類を示す特別なパラメーターが含まれます。モジュールの最初の命令は、四つのコードセクションへの四方向分岐であることが考えられます。それは、マスターレコードの編集、更新レコードの編集、追加レコードの編集、および削除レコードの編集です。

しばしば、これら四つの機能も何らかの方法でモジュール内で絡み合っています。削除レコードが変更されて削除レコードの編集機能を変更する必要がある場合、この機能が他の三つと絡み合っていると問題が生じます。もし編集が真に独立しているならば、システムは各編集を別々のモジュールに置くことで単純化され、各実行でどの編集を行うかを決定する必要がなくなります。短く言えば、論理的結合は通常、修正が困難な巧妙なまたは共有コードを生じさせ、不必要なパラメーターの受け渡しを行います。

code:ts

type DataRecord = {

type: 'master' | 'update' | 'addition' | 'deletion';

data: any;

};

function editData(record: DataRecord) {

switch (record.type) {

case 'master':

editMasterRecord(record.data);

break;

case 'update':

editUpdateRecord(record.data);

break;

case 'addition':

editAdditionRecord(record.data);

break;

case 'deletion':

editDeletionRecord(record.data);

break;

default:

throw new Error('Unknown record type');

}

}