TypeScriptは、JavaScriptに静的型付けを追加した言語であり、オブジェクト指向設計の導入がしやすくなっています。オブジェクト指向設計では、データを適切に管理し、外部からの不正なアクセスを防ぐことが重要です。このために、TypeScriptはアクセス修飾子（public, private, protected）を提供しており、クラス設計においてデータの隠蔽や適切なアクセス制御を実現できます。本記事では、TypeScriptにおけるアクセス修飾子の基本から応用まで、具体例を交えてそのベストプラクティスを解説していきます。
アクセス修飾子の基本
TypeScriptでは、クラス内のプロパティやメソッドに対するアクセスを制御するために、アクセス修飾子が用意されています。主なアクセス修飾子には、public、private、protectedの3つがあります。
public
publicはデフォルトのアクセス修飾子であり、クラスの外部からでも自由にアクセスできます。特に指定がない場合、プロパティやメソッドはすべてpublicとして扱われます。
class Person {
public name: string;
constructor(name: string) {
this.name = name;
}
}
const person = new Person("John");
console.log(person.name); // "John"private
privateは、そのクラスの内部でのみアクセス可能なメンバーを定義します。クラス外部からは直接アクセスできないため、データのカプセル化に役立ちます。
class Person {
private age: number;
constructor(age: number) {
this.age = age;
}
getAge(): number {
return this.age;
}
}
const person = new Person(30);
// console.log(person.age); // エラー: 'age'はprivateでアクセス不可
console.log(person.getAge()); // 30protected
protectedは、クラス自身とその派生クラス内でのみアクセス可能なメンバーを定義します。privateよりも柔軟性が高く、継承時に便利です。
class Person {
protected name: string;
constructor(name: string) {
this.name = name;
}
}
class Employee extends Person {
constructor(name: string, private employeeId: number) {
super(name);
}
getEmployeeInfo(): string {
return `${this.name}, ID: ${this.employeeId}`;
}
}
const employee = new Employee("Jane", 123);
console.log(employee.getEmployeeInfo()); // "Jane, ID: 123"
// console.log(employee.name); // エラー: 'name'はprotectedでアクセス不可これらのアクセス修飾子を使い分けることで、クラスの設計をより安全かつ柔軟に構築することができます。次項では、具体的な使い方やベストプラクティスをさらに深掘りしていきます。
`private`の活用方法
privateは、クラス内でのみアクセス可能なプロパティやメソッドを定義するために使用されます。外部からの直接的な変更やアクセスを制限することで、データの整合性を保ち、予期しない動作を防ぐ役割を果たします。
カプセル化によるデータ保護
privateを使用することで、クラス外部からの不正な操作を防ぐことができ、データのカプセル化を実現します。例えば、年齢やパスワードといった重要な情報をprivateで保護し、外部からのアクセスを制御します。
class User {
private password: string;
constructor(password: string) {
this.password = password;
}
changePassword(newPassword: string): void {
if (this.validatePassword(newPassword)) {
this.password = newPassword;
} else {
console.log("パスワードが強度基準を満たしていません");
}
}
private validatePassword(password: string): boolean {
// パスワード強度をチェックするロジック
return password.length >= 8;
}
}
const user = new User("initialPass123");
// user.password に直接アクセスできない
user.changePassword("newPass456"); // パスワード変更上記の例では、passwordプロパティがprivateとして定義されているため、クラス外部から直接アクセスすることができません。また、パスワードの強度を検証するvalidatePasswordメソッドもprivateとすることで、内部的なロジックの変更に対する柔軟性を高めています。
メソッドの内部処理を隠す
privateメソッドを利用すると、クラスの外部から不要な操作を隠蔽できます。例えば、ある処理が内部的に行われるが、ユーザーには見せたくない、もしくは使用されるべきではないメソッドをprivateとして定義することができます。
class BankAccount {
private balance: number;
constructor(initialBalance: number) {
this.balance = initialBalance;
}
deposit(amount: number): void {
this.balance += amount;
this.logTransaction("deposit", amount);
}
withdraw(amount: number): void {
if (amount <= this.balance) {
this.balance -= amount;
this.logTransaction("withdraw", amount);
} else {
console.log("残高不足です");
}
}
private logTransaction(type: string, amount: number): void {
console.log(`Transaction: ${type} - Amount: ${amount}`);
}
}
const account = new BankAccount(1000);
account.deposit(500); // 残高が増加し、トランザクションが記録される
// account.logTransaction("test", 100); // エラー: logTransactionはprivateここでは、logTransactionメソッドがprivateとして定義されており、外部から直接呼び出せません。このメソッドは内部的なトランザクション記録にのみ使用され、ユーザーに操作を許可する必要がないため、privateとして隠されています。
メリットと注意点
privateを適切に使うことで、以下のメリットがあります。
- クラス内でのみデータの変更が可能となり、バグの原因となる不正な操作を防止できる。
- 外部からの不必要な依存を排除し、クラスの安全性を高めることができる。
一方、過度にprivateを使用すると、クラスが他のコンポーネントと柔軟に連携できなくなる場合があるため、設計時にはバランスを考慮する必要があります。
次項では、継承時に役立つprotectedについて解説し、privateとの違いを見ていきます。
`protected`を使った継承のベストプラクティス
protectedは、クラス内およびその派生クラス内でアクセス可能な修飾子です。privateと似ていますが、異なる点は、protectedメンバーはサブクラスでもアクセスできるという点です。この特性を活かして、継承時に柔軟なアクセス制御を行うことができます。
`protected`の基本的な使い方
protectedは、親クラスの内部で保持しているデータやメソッドを、サブクラスが利用する必要がある場合に非常に役立ちます。これにより、データの完全なカプセル化を維持しながらも、サブクラスでの操作を許容できます。
class Animal {
protected name: string;
constructor(name: string) {
this.name = name;
}
protected makeSound(): void {
console.log(`${this.name}が音を出しています`);
}
}
class Dog extends Animal {
constructor(name: string) {
super(name);
}
bark(): void {
console.log(`${this.name}が吠えています`);
this.makeSound();
}
}
const dog = new Dog("ポチ");
dog.bark(); // "ポチが吠えています" "ポチが音を出しています"
// dog.makeSound(); // エラー: makeSoundはprotectedでアクセス不可この例では、nameプロパティとmakeSoundメソッドがprotectedとして定義されています。そのため、親クラスのAnimalから継承されたDogクラス内でそれらにアクセスできますが、クラスの外部からはアクセスできません。
継承を利用したコードの再利用
protectedを使うと、サブクラスで親クラスの機能を再利用しつつ、必要に応じて特定の動作を上書きしたり拡張したりすることが可能です。これは、オブジェクト指向設計におけるポリモーフィズムやコードの再利用に役立ちます。
class Employee {
protected employeeId: number;
protected name: string;
constructor(employeeId: number, name: string) {
this.employeeId = employeeId;
this.name = name;
}
protected getEmployeeInfo(): string {
return `ID: ${this.employeeId}, 名前: ${this.name}`;
}
}
class Manager extends Employee {
private department: string;
constructor(employeeId: number, name: string, department: string) {
super(employeeId, name);
this.department = department;
}
public getManagerInfo(): string {
return `${this.getEmployeeInfo()}, 部署: ${this.department}`;
}
}
const manager = new Manager(101, "田中", "営業");
console.log(manager.getManagerInfo()); // "ID: 101, 名前: 田中, 部署: 営業"
// console.log(manager.getEmployeeInfo()); // エラー: getEmployeeInfoはprotectedでアクセス不可上記の例では、EmployeeクラスのgetEmployeeInfoメソッドがprotectedとして定義されています。これにより、サブクラスManagerはこのメソッドを利用できますが、クラスの外部から直接呼び出すことはできません。このように、protectedを使うことで、親クラスの機能を安全に継承しつつ、サブクラスに柔軟なカスタマイズを加えることができます。
カプセル化を維持しつつ拡張性を確保
protectedは、カプセル化を完全に壊さずに、継承によってクラスの機能を拡張するのに適しています。例えば、特定のメソッドやプロパティは外部から直接アクセスさせず、サブクラスのみが操作できるようにしたい場合に有効です。
class Vehicle {
protected speed: number = 0;
protected accelerate(amount: number): void {
this.speed += amount;
}
public getCurrentSpeed(): number {
return this.speed;
}
}
class Car extends Vehicle {
public drive(): void {
this.accelerate(10);
console.log(`車が加速しました: 現在の速度は ${this.speed} km/h`);
}
}
const car = new Car();
car.drive(); // "車が加速しました: 現在の速度は 10 km/h"
// car.accelerate(10); // エラー: accelerateはprotectedでアクセス不可この例では、accelerateメソッドがprotectedとして定義されています。このため、クラスVehicleを継承したCarクラスでは呼び出せますが、クラスの外部からは直接呼び出すことができません。これにより、Vehicleクラス内での速度管理が保護され、サブクラスは安全に機能を拡張できます。
注意点: `protected`の使いすぎに注意
protectedは、継承時に便利ですが、使いすぎるとカプセル化が弱くなり、クラス設計が複雑化する恐れがあります。特に、親クラスの内部構造がサブクラスに過度に依存するようになると、クラスの再利用性が低下するリスクがあります。必要な場面にのみ使用し、設計の一貫性を保つことが重要です。
次項では、publicの使用における注意点とそのベストプラクティスを見ていきます。
`public`の使用における注意点
publicは、クラスのメンバーが外部から自由にアクセス可能であることを意味します。TypeScriptでは、明示的に指定しなくてもすべてのクラスメンバーはpublicとなるため、デフォルトのアクセス修飾子として非常に便利です。しかし、使用に際していくつかの注意点もあります。
デフォルトで公開される危険性
TypeScriptでは、明示的にアクセス修飾子を指定しない場合、すべてのプロパティやメソッドはpublicとして扱われます。このため、無意識に重要なデータやメソッドが外部からアクセス可能になってしまう可能性があります。
class User {
public name: string;
public age: number;
constructor(name: string, age: number) {
this.name = name;
this.age = age;
}
}
const user = new User("John", 30);
console.log(user.name); // "John"
console.log(user.age); // 30この例では、nameとageがpublicとして定義されています。これにより、クラスの外部から直接プロパティにアクセスでき、例えば誤ってデータを変更してしまうリスクがあります。
user.age = 35; // 外部から直接変更可能
console.log(user.age); // 35このような状況では、外部から意図しない変更が行われる可能性があるため、プロパティの保護や管理が難しくなります。特に、データの整合性を保ちたい場合にはpublicの使用に注意する必要があります。
データの保護とカプセル化の欠如
publicを多用すると、クラスのデータや内部ロジックが外部に露出し、カプセル化のメリットが失われます。クラスのデータは基本的に内部で管理されるべきであり、外部から直接アクセスできると予期しない動作が起こる可能性があります。
class BankAccount {
public balance: number;
constructor(initialBalance: number) {
this.balance = initialBalance;
}
public deposit(amount: number): void {
this.balance += amount;
}
public withdraw(amount: number): void {
if (amount <= this.balance) {
this.balance -= amount;
} else {
console.log("残高不足です");
}
}
}
const account = new BankAccount(1000);
account.balance = 5000; // 外部から残高が直接変更可能
console.log(account.balance); // 5000上記の例では、balanceがpublicとして定義されているため、外部から直接変更可能です。これにより、クラスのインターフェースを介さずにデータを改ざんできてしまい、カプセル化の原則に反しています。こうした事態を避けるためには、必要に応じてprivateやprotectedを使うべきです。
メソッドの公開と責任範囲の曖昧化
メソッドもpublicで公開する場合、外部のコードがそのメソッドに依存するようになります。これにより、将来的にそのメソッドを変更したり削除したりする際、外部コードに影響を与える可能性があります。クラスのインターフェースが大きくなると、責任範囲が不明確になり、コードが保守しづらくなります。
class Car {
public startEngine(): void {
console.log("エンジンを始動します");
}
public stopEngine(): void {
console.log("エンジンを停止します");
}
public drive(): void {
console.log("車を走らせます");
}
}
const car = new Car();
car.startEngine();
car.drive();
car.stopEngine();この例では、Carクラスが提供するすべてのメソッドがpublicで公開されていますが、特定のメソッドは内部でしか使われないはずです。例えば、エンジンの始動と停止はユーザーに明示的に操作させる必要がなく、クラス内部で管理すべきかもしれません。
ベストプラクティス: `public`を必要最低限にする
publicは、クラスのインターフェースを明確に定義するために使うべきであり、必要以上に公開するべきではありません。クラスが提供する最小限の機能のみをpublicとして定義し、内部ロジックはできる限りprivateやprotectedで保護するのが良い設計です。
class SafeCar {
private engineStarted: boolean = false;
public drive(): void {
if (!this.engineStarted) {
this.startEngine();
}
console.log("車を走らせます");
}
private startEngine(): void {
this.engineStarted = true;
console.log("エンジンを始動します");
}
private stopEngine(): void {
this.engineStarted = false;
console.log("エンジンを停止します");
}
}
const safeCar = new SafeCar();
safeCar.drive(); // "エンジンを始動します", "車を走らせます"
// safeCar.startEngine(); // エラー: startEngineはprivateこの例では、startEngineやstopEngineはprivateとして定義され、クラス外部からはアクセスできません。これにより、エンジンの始動と停止がクラスの内部で適切に管理され、ユーザーにはdriveメソッドだけが公開されます。
publicの使用は慎重に行い、必要最低限のメンバーのみを公開することで、クラスの安全性や保守性を高めることができます。次項では、クラス設計におけるアクセス修飾子の戦略的な活用について掘り下げて解説します。
クラス設計におけるアクセス修飾子の戦略的活用
オブジェクト指向設計において、アクセス修飾子はクラスの保護レベルを決定する重要な要素です。正しい修飾子を適切に使用することで、クラスのデータやロジックを守りながら、必要な部分だけを外部に公開することができます。ここでは、クラス設計においてアクセス修飾子をどのように戦略的に活用すべきかについて解説します。
公開する必要がある部分を明確にする
クラス設計において最初に考慮すべき点は、どのメソッドやプロパティを外部に公開し、どれを内部に閉じ込めるかです。通常、外部からアクセス可能な部分は最小限に抑えるべきです。これにより、クラスの利用者が不必要に内部構造に依存することを防げます。
class UserAccount {
private balance: number;
constructor(initialBalance: number) {
this.balance = initialBalance;
}
public deposit(amount: number): void {
if (amount > 0) {
this.balance += amount;
console.log(`預金: ${amount}`);
} else {
console.log("無効な金額です");
}
}
public getBalance(): number {
return this.balance;
}
private validateAmount(amount: number): boolean {
return amount > 0;
}
}
const account = new UserAccount(1000);
account.deposit(500); // "預金: 500"
console.log(account.getBalance()); // 1500
// account.validateAmount(100); // エラー: validateAmountはprivateこの例では、balanceプロパティとvalidateAmountメソッドはprivateに設定されており、クラスの外部からはアクセスできません。これにより、balanceの直接操作や金額の検証ロジックが外部から変更されることを防ぎます。一方で、depositやgetBalanceといった、外部から操作する必要があるメソッドはpublicとして公開されています。
必要に応じて`protected`を活用する
継承を考慮した設計では、protectedの使用が有効です。親クラス内のメンバーが、外部には隠しながらも、サブクラスで利用できるようにすることで、継承関係における柔軟性を保ちながら、クラスの安全性を確保します。
class Person {
protected name: string;
constructor(name: string) {
this.name = name;
}
protected displayName(): void {
console.log(`名前: ${this.name}`);
}
}
class Employee extends Person {
private employeeId: number;
constructor(name: string, employeeId: number) {
super(name);
this.employeeId = employeeId;
}
public showEmployeeDetails(): void {
this.displayName();
console.log(`社員ID: ${this.employeeId}`);
}
}
const employee = new Employee("田中", 1234);
employee.showEmployeeDetails();
// employee.displayName(); // エラー: displayNameはprotectedここでは、nameプロパティとdisplayNameメソッドがprotectedとして定義されています。これにより、親クラスのPersonから継承したEmployeeクラス内ではこれらにアクセス可能ですが、クラスの外部からはアクセスできません。こうした設計により、クラスの内部ロジックを保護しつつ、継承による機能拡張が可能になります。
アクセス修飾子を用いたモジュール化と責任の分離
アクセス修飾子を効果的に使用することは、クラス設計において「責任の分離」を実現するために重要です。責任の分離とは、各クラスが一つの明確な責務を持ち、それ以外の機能は他のクラスに委ねることです。これにより、クラスの機能が分かりやすくなり、変更に対する柔軟性が向上します。
例えば、データの保存や取得は、データベースアクセスクラスに委ねるべきであり、ビジネスロジックを管理するクラスで直接操作すべきではありません。こうした機能を分離する際に、privateやprotectedを活用して、クラス間の不要な依存関係を排除します。
class Database {
private records: { [key: string]: any } = {};
public save(key: string, value: any): void {
this.records[key] = value;
}
public get(key: string): any {
return this.records[key];
}
private logOperation(operation: string): void {
console.log(`Operation: ${operation}`);
}
}
class UserManager {
private db: Database;
constructor(db: Database) {
this.db = db;
}
public createUser(username: string, data: any): void {
this.db.save(username, data);
}
public getUser(username: string): any {
return this.db.get(username);
}
}
const db = new Database();
const userManager = new UserManager(db);
userManager.createUser("john", { age: 30 });
console.log(userManager.getUser("john")); // { age: 30 }この例では、Databaseクラスがデータの保存や取得の責任を持ち、その機能をUserManagerクラスが利用しています。DatabaseクラスのlogOperationメソッドはprivateとして定義され、内部でのみ使用されています。これにより、UserManagerはデータ操作の詳細を知らずに済み、データベースの実装が変更されてもUserManagerに影響を与えません。
ベストプラクティス: 最小限の公開、最大限の保護
クラス設計の際には、次のようなポイントを意識することが重要です。
publicは必要最小限にする: クラス外部に公開するメソッドやプロパティは最小限に抑え、外部からの不正なアクセスを防ぐ。privateで内部ロジックを保護: 直接操作されるべきでない内部のデータやメソッドはprivateで保護し、カプセル化を徹底する。- 継承が必要な場合は
protectedを活用: 継承を行う際、サブクラスで利用する必要があるメンバーはprotectedとして定義し、クラス間の柔軟性を確保する。
アクセス修飾子を適切に使用することで、クラスの安全性と拡張性を両立させた設計が可能になります。次項では、インターフェースとアクセス修飾子の関係について詳しく解説します。
インターフェースとアクセス修飾子の関係
TypeScriptにおいて、インターフェースはクラスの構造を定義するための強力なツールです。しかし、インターフェース自体にはアクセス修飾子を直接使用できません。インターフェースはクラスやオブジェクトの「契約」を定義し、外部から見えるべきプロパティやメソッドを明確にするためのものだからです。ここでは、インターフェースとアクセス修飾子の関係や、インターフェースを使った設計のポイントについて解説します。
インターフェースは`public`なメンバーの定義
インターフェース内で定義されたプロパティやメソッドは、すべてpublicとして扱われます。インターフェースは、クラスの外部に公開するべき構造を定義するため、privateやprotectedのようなアクセス修飾子を指定することはできません。
interface User {
name: string;
age: number;
greet(): void;
}
class Person implements User {
public name: string;
public age: number;
constructor(name: string, age: number) {
this.name = name;
this.age = age;
}
public greet(): void {
console.log(`こんにちは、${this.name}です`);
}
}
const user: User = new Person("太郎", 25);
user.greet(); // "こんにちは、太郎です"この例では、Userインターフェースがnameプロパティ、ageプロパティ、greetメソッドを定義しています。このインターフェースを実装するPersonクラスは、publicとしてインターフェースで定義されたメンバーを持つ必要があります。
インターフェースとアクセス修飾子の組み合わせ
インターフェースは、クラスの公開インターフェースを定義しますが、クラス内でインターフェースに含まれないプロパティやメソッドに対してはprivateやprotectedを使うことができます。これにより、クラスの内部ロジックを隠しながら、外部に必要な部分だけを公開できます。
interface User {
name: string;
greet(): void;
}
class Person implements User {
public name: string;
private age: number;
constructor(name: string, age: number) {
this.name = name;
this.age = age;
}
public greet(): void {
console.log(`こんにちは、${this.name}です`);
}
private getAge(): number {
return this.age;
}
}
const person = new Person("太郎", 25);
person.greet(); // "こんにちは、太郎です"
// person.getAge(); // エラー: getAgeはprivateこの例では、Userインターフェースはnameとgreetを定義していますが、Personクラスにはprivateとして定義されたageプロパティとgetAgeメソッドもあります。このように、インターフェースによって公開されるメンバーと、クラス内部に隠されたメンバーを分けることが可能です。
インターフェースを使った設計のベストプラクティス
インターフェースを使用する際には、クラスの公開インターフェースを明確にすることが重要です。これにより、外部からのアクセスを必要最低限に抑え、クラスの内部実装を隠蔽しつつ、必要な部分だけを公開できます。
- インターフェースは外部に公開すべき部分のみ定義
インターフェースは、外部からアクセス可能なpublicメンバーだけを定義します。これにより、クラス内部のロジックはカプセル化され、インターフェースに依存するコードが実装の詳細に依存しなくなります。 - 内部の実装は
privateやprotectedで保護
インターフェースに含まれないクラスの内部ロジックやデータは、privateやprotectedを使用して外部からアクセスできないようにします。これにより、クラスの内部構造を変更しても、外部の依存コードに影響を与えないようにできます。 - 必要に応じて複数のインターフェースを実装
クラスが複数の役割を持つ場合、異なるインターフェースを実装して役割ごとに公開するメンバーを制御できます。これにより、クラスが持つ異なる責任を明確に分離できます。
interface Flyable {
fly(): void;
}
interface Swimmable {
swim(): void;
}
class Bird implements Flyable, Swimmable {
public fly(): void {
console.log("鳥が飛んでいます");
}
public swim(): void {
console.log("鳥が泳いでいます");
}
}
const bird: Flyable & Swimmable = new Bird();
bird.fly(); // "鳥が飛んでいます"
bird.swim(); // "鳥が泳いでいます"この例では、FlyableとSwimmableという2つのインターフェースをBirdクラスが実装しています。それぞれのインターフェースによって、flyメソッドとswimメソッドがpublicとして定義され、外部からアクセス可能になっています。
インターフェースと抽象クラスの違い
インターフェースと抽象クラスは、どちらもクラスの設計をガイドするために使用されますが、それぞれの役割は異なります。インターフェースは純粋に構造を定義するのに対し、抽象クラスは部分的な実装を持ち、かつアクセス修飾子を使用してメンバーの可視性を制御できます。
abstract class Animal {
protected name: string;
constructor(name: string) {
this.name = name;
}
abstract makeSound(): void;
public getName(): string {
return this.name;
}
}
class Dog extends Animal {
constructor(name: string) {
super(name);
}
public makeSound(): void {
console.log(`${this.name}が吠えています`);
}
}
const dog = new Dog("ポチ");
dog.makeSound(); // "ポチが吠えています"この例では、Animalは抽象クラスとして定義されており、protectedなnameプロパティやpublicなgetNameメソッドを持っています。抽象クラスは部分的な実装を提供しつつ、アクセス修飾子を使ってクラスの可視性を制御できる点がインターフェースとの大きな違いです。
次項では、実際のコード例を基にカプセル化されたクラスの設計を詳しく解説します。
実装例: カプセル化されたクラスの設計
カプセル化はオブジェクト指向設計の重要な原則であり、クラスのデータや実装の詳細を外部から隠しつつ、必要なインターフェースだけを公開する手法です。ここでは、TypeScriptのアクセス修飾子を活用して、カプセル化を実現したクラスの設計例を紹介します。
カプセル化の基本: データの保護
カプセル化の主な目的は、データの保護と、クラス外部からの不正アクセスを防ぐことです。privateを使用することで、データやメソッドをクラスの内部に閉じ込め、直接アクセスさせないようにします。一方、外部から必要な操作を許可するメソッドはpublicとして公開します。
class BankAccount {
private balance: number;
constructor(initialBalance: number) {
this.balance = initialBalance;
}
public deposit(amount: number): void {
if (amount > 0) {
this.balance += amount;
console.log(`預金: ${amount}`);
} else {
console.log("無効な金額です");
}
}
public withdraw(amount: number): void {
if (amount > 0 && amount <= this.balance) {
this.balance -= amount;
console.log(`引き出し: ${amount}`);
} else {
console.log("残高不足または無効な金額です");
}
}
public getBalance(): number {
return this.balance;
}
private logTransaction(type: string, amount: number): void {
console.log(`取引記録: ${type} - 金額: ${amount}`);
}
}
const account = new BankAccount(1000);
account.deposit(500); // "預金: 500"
account.withdraw(300); // "引き出し: 300"
console.log(account.getBalance()); // 1200
// account.logTransaction("test", 100); // エラー: logTransactionはprivateこの例では、BankAccountクラスがカプセル化を実現しています。balanceプロパティはprivateとして定義され、クラスの外部から直接アクセスできません。外部からは、deposit、withdraw、getBalanceメソッドを介してのみ残高を操作できるようになっています。また、内部処理の一部であるlogTransactionメソッドはprivateとして定義され、クラス内部でのみ使用可能です。
カプセル化による堅牢なクラス設計
このようなカプセル化により、外部からの不正な操作やデータの改ざんを防ぎつつ、必要なインターフェースだけを外部に提供することが可能です。また、内部のロジックやデータ構造を変更しても、クラスの外部に影響を与えないため、柔軟なメンテナンスが可能です。
例えば、以下のように、残高操作の際に内部ロジックを追加しても、外部からの使用方法は変わりません。
class BankAccount {
private balance: number;
private transactionFee: number = 50;
constructor(initialBalance: number) {
this.balance = initialBalance;
}
public deposit(amount: number): void {
if (amount > 0) {
this.balance += amount;
this.applyTransactionFee();
console.log(`預金: ${amount}`);
} else {
console.log("無効な金額です");
}
}
public withdraw(amount: number): void {
if (amount > 0 && amount <= this.balance) {
this.balance -= amount;
this.applyTransactionFee();
console.log(`引き出し: ${amount}`);
} else {
console.log("残高不足または無効な金額です");
}
}
public getBalance(): number {
return this.balance;
}
private applyTransactionFee(): void {
this.balance -= this.transactionFee;
console.log(`取引手数料: ${this.transactionFee}`);
}
}
const account = new BankAccount(1000);
account.deposit(500); // "預金: 500", "取引手数料: 50"
account.withdraw(300); // "引き出し: 300", "取引手数料: 50"
console.log(account.getBalance()); // 1100ここでは、applyTransactionFeeという取引手数料を適用するprivateメソッドを追加しています。depositやwithdrawメソッドを呼び出すたびに手数料が適用されますが、この変更はクラス外部に影響を与えません。
アクセサメソッドを使った柔軟なデータ管理
TypeScriptでは、アクセサメソッド（getterとsetter）を使用して、プロパティの読み取りや書き込みをより細かく制御することができます。これにより、データの読み取り専用にしたり、値の検証を行うことが可能です。
class Person {
private _age: number;
constructor(age: number) {
this._age = age;
}
public get age(): number {
return this._age;
}
public set age(value: number) {
if (value >= 0) {
this._age = value;
} else {
console.log("年齢は0以上でなければなりません");
}
}
}
const person = new Person(30);
console.log(person.age); // 30
person.age = 35;
console.log(person.age); // 35
person.age = -5; // "年齢は0以上でなければなりません"この例では、ageプロパティは内部的には_ageとして保持され、getおよびsetメソッドを使って外部からアクセスされています。setメソッド内で年齢の値が0以上であることを検証することで、不正な値が設定されるのを防いでいます。
カプセル化の利点
カプセル化を適切に実装することで、次のような利点が得られます。
- データの保護: クラス外部から直接データを変更できないため、予期しないバグを防止できる。
- コードの柔軟性: 内部実装を変更しても、外部に影響を与えずにメンテナンスや拡張ができる。
- 責任の分離: クラスは自身の責務だけに集中し、外部に必要な機能のみを提供することで、コードの可読性や保守性が向上する。
次項では、継承を利用したリファクタリングの具体例について解説します。アクセス修飾子を活用しつつ、どのようにコードの再利用性を高めるかを学びます。
継承を利用したリファクタリングの実例
オブジェクト指向設計において、継承はコードの再利用性を高めるための強力な手法です。継承を活用することで、共通の機能を親クラスに集約し、派生クラスが必要に応じて特定の機能を拡張・上書きすることが可能になります。ここでは、TypeScriptでアクセス修飾子を使いながら、継承を活用したリファクタリングの実例を紹介します。
継承の基本概念とリファクタリング
継承を使用することで、複数のクラス間で共通するコードを一元化し、コードの重複を避けることができます。これは特に、大規模なプロジェクトでの保守性や拡張性を向上させるために重要です。
以下の例では、EmployeeとManagerという2つのクラスを持つコードが、共通のプロパティやメソッドを重複して実装している場合を示します。
class Employee {
public name: string;
public employeeId: number;
constructor(name: string, employeeId: number) {
this.name = name;
this.employeeId = employeeId;
}
public displayInfo(): void {
console.log(`名前: ${this.name}, 社員ID: ${this.employeeId}`);
}
}
class Manager {
public name: string;
public employeeId: number;
public department: string;
constructor(name: string, employeeId: number, department: string) {
this.name = name;
this.employeeId = employeeId;
this.department = department;
}
public displayInfo(): void {
console.log(`名前: ${this.name}, 社員ID: ${this.employeeId}, 部署: ${this.department}`);
}
}このコードでは、EmployeeとManagerの両方にnameとemployeeIdが重複しており、displayInfoメソッドも似たような実装がされています。このような場合、親クラスを導入して共通の機能を集約することで、コードを簡潔に保つことができます。
継承を使ったリファクタリングの実装
以下の例では、共通のプロパティとメソッドをPersonという親クラスに移し、EmployeeとManagerがその親クラスを継承する形にリファクタリングします。
class Person {
public name: string;
public employeeId: number;
constructor(name: string, employeeId: number) {
this.name = name;
this.employeeId = employeeId;
}
public displayInfo(): void {
console.log(`名前: ${this.name}, 社員ID: ${this.employeeId}`);
}
}
class Employee extends Person {
constructor(name: string, employeeId: number) {
super(name, employeeId);
}
}
class Manager extends Person {
public department: string;
constructor(name: string, employeeId: number, department: string) {
super(name, employeeId);
this.department = department;
}
public displayInfo(): void {
console.log(`名前: ${this.name}, 社員ID: ${this.employeeId}, 部署: ${this.department}`);
}
}
const employee = new Employee("佐藤", 101);
employee.displayInfo(); // "名前: 佐藤, 社員ID: 101"
const manager = new Manager("田中", 102, "営業");
manager.displayInfo(); // "名前: 田中, 社員ID: 102, 部署: 営業"このリファクタリングにより、nameやemployeeIdといった共通のプロパティをPersonクラスに集約し、EmployeeとManagerクラスがその親クラスを継承することで、コードの重複を解消しました。さらに、Managerクラスではdepartmentプロパティを追加し、displayInfoメソッドをオーバーライドして部署情報も表示できるようにしています。
`protected`を活用した親クラスのカスタマイズ
継承を利用する際、親クラスのメソッドやプロパティを派生クラスで自由に扱うために、protectedアクセス修飾子を使用することができます。protectedに設定されたメンバーは、クラス外部からはアクセスできませんが、派生クラス内では利用できます。
以下の例では、親クラスで定義されたメソッドを、派生クラスでさらにカスタマイズしています。
class Person {
protected name: string;
protected employeeId: number;
constructor(name: string, employeeId: number) {
this.name = name;
this.employeeId = employeeId;
}
protected displayBasicInfo(): void {
console.log(`名前: ${this.name}, 社員ID: ${this.employeeId}`);
}
}
class Manager extends Person {
private department: string;
constructor(name: string, employeeId: number, department: string) {
super(name, employeeId);
this.department = department;
}
public displayInfo(): void {
this.displayBasicInfo();
console.log(`部署: ${this.department}`);
}
}
const manager = new Manager("田中", 102, "営業");
manager.displayInfo(); // "名前: 田中, 社員ID: 102", "部署: 営業"この例では、PersonクラスのdisplayBasicInfoメソッドがprotectedとして定義されており、外部からは呼び出せません。しかし、Managerクラス内ではdisplayBasicInfoを呼び出すことができ、部署情報と合わせて出力しています。これにより、親クラスの機能を安全に活用しつつ、派生クラスでカスタマイズすることが可能です。
リファクタリングによる利点
継承を利用したリファクタリングには、次のような利点があります。
- コードの重複を削減: 共通のロジックを親クラスに集約することで、同じコードを繰り返し記述する必要がなくなり、メンテナンス性が向上します。
- コードの拡張性が向上: 派生クラスで親クラスのメソッドやプロパティをオーバーライドしたり、追加のロジックを実装したりすることで、柔軟に機能を拡張できます。
- 設計の明確化: 共通機能を親クラスにまとめることで、クラス間の責任が明確になり、設計が整理されます。
次項では、アクセス修飾子を活用して、クラスのユニットテストを効果的に行う方法について解説します。テスト可能なクラス設計のポイントを学びましょう。
アクセス修飾子を活用したユニットテスト
ユニットテストは、ソフトウェアの品質を保つために欠かせないプロセスです。TypeScriptでは、アクセス修飾子を活用しながらクラスを設計することで、テストのしやすさとクラスの安全性を両立させることが可能です。ここでは、アクセス修飾子を使ったクラス設計のテスト戦略や、ユニットテストでのベストプラクティスを紹介します。
公開メソッドをテストする
原則として、ユニットテストではpublicなメソッドやプロパティに対してテストを行います。クラスの外部に公開されているメソッドをテストすることで、クラスの正しい動作を確認します。
次の例では、BankAccountクラスのdepositとwithdrawメソッドをテストします。
class BankAccount {
private balance: number;
constructor(initialBalance: number) {
this.balance = initialBalance;
}
public deposit(amount: number): void {
if (amount > 0) {
this.balance += amount;
} else {
throw new Error("無効な金額です");
}
}
public withdraw(amount: number): void {
if (amount > 0 && amount <= this.balance) {
this.balance -= amount;
} else {
throw new Error("残高不足または無効な金額です");
}
}
public getBalance(): number {
return this.balance;
}
}このBankAccountクラスでは、depositとwithdrawメソッドがpublicとして定義されており、外部から操作できる部分です。これらをテストする際には、内部のbalanceプロパティには直接アクセスせず、getBalanceメソッドを利用して結果を確認します。
test('正しい金額が預金されるか', () => {
const account = new BankAccount(1000);
account.deposit(500);
expect(account.getBalance()).toBe(1500);
});
test('引き出し処理が正しく行われるか', () => {
const account = new BankAccount(1000);
account.withdraw(300);
expect(account.getBalance()).toBe(700);
});
test('残高不足の引き出しがエラーをスローするか', () => {
const account = new BankAccount(1000);
expect(() => account.withdraw(1500)).toThrow("残高不足または無効な金額です");
});このテストでは、deposit、withdraw、およびgetBalanceメソッドの動作を検証しています。直接balanceプロパティにアクセスすることなく、クラスのインターフェースを通じて動作が正しいかどうかを確認できます。
プライベートメソッドのテスト方法
原則として、privateメソッドはユニットテストで直接テストしません。privateメソッドはクラスの内部ロジックをカプセル化しており、外部に公開されるべきではないからです。代わりに、publicメソッドのテストを通じて間接的にprivateメソッドの動作を確認します。
以下の例では、privateなapplyTransactionFeeメソッドを含むBankAccountクラスをテストします。このメソッドは内部的にしか呼び出されないため、テストでは公開されているdepositとwithdrawメソッドを使って、手数料が正しく適用されているかを確認します。
class BankAccount {
private balance: number;
private transactionFee: number = 50;
constructor(initialBalance: number) {
this.balance = initialBalance;
}
public deposit(amount: number): void {
if (amount > 0) {
this.balance += amount;
this.applyTransactionFee();
} else {
throw new Error("無効な金額です");
}
}
public withdraw(amount: number): void {
if (amount > 0 && amount <= this.balance) {
this.balance -= amount;
this.applyTransactionFee();
} else {
throw new Error("残高不足または無効な金額です");
}
}
public getBalance(): number {
return this.balance;
}
private applyTransactionFee(): void {
this.balance -= this.transactionFee;
}
}この例では、applyTransactionFeeはprivateとして定義されていますが、depositやwithdrawメソッドを通じて手数料の処理が間接的に確認できます。
test('預金時に取引手数料が適用されるか', () => {
const account = new BankAccount(1000);
account.deposit(500);
expect(account.getBalance()).toBe(1450); // 500預金 - 50手数料
});
test('引き出し時に取引手数料が適用されるか', () => {
const account = new BankAccount(1000);
account.withdraw(300);
expect(account.getBalance()).toBe(650); // 300引き出し - 50手数料
});このように、privateメソッド自体を直接テストすることはせず、publicメソッドのテストを通じて、内部のprivateロジックが正しく機能しているかを検証します。
モックやスタブを使ったテスト
クラスの依存関係をテストする際には、モックやスタブを使用して、外部の依存関係をシミュレーションすることが効果的です。これにより、外部の影響を排除し、テスト対象のクラスにフォーカスしたテストが可能になります。
以下の例では、Databaseクラスをモックし、UserManagerクラスのテストを行います。
class Database {
save(key: string, value: any): void {
// データベースに保存する処理
}
get(key: string): any {
// データベースからデータを取得する処理
return {};
}
}
class UserManager {
private db: Database;
constructor(db: Database) {
this.db = db;
}
public createUser(username: string, data: any): void {
this.db.save(username, data);
}
public getUser(username: string): any {
return this.db.get(username);
}
}
// モックを使用したテスト
test('ユーザー作成時にデータベースに保存されるか', () => {
const mockDb = { save: jest.fn(), get: jest.fn() };
const userManager = new UserManager(mockDb as any);
userManager.createUser("john", { age: 30 });
expect(mockDb.save).toHaveBeenCalledWith("john", { age: 30 });
});このテストでは、Databaseクラスのsaveメソッドをモック化しており、実際にデータベースにアクセスせずにUserManagerクラスの動作を検証しています。これにより、外部の依存関係に影響されることなく、UserManagerクラスの動作にフォーカスしたテストが可能です。
テスト設計のベストプラクティス
ユニットテストを行う際のポイントは次の通りです。
publicメソッドのテストに集中: クラスの外部に公開されるインターフェースを通じてテストを行い、privateメソッドは間接的に確認する。- エラーハンドリングのテスト: 不正な値や条件に対して、クラスが適切にエラーをスローするかどうかもテストする。
- 依存関係をモック化する: 外部システムやデータベースのような依存関係はモックやスタブを使って置き換え、クラスの動作を単独で検証する。
次項では、アクセス修飾子の使用に関するよくある間違いとその回避方法について詳しく解説します。
よくある間違いとその回避方法
TypeScriptにおけるアクセス修飾子の使い方には、いくつかのよくある間違いがあります。これらの間違いは、コードの保守性やセキュリティ、可読性に悪影響を与えることがあります。ここでは、典型的なミスと、それを回避するための方法を解説します。
1. `public`の無意識な使用
TypeScriptでは、明示的にアクセス修飾子を指定しない場合、すべてのクラスメンバーはデフォルトでpublicになります。無意識にpublicを使ってしまうことで、本来外部に公開するべきでないメソッドやプロパティが外部からアクセス可能になってしまうことがあります。
間違いの例:
class User {
name: string; // デフォルトでpublic
age: number; // デフォルトでpublic
constructor(name: string, age: number) {
this.name = name;
this.age = age;
}
}
const user = new User("太郎", 30);
user.name = "次郎"; // 外部から直接変更可能回避方法:
明示的にアクセス修飾子を指定し、必要なメンバーのみを公開するようにしましょう。特に、外部から変更されるべきでないデータにはprivateやprotectedを使用します。
class User {
private name: string;
private age: number;
constructor(name: string, age: number) {
this.name = name;
this.age = age;
}
public getName(): string {
return this.name;
}
}2. `private`を使いすぎる
privateを多用してすべてのプロパティやメソッドを隠してしまうと、クラスの再利用性や拡張性が損なわれることがあります。特に、継承を考慮する場合には、サブクラスで必要なメンバーはprotectedにすることで、クラスの柔軟性を保つことが重要です。
間違いの例:
class Animal {
private name: string;
constructor(name: string) {
this.name = name;
}
private makeSound(): void {
console.log(`${this.name}が音を出しています`);
}
}
class Dog extends Animal {
bark(): void {
// 親クラスのnameやmakeSoundにアクセスできないため、機能拡張が難しい
}
}回避方法:privateとprotectedを使い分け、継承の必要性がある場合はprotectedを使って、サブクラスでもメンバーにアクセスできるようにします。
class Animal {
protected name: string;
constructor(name: string) {
this.name = name;
}
protected makeSound(): void {
console.log(`${this.name}が音を出しています`);
}
}
class Dog extends Animal {
bark(): void {
this.makeSound(); // サブクラスで親クラスのメソッドにアクセス可能
}
}3. プロパティの不正な公開によるデータ破損
publicプロパティを直接公開すると、外部から予期しない操作が行われ、データの整合性が崩れる可能性があります。例えば、クラスの外部からプロパティを直接変更されると、意図しない結果を引き起こすことがあります。
間違いの例:
class BankAccount {
public balance: number;
constructor(initialBalance: number) {
this.balance = initialBalance;
}
}
const account = new BankAccount(1000);
account.balance = -500; // 残高が負の値に変更されてしまう回避方法:
プロパティはprivateにし、getterやsetterメソッドを使って適切に制御することで、データの不整合を防ぎます。
class BankAccount {
private balance: number;
constructor(initialBalance: number) {
this.balance = initialBalance;
}
public getBalance(): number {
return this.balance;
}
public deposit(amount: number): void {
if (amount > 0) {
this.balance += amount;
}
}
public withdraw(amount: number): void {
if (amount > 0 && amount <= this.balance) {
this.balance -= amount;
}
}
}4. アクセス修飾子の指定忘れ
アクセス修飾子を指定しないことで、クラス設計の意図が不明確になり、他の開発者がクラスを使用する際に誤解を招くことがあります。
間違いの例:
class Car {
model: string; // デフォルトでpublic
speed: number;
constructor(model: string, speed: number) {
this.model = model;
this.speed = speed;
}
}回避方法:
クラスのメンバーには明示的にアクセス修飾子を指定し、どのメンバーが外部からアクセス可能か、どのメンバーが内部で保護されているかを明確にします。
class Car {
private model: string;
private speed: number;
constructor(model: string, speed: number) {
this.model = model;
this.speed = speed;
}
public getModel(): string {
return this.model;
}
public accelerate(): void {
this.speed += 10;
}
}5. 不要な`public`メソッドの多用
クラス内のすべてのメソッドをpublicとして公開すると、外部から不要な部分までアクセス可能になり、クラスの意図しない使い方をされる可能性があります。
間違いの例:
class Vehicle {
public startEngine(): void {
this.checkFuel();
console.log("エンジンが始動しました");
}
public checkFuel(): void {
console.log("燃料をチェックしています");
}
}回避方法:
本来外部から呼び出すべきでないメソッドはprivateまたはprotectedにし、外部に公開するインターフェースを最小限に抑えます。
class Vehicle {
public startEngine(): void {
this.checkFuel();
console.log("エンジンが始動しました");
}
private checkFuel(): void {
console.log("燃料をチェックしています");
}
}結論
アクセス修飾子の誤った使い方は、セキュリティやコードの保守性に悪影響を及ぼします。適切にpublic、private、protectedを使い分けることで、クラスの安全性と柔軟性を保ちながら、他の開発者にとっても理解しやすい設計を実現できます。
次項では、TypeScriptのアクセス修飾子を用いたオブジェクト指向設計全体を振り返り、まとめとして重要なポイントを再確認します。
まとめ
本記事では、TypeScriptにおけるアクセス修飾子を活用したオブジェクト指向設計のベストプラクティスについて詳しく解説しました。public、private、protectedの役割を理解し、適切に使い分けることで、データのカプセル化や継承によるコードの再利用性が向上します。また、テスト可能なクラス設計や、よくある間違いの回避方法についても学びました。
アクセス修飾子を効果的に使用することで、クラスの安全性を保ちつつ、柔軟でメンテナンスしやすいコードを書くことができます。
コメント