なぜclassは使わない？JavaScriptの歴史・設計思想・現場のリアルから学ぶ最適なコーディング戦略

JavaScriptで開発をしていると、「class構文って本当に必要なの？」と疑問に感じたことはありませんか？

最近はReactやVue3などのモダンフレームワークでも、classを使わない関数ベースの設計が主流になりつつあります。また、「classはJavaScriptらしくない」「thisが面倒」「関数やクロージャだけで十分」といった声もよく聞かれます。実際、ES5以前の時代からJavaScriptはプロトタイプベースの柔軟なオブジェクト指向を持っており、class構文は後から追加された“シンタックスシュガー”にすぎません。

しかし、「classを使わない設計」と言っても、具体的にどんなメリットやデメリットがあるのか、どうやって保守性や再利用性を確保するのか、現場で迷う方も多いはずです。本記事では、class構文の歴史や設計思想から、関数・クロージャ・プロトタイプチェーンを活用した実践的なパターン、現場での判断基準や活用ノウハウまで、体系的に解説します。

「classを使わない」JavaScript設計の本質と実践例を、ぜひ最後までご覧ください。

JavaScriptでclassを使わない理由と設計思想の全体像

JavaScriptのclass構文が生まれた歴史と目的

なぜJavaScriptにclassが導入されたのか、ご存知ですか？

JavaScriptは元々、プロトタイプベースのオブジェクト指向言語として設計されました。しかし、JavaやC#、Pythonなどのクラスベース言語に慣れ親しんだ開発者にとって、その独自のオブジェクト指向モデルは理解しにくいものでした。特に、オブジェクトの生成や継承の記述が冗長だと感じられることもありました。

そこで、2015年にリリースされたES2015（ES6）で、class構文が導入されました。このclassは、既存のプロトタイプベースのオブジェクト指向の上に構築された「シンタックスシュガー」（構文糖衣）です。つまり、内部的にはこれまで通りのプロトタイプベースの仕組みが動いていますが、見た目だけをクラスベースの言語に近づけることで、より多くの開発者にJavaScriptを受け入れやすくすることが目的でした。

これにより、JavaやC++などのクラスベース言語からJavaScriptに移行してきた開発者も、比較的スムーズにオブジェクト指向的なコードを書けるようになりました。

JavaScriptのclass構文が「JavaScriptらしくない」と言われる理由

しかし、このclass構文は、一部のJavaScript開発者から「JavaScriptらしくない」と評されることがあります。その理由は、JavaScriptの根本的な思想であるプロトタイプベースのオブジェクト指向と、class構文がもたらす「クラスベース」の概念との間にギャップがあるからです。

• thisのバインディング問題:
  class内でメソッドを定義すると、thisの参照が呼び出し方によって変わるというJavaScript特有のバインディング問題に直面しやすくなります。これに対処するために、.bind()やアロー関数を使う必要がありますが、これはコードの複雑さを増す要因となります。
• 継承の複雑さ:
  classによる継承は、多重継承ができないなど、他のクラスベース言語に比べて機能が限定的です。また、継承関係が深くなると、コードの依存性が高まり、密結合になりやすいという問題があります。これは、一部の機能を変更しようとすると、関連する多くの箇所に影響が出てしまうという、**「ダイヤモンド問題」**のような複雑性を生む可能性もあります。

classを使わない設計が活きるユースケースと判断基準

では、具体的にどのような場面でclassを使わない設計が有効なのでしょうか？

classを使わない設計は、特に以下のようなユースケースでその真価を発揮します。

• 軽量なユーティリティ関数やヘルパー関数の作成:
  複雑な状態管理や継承が不要な場合、シンプルな関数で十分です。例えば、数値計算や文字列操作、日付フォーマットなどの共通関数。
• モダンなUIコンポーネント開発:
  Reactの関数コンポーネントとHooks、Vue 3のComposition APIは、まさにclassを使わない設計の代表例です。これらは、ステートフルなロジックを関数として再利用可能にし、コンポーネントの可読性と保守性を高めます。
• 関数型プログラミングとの親和性:
  Immutable.jsやLodashのような関数型ライブラリと組み合わせることで、データの不変性（イミュータビリティ）を保ちつつ、より予測可能でテストしやすいコードを書けます。
• 単体テストのしやすさ:
  classに比べ、純粋な関数は外部依存が少なく、テストのモック化やスタブ化が容易です。これにより、単体テストの記述コストが大幅に削減されます。
• 依存性の注入（DI）の容易さ:
  必要な依存関係を関数の引数として渡すことで、特定のクラスに密結合することなく、柔軟なコンポーネントの入れ替えが可能になります。

これらのメリットから、「小規模なモジュール」「ビジネスロジックが複雑でない部分」「UIコンポーネント開発」など、シンプルさや再利用性が求められる場面で、classを使わない設計が非常に有効な選択肢となります。

classを使わずにオブジェクト指向設計を実現する具体的な方法

classを使わないからといって、JavaScriptでオブジェクト指向プログラミングができないわけではありません。むしろ、JavaScript本来の柔軟な特性を活かし、より洗練された方法でオブジェクト指向的な設計を実現できます。

関数・クロージャ・プロトタイプチェーンによる実装パターンとコード例

まずは、classを使わずにオブジェクトを生成し、操作する基本的なパターンを見ていきましょう。

コンストラクタ関数によるオブジェクト生成（ES5以前の基本）

class構文が導入される前から、JavaScriptではコンストラクタ関数を使ってオブジェクトを生成するのが一般的でした。

// コンストラクタ関数
function Person(name, age) {
  this.name = name;
  this.age = age;
}

// プロトタイプにメソッドを追加
Person.prototype.greet = function() {
  console.log(`こんにちは、${this.name}です。${this.age}歳です。`);
};

const john = new Person('John', 30);
john.greet(); // こんにちは、Johnです。30歳です。

const alice = new Person('Alice', 25);
alice.greet(); // こんにちは、Aliceです。25歳です。

newキーワードを使ってコンストラクタ関数を呼び出すことで、新しいオブジェクトが生成され、thisはその新しいオブジェクトを指します。メソッドはprototypeに追加することで、メモリ効率良く共有されます。ただし、thisのバインディングには注意が必要です。

ファクトリ関数によるオブジェクト生成

newキーワードを使わずにオブジェクトを生成するパターンがファクトリ関数です。これは、thisのバインディング問題を回避し、より柔軟なオブジェクト生成が可能です。

// ファクトリ関数
function createPerson(name, age) {
  return {
    name: name,
    age: age,
    greet: function() {
      // thisの参照がシンプル
      console.log(`こんにちは、${this.name}です。${this.age}歳です。`);
    }
  };
}

const bob = createPerson('Bob', 40);
bob.greet(); // こんにちは、Bobです。40歳です。

ファクトリ関数はシンプルで理解しやすいですが、メソッドがオブジェクトごとに新しく生成されるため、大量のオブジェクトを生成する場合はメモリ効率が劣る可能性があります。

クロージャを活用したオブジェクト生成（プライベート変数も実現）

JavaScriptのクロージャは、関数がその宣言されたスコープにある変数にアクセスできる特性です。これを利用すると、外部から直接アクセスできない「プライベート変数」を実現し、カプセル化されたオブジェクトを作成できます。

function createCounter() {
  let count = 0; // プライベート変数

  return {
    increment: function() {
      count++;
      console.log(`現在のカウント: ${count}`);
    },
    decrement: function() {
      count--;
      console.log(`現在のカウント: ${count}`);
    },
    getCount: function() {
      return count;
    }
  };
}

const counter1 = createCounter();
counter1.increment(); // 現在のカウント: 1
counter1.increment(); // 現在のカウント: 2
console.log(counter1.getCount()); // 2
// console.log(counter1.count); // undefined - countはプライベートなのでアクセスできない

const counter2 = createCounter(); // 別のカウンタ
counter2.increment(); // 現在のカウント: 1 (counter1とは独立)

この例では、count変数はcreateCounter関数のスコープ内に閉じ込められており、外部からはincrementやdecrement、getCountメソッドを介してのみ操作できます。これにより、オブジェクトの状態が意図せず変更されることを防ぎ、堅牢なコードになります。

Object.create()によるプロトタイプ継承

Object.create()は、指定したオブジェクトをプロトタイプとして新しいオブジェクトを作成します。これにより、従来のプロトタイプベースの継承をより明示的に記述できます。

const personPrototype = {
  greet: function() {
    console.log(`こんにちは、${this.name}です。`);
  }
};

const emily = Object.create(personPrototype);
emily.name = 'Emily';
emily.greet(); // こんにちは、Emilyです。

const david = Object.create(personPrototype);
david.name = 'David';
david.greet(); // こんにちは、Davidです。

これは、JavaScriptのオブジェクト指向の根幹を理解する上で非常に重要な概念ですが、直接プロトタイプを操作するため、より低レベルな知識が求められます。

ミックスイン・合成（composition）による柔軟な設計手法

複雑なクラス階層を構築する代わりに、JavaScriptではミックスインや合成（Composition）といった手法で、柔軟に機能を組み合わせることができます。これは「継承よりも合成を優先する（Composition over Inheritance）」という設計原則にも通じます。

ミックスイン（Mixin）

ミックスインは、オブジェクトに既存のプロパティやメソッドを「混ぜ込む」設計パターンです。多重継承がないJavaScriptにおいて、複数のソースから機能を再利用する効果的な方法です。

// ミックスインとして機能を提供するオブジェクト
const canLog = {
  log(message) {
    console.log(`[LOG] ${message}`);
  }
};

const canSave = {
  save() {
    console.log('データを保存しました。');
  }
};

// オブジェクトにミックスインを適用するファクトリ関数
function createLoggerAndSaver(name) {
  const obj = { name };
  Object.assign(obj, canLog, canSave); // 機能を混ぜ込む
  return obj;
}

const user = createLoggerAndSaver('UserA');
user.log('ユーザーデータを作成しました。'); // [LOG] ユーザーデータを作成しました。
user.save(); // データを保存しました。

Object.assign()を使うことで、canLogとcanSaveのメソッドがuserオブジェクトにコピーされ、利用できるようになります。

合成（Composition）

合成は、オブジェクトを構築する際に、他のオブジェクトをプロパティとして含めることで機能を持たせる設計手法です。これにより、密結合な継承階層を避け、疎結合で変更に強い設計を実現できます。

// 機能を提供するシンプルなオブジェクト
const logger = {
  log(message) {
    console.log(`[Logger] ${message}`);
  }
};

const database = {
  save(data) {
    console.log(`[Database] データ '${data}' を保存しました。`);
  }
};

// 機能を「合成」して新しいオブジェクトを作成
function createUserProcessor(name, loggerService, dbService) {
  return {
    name,
    processUser(userData) {
      loggerService.log(`ユーザー ${name} がデータを処理中...`);
      dbService.save(userData);
    }
  };
}

const userProcessor = createUserProcessor('Admin', logger, database);
userProcessor.processUser('新しいユーザー情報');
// [Logger] ユーザー Admin がデータを処理中...
// [Database] データ '新しいユーザー情報' を保存しました。

この例では、createUserProcessorがloggerServiceとdbServiceをプロパティとして持ち、それらの機能を利用しています。これにより、UserProcessorはloggerServiceやdbServiceの具体的な実装に依存せず、柔軟な置き換えが可能になります。

プライベート変数やカプセル化をclassなしで実現するテクニック

JavaScriptのclass構文には、現時点では真のプライベートプロパティはありません（一部のモダンな提案はありますが）。しかし、classを使わない方法であれば、プライベートな状態をより確実にカプセル化できます。

クロージャを利用したプライベート変数

前述のクロージャの例（createCounter）が最も一般的な方法です。関数スコープ内の変数は外部から直接アクセスできないため、完全にプライベートな状態を維持できます。

function createBankovacíÚčet(initialBalance) {
  let balance = initialBalance; // プライベート変数

  return {
    deposit(amount) {
      balance += amount;
      console.log(`入金: ${amount}, 残高: ${balance}`);
    },
    withdraw(amount) {
      if (balance >= amount) {
        balance -= amount;
        console.log(`出金: ${amount}, 残高: ${balance}`);
      } else {
        console.log('残高不足です。');
      }
    },
    getBalance() {
      return balance; // 参照のみ許可
    }
  };
}

const myAccount = createBankovacíÚčet(1000);
myAccount.deposit(500);  // 入金: 500, 残高: 1500
myAccount.withdraw(200); // 出金: 200, 残高: 1300
console.log(myAccount.getBalance()); // 1300
// console.log(myAccount.balance); // undefined (プライベート)

Symbolを用いたプライベートプロパティ（擬似的）

ES6で導入されたSymbolは、ユニークなプロパティキーを作成できます。これにより、外部からの意図しないプロパティアクセスを防ぐ、擬似的なプライベートプロパティを実現できます。

Symbol - JavaScript | MDN

Symbol は組み込みオブジェクトであり、コンストラクターは一意であることが保証されているシンボルプリミティブ（シンボル値または単にシンボル）を返します。シンボルは、他のコードがオブジェクトに追加する可能性のあるキーと衝突しないように、また、他のコードがオブジェクトにアクセスするために通常使用するメカニズムから隠され...

developer.mozilla.org

const _secretData = Symbol('secretData'); // ユニークなシンボルを作成

function createDataStore() {
  const store = {};
  store[_secretData] = 'これは秘密のデータです'; // Symbolをキーとして設定

  return {
    getSecretData() {
      return store[_secretData];
    },
    // 他の公開メソッド
  };
}

const dataStore = createDataStore();
console.log(dataStore.getSecretData()); // これは秘密のデータです
// console.log(dataStore._secretData); // undefined
// console.log(Object.getOwnPropertySymbols(dataStore)); // [Symbol(secretData)] - Symbolキーは取得できるが、キー名を知らないとアクセスしにくい

Symbolを使ったプロパティは完全にプライベートではありませんが、通常の方法ではアクセスしにくいため、意図しないアクセスを防ぐのに役立ちます。

WeakMapを利用したプライベートデータ

WeakMapは、オブジェクトをキーとして、関連するデータを保存するMapです。キーが参照されなくなると、ガベージコレクションによって自動的にメモリから解放される特性があります。これを利用して、外部から参照できない完全にプライベートなデータを実現できます。

const privateData = new WeakMap();

function createPersonWithPrivateId(name) {
  const person = { name };
  privateData.set(person, { id: Math.random().toString(36).substring(7) }); // Personオブジェクトをキーにプライベートデータを設定

  return {
    getName() {
      return person.name;
    },
    getPrivateId() {
      return privateData.get(person).id;
    }
  };
}

const userA = createPersonWithPrivateId('Alice');
console.log(userA.getName());      // Alice
console.log(userA.getPrivateId()); // 例: "b3f0xya"

// privateDataから直接idを取得することはできない
// console.log(privateData.get(userA).id); // これはgetPrivateId()を通して可能だが、直接WeakMapにアクセスする必要がある

WeakMapのキーは外部から参照できなくなると自動的に削除されるため、メモリリークのリスクも低減できます。

classを使わない場合のメリット・デメリットと現場での活用ノウハウ

classと関数ベースのパフォーマンス・可読性・保守性比較

classと関数ベースのどちらが良いかは、一概には言えません。しかし、いくつかの観点から比較することで、プロジェクトに合った選択ができるようになります。

結論として、一般的なWebアプリケーション開発において、classと関数ベースのコードでパフォーマンスに決定的な差が出ることはほとんどありません。むしろ、可読性と保守性、そしてテスト容易性といった要素が、長期的なプロジェクト運営においてはるかに重要です。

関数ベースのコードは、thisの参照がシンプルで、関数の引数と返り値が明確であるため、コードの挙動を追いやすいというメリットがあります。また、密結合を避け、疎結合なモジュールを組み合わせることで、変更に強く、バグを特定しやすいという保守性のメリットを享受できます。

classを使わない設計が向いているプロジェクトの特徴と判断基準

前述のユースケースと重複しますが、どのようなプロジェクトでclassを使わない設計が向いているのか、具体的な判断基準をまとめます。

• 小規模〜中規模プロジェクト: 複雑な継承構造が不要で、シンプルさと迅速な開発が求められる場合。
• ライブラリや共通関数群の開発: 特定のフレームワークやclassに依存せず、再利用性を最優先し、軽量なコードを提供したい場合。
• 関数型プログラミングを積極的に採用したいチーム: Immutable.jsやRamdaなどの関数型ライブラリを積極的に活用し、純粋関数とデータの不変性を重視する開発スタイル。
• テスト容易性を重視する開発: テストコードの記述コストを抑え、自動テストによる品質保証を徹底したい場合。モック化やスタブ化が容易になるため、テストカバレッジを高めやすくなります。
• チームのスキルセット: チームメンバーが関数型プログラミングやJavaScriptのプロトタイプベースのオブジェクト指向を深く理解している場合、スムーズに導入できます。

class構文に依存しないモジュール設計と実用的コード例

現代のJavaScript開発において、モジュールシステムは不可欠です。classに依存しない設計は、モジュールシステムの恩恵を最大限に活用できます。

ES Modules (ESM) によるモジュール化

ES Modulesは、JavaScriptにおける公式のモジュールシステムです。exportとimportキーワードを使って、機能の提供と利用を明確にできます。

// math.js (モジュールファイルの例)
export function add(a, b) {
  return a + b;
}

export function subtract(a, b) {
  return a - b;
}

// main.js (モジュールの利用例)
import { add, subtract } from './math.js';

console.log(add(5, 3));      // 8
console.log(subtract(10, 4)); // 6

このように、classを使わずに関数をexportするだけで、シンプルで再利用可能なモジュールを作成できます。

シングルトンパターンの代替（モジュールスコープの活用）

classでシングルトンパターンを実装すると、インスタンスの生成を制御するために複雑なロジックが必要になることがあります。しかし、ES Modulesのモジュールスコープを活用すれば、簡単にシングルトンを実現できます。

// logger.js (シングルトンLoggerモジュール)
let instance = null; // モジュールスコープに隠蔽されたインスタンス

function initLogger() {
  if (instance) {
    return instance; // 既にインスタンスがあればそれを返す
  }
  // 初回のみインスタンスを生成
  instance = {
    logs: [],
    log(message) {
      this.logs.push(message);
      console.log(`[Logger] ${message}`);
    },
    getLogs() {
      return this.logs;
    }
  };
  return instance;
}

const logger = initLogger(); // モジュール読み込み時にインスタンスが生成され、エクスポートされる

export default logger;

// main.js (シングルトンLoggerの利用)
import logger from './logger.js';
import anotherLogger from './logger.js'; // 同じインスタンスが取得される

logger.log('アプリケーション開始');
anotherLogger.log('ユーザーログイン'); // 同じログに追加される

console.log(logger.getLogs()); // ['アプリケーション開始', 'ユーザーログイン']

initLogger関数が一度しか実行されないように工夫することで、モジュールとしてシングルトンが実現できます。

依存性の注入（DI）のシンプルな実現

依存性の注入は、コンポーネントが依存するオブジェクトを外部から渡すことで、コンポーネント間の結合度を低減する設計パターンです。関数ベースの設計では、関数の引数として依存するサービスを渡すことで、非常にシンプルにDIを実現できます。

// dataService.js (データ取得サービス)
export const createDataService = () => ({
  fetchUsers: async () => {
    // 実際はAPI呼び出しなど
    return [{ id: 1, name: 'Taro' }, { id: 2, name: 'Hanako' }];
  }
});

// userService.js (ユーザー処理サービス)
export const createUserService = (dataService) => ({ // dataServiceを注入
  getUsersWithGreeting: async () => {
    const users = await dataService.fetchUsers();
    return users.map(user => `こんにちは、${user.name}さん！`);
  }
});

// app.js (アプリケーションのエントリーポイント)
import { createDataService } from './dataService.js';
import { createUserService } from './userService.js';

const dataService = createDataService(); // 依存関係を生成
const userService = createUserService(dataService); // 注入

(async () => {
  const greetings = await userService.getUsersWithGreeting();
  console.log(greetings); // ['こんにちは、Taroさん！', 'こんにちは、Hanakoさん！']
})();

この例では、createUserServiceがcreateDataServiceによって生成されたdataServiceを引数として受け取っています。これにより、userServiceは特定のdataServiceの実装に直接依存せず、テスト時などに異なるdataService（モックなど）を簡単に注入できるようになります。

よくある質問（FAQ)

まとめ

この記事では、JavaScriptでclassを使わない選択肢がなぜモダン開発において重要なのか、その理由と具体的な手法、そして現場での活用ノウハウについて解説しました。

class構文は、JavaScriptが多くの開発者に受け入れられる上で重要な役割を果たしましたが、必ずしも唯一の、あるいは最良の選択肢ではありません。JavaScriptの柔軟な特性を最大限に活かすためには、プロトタイプチェーン、クロージャ、ファクトリ関数、そして合成（コンポジション）といった、classに依存しない設計パターンを理解し、活用することが不可欠です。

これらの手法は、コードの可読性、保守性、テスト容易性を高め、結果として開発効率の向上にも繋がります。特に、ReactのHooksやVue 3のComposition APIなど、モダンなフレームワークの主流が関数ベースにシフトしている現代において、classを使わない設計思想は、あなたのスキルセットをさらに次のレベルへと引き上げるでしょう。

popstateが発火しない原因と解決策を徹底解説！History APIと連携した正しい実装パターン＆各ブラウザ対応法

popstateが発火しない原因や対処法にお困りではありませんか？本記事では、History APIとの関係性や、Chrome・Safari・Edgeなど主要ブラウザごとの挙動の違いを解説。発火しない主なケースやデバッグ方法、確実に動作させる実装方法までわかりやすくご紹介。popstateで悩んだときに役立ちます。

watashi.xyz

2025.06.05