TypeScript で抽象クラスと抽象メンバを使って変更に強いコードを設計する

TypeScript にはabstractキーワードという機能があり、これを使うことで抽象クラスや抽象メンバを宣言することができる。
この機能を上手く使ってクラスを作ることで、可読性が高く、変更にも強いコードを設計できる。

abstractキーワードを使ったクラスやメンバの詳細な挙動については、以下の記事に書いた。

numb86-tech.hatenablog.com

本記事では、架空のオンラインショップの開発現場を通して、具体的にabstractをどう使えばよいのか、どのようなケースで役に立つのか、といったことを説明していく。

動作確認はv3.8.2で行っている。

間違った共通化

このオンラインショップは書籍の販売を行っており、商品である書籍はProductというクラスで表現している。

class Product {
  productCode: string;
  title: string;
  author: string;
  unitPrice: number;
  private static CONSUMPTION_TAX_RATE = 10;

  constructor(arg: Omit<Product, 'getTaxIncludedPrice'>) {
    this.productCode = arg.productCode;
    this.title = arg.title;
    this.author = arg.author;
    this.unitPrice = arg.unitPrice;
  }

  getTaxIncludedPrice() {
    return Math.floor(
      this.unitPrice * ((100 + Product.CONSUMPTION_TAX_RATE) / 100)
    );
  }
}

このように書くことで、全ての書籍に共通するメソッドであるgetTaxIncludedPriceを一箇所で定義すれば済むようになる。
このメソッドの内容を変更したり、新しく別のメソッドを追加したりする際も、Productクラスにだけ手を加えればよいことになる。
ちなみに、小数点以下の計算を正確に行うためには様々な注意点があるのだが、本記事の主題ではないので割愛し、今回は簡単な実装で済ませている。

このコードに特に問題はなく、正しく動く。

const productList = [
  new Product({
    productCode: '0001',
    title: 'Just for Fun',
    author: 'Linus Torvalds',
    unitPrice: 1500,
  }),
  new Product({
    productCode: '0002',
    title: 'Nineteen Eighty-Four',
    author: 'George Orwell',
    unitPrice: 1000,
  }),
];

productList.forEach(p => {
  console.log(p.getTaxIncludedPrice());
});
// 1650
// 1100

しかしビジネスモデルに変更があり、書籍以外の商材も扱うことになった。
まずは缶ビールや缶コーヒーなどの飲料の取り扱いを開始するが、他の商材も今後追加していく可能性があるらしい。

飲料にauthorやtitleが存在しないのは自明である。
一方で、アルコールかどうかで消費税率が変わるため、新たに、アルコールか否かを表現するデータを持つ必要がある。そしてその情報は、書籍には存在しない。
それぞれの商材にどのようなメンバが必要なのかを精査し、まとめたのが、以下の表である。

	書籍	飲料
productCode	◯	◯
unitPrice	◯	◯
getTaxIncludedPrice	◯	◯
title	◯	×
author	◯	×
name	×	◯
isAlcohol	×	◯

こうしてみると、共通するメンバがそれなりにある。そして今後も、全ての商品に共通する性質や機能を追加する可能性は、十分にある。また、書籍と飲料以外の商材の追加も検討中だ。
そう考えると、商材毎に完全に別々のクラスに分けてしまうのは、筋が悪そうである。
そこで、Productにtypeという属性を持たせて、Productが複数の商材を表現できるようにした。書籍の場合はtypeをbookに、飲料の場合はtypeをdrinkにする。
これなら、共通の処理を一箇所にまとめつつ、複数の商材を表現できるようになる。
そうして出来上がったProductクラスが、こちら。

class Product {
  type: 'book' | 'drink';
  productCode: string;
  unitPrice: number;
  title?: string;
  author?: string;
  name?: string;
  isAlcohol?: boolean;
  private static DEFAULT_CONSUMPTION_TAX_RATE = 10;
  private static REDUCED_CONSUMPTION_TAX_RATE = 8;

  constructor(arg: Omit<Product, 'getTaxIncludedPrice'>) {
    this.type = arg.type;
    this.productCode = arg.productCode;
    this.unitPrice = arg.unitPrice;
    if (arg.type === 'book') {
      this.title = arg.title;
      this.author = arg.author;
    }
    if (arg.type === 'drink') {
      this.name = arg.name;
      this.isAlcohol = arg.isAlcohol;
    }
  }

  getTaxIncludedPrice() {
    let taxRate;
    if (this.type === 'book') {
      taxRate = Product.DEFAULT_CONSUMPTION_TAX_RATE;
    }
    if (this.type === 'drink') {
      taxRate = this.isAlcohol
        ? Product.DEFAULT_CONSUMPTION_TAX_RATE
        : Product.REDUCED_CONSUMPTION_TAX_RATE;
    }
    if (!taxRate) throw new Error('taxRate is undefined.');
    return Math.floor(this.unitPrice * ((100 + taxRate) / 100));
  }
}

取り敢えず、動作に問題はない。
税込価格の計算ロジックも正しく動いている。飲料は軽減税率の対象だが、アルコールは対象外となる。

const someBook = new Product({
  type: 'book',
  productCode: '0001',
  unitPrice: 1500,
  title: 'Just for Fun',
  author: 'Linus Torvalds',
});
const coffee = new Product({
  type: 'drink',
  productCode: '1001',
  unitPrice: 200,
  name: 'Coffee',
  isAlcohol: false,
});
const beer = new Product({
  type: 'drink',
  productCode: '1002',
  unitPrice: 300,
  name: 'Beer',
  isAlcohol: true,
});

console.log(someBook.getTaxIncludedPrice()); // 1650
console.log(coffee.getTaxIncludedPrice()); // 216
console.log(beer.getTaxIncludedPrice()); // 330

しかしこのコードは、少なくとも 3 つの問題を抱えている。

まず、生成されたインスタンスがどのようなメンバを持つのかが、定かではない。
同じProductから生成されたインスタンスでも、どのようなメンバを持つのかは、生成時に渡した引数によって変化する。
そのため、実際に中身にアクセスするまで、そのメンバが存在するかどうか分からない。
型推論の結果もそうなる。

// const beer: Product
const beer = new Product({
  type: 'drink',
  productCode: '1002',
  unitPrice: 300,
  name: 'Beer',
  isAlcohol: true,
});

// const isAlcohol: boolean | undefined
const {isAlcohol} = beer;

isAlcoholはオプショナルなメンバであるため、存在するかもしれないし、undefinedかもしれない。
後からこのプロジェクトに参加した開発者は特に、挙動の把握に苦労することになる。
生成されたインスタンスがどのメンバを持っているのかは、Productのコードを読んで調べなければ分からない。

その際に、2 つめの問題が影響してくる。
単純に、Productの実装が複雑で、可読性が低いという問題。
Productというひとつのクラスで複数種の商材を表現するために、typeによる条件分岐が行われている。
この程度の規模ならまだよいかもしれないが、今後商材が増えれば、その度に、条件分岐は増えていくことになる。

最後の問題は、isAlcoholなどをオプショナルにしたことで、型システムの恩恵を受けられなくなってしまったこと。
例えば、飲料にはisAlcoholが必須なのだが、忘れてしまってもエラーにならない。

// isAlcohol を忘れているがエラーにならない
const highball = new Product({
  type: 'drink',
  productCode: '1003',
  unitPrice: 300,
  name: 'Highball',
});

// 軽減税率が適用されて 324 になってしまっているが、型システム上はエラーにならない
console.log(highball.getTaxIncludedPrice()); // 324

逆に不要な情報を渡しても、それもエラーにはならない。

const highball = new Product({
  type: 'drink',
  productCode: '1003',
  unitPrice: 300,
  name: 'Highball',
  author: 'someone', // エラーにならない
});

継承を使った共通化

こうなってしまった原因は、異なる商材をひとつのクラスにまとめてしまったことにある。

共通するものをまとめてしまおう、という考え方は、ある程度は正しい。
共通するメンバがいくつかあるから、ではなく、書籍と飲料は別々の商材ではあるが、どちらも同じ「商品」であるためだ。
全く別の存在ではなく、「性質が異なる 2 種類のProduct」と考えることができる。
「インターフェイスが似ているだけで意味としては異なるもの」をまとめてしまうのはアンチパターンだが、この記事の主題から逸れるので、今回はそれについては扱わない。

書籍と飲料のようなケースでは、継承を使うことで、綺麗に書ける。
もちろん継承が唯一の選択肢というわけではないのだが、仕様の全体像や今後の事業計画を総合的に考えた結果、今回は継承を使うことにした。

まず、Productを親クラスとして設計し直して、書籍と飲料に共通する性質や機能を書く。
そして子クラスとしてBookとDrinkを作り、商材毎に異なる性質や機能はそちらに書く。

この方針に基づいて、どのメンバをどのクラスに実装するか、検討した。

メンバ名	実装するクラス
productCode	Product
unitPrice	Product
title	Book
author	Book
name	Drink
isAlcohol	Drink
getTaxIncludedPrice	?

他のメンバは簡単だが、getTaxIncludedPriceが問題。
全ての商品が持っているべきメソッドなので、Productに書くべきかもしれない。だが、そのロジックは商材毎に微妙に異なる。
そこで、getTaxIncludedPriceは各商材に持たせ、ロジックの共通部分を抽出してそれをProductに書くようにした。

具体的には、Productの実装は以下のようになる。

class Product {
  productCode: string;
  unitPrice: number;
  protected static DEFAULT_CONSUMPTION_TAX_RATE = 10;
  protected static REDUCED_CONSUMPTION_TAX_RATE = 8;

  constructor(arg: Omit<Product, 'calculateTaxIncludedPrice'>) {
    this.productCode = arg.productCode;
    this.unitPrice = arg.unitPrice;
  }

  protected calculateTaxIncludedPrice(taxRate: number) {
    return Math.floor(this.unitPrice * ((100 + taxRate) / 100));
  }
}

商材毎に異なるのは消費税率の部分なので、その部分は、BookやDrinkに書く。そしてそれを使ったロジックの大部分についてはcalculateTaxIncludedPriceとしてProductに書く。
BookとDrinkはgetTaxIncludedPriceを実装し、そのなかでcalculateTaxIncludedPriceを呼び出して消費税率を渡す。

以下が、BookとDrinkの実装。

class Book extends Product {
  title: string;
  author: string;

  constructor(arg: Omit<Book, 'getTaxIncludedPrice'>) {
    const {productCode, unitPrice, title, author} = arg;
    super({productCode, unitPrice});
    this.title = title;
    this.author = author;
  }

  getTaxIncludedPrice() {
    return super.calculateTaxIncludedPrice(
      Product.DEFAULT_CONSUMPTION_TAX_RATE
    );
  }
}

class Drink extends Product {
  name: string;
  isAlcohol: boolean;

  constructor(arg: Omit<Drink, 'getTaxIncludedPrice'>) {
    const {productCode, unitPrice, name, isAlcohol} = arg;
    super({productCode, unitPrice});
    this.name = name;
    this.isAlcohol = isAlcohol;
  }

  getTaxIncludedPrice() {
    const taxRate = this.isAlcohol
      ? Product.DEFAULT_CONSUMPTION_TAX_RATE
      : Product.REDUCED_CONSUMPTION_TAX_RATE;
    return super.calculateTaxIncludedPrice(taxRate);
  }
}

処理の流れが理解しやすくなっており、動作も問題ない。

const someBook = new Book({
  productCode: '0001',
  unitPrice: 1500,
  title: 'Just for Fun',
  author: 'Linus Torvalds',
});
const coffee = new Drink({
  productCode: '1001',
  unitPrice: 200,
  name: 'Coffee',
  isAlcohol: false,
});
const beer = new Drink({
  productCode: '1002',
  unitPrice: 300,
  name: 'Beer',
  isAlcohol: true,
});

console.log(someBook.getTaxIncludedPrice()); // 1650
console.log(coffee.getTaxIncludedPrice()); // 216
console.log(beer.getTaxIncludedPrice()); // 330

生成されたインスタンスがどのようなメンバを持つのか、自明になった。
インスタンス生成時の引数によってメンバの有無が変化することはなく、同じクラスから生成されたインスタンスなら必ず同じメンバを持つ。
型推論も行われる。

// const beer: Drink
const beer = new Drink({
  productCode: '1002',
  unitPrice: 300,
  name: 'Beer',
  isAlcohol: true,
});

// const isAlcohol: boolean
const {isAlcohol} = beer;

インスタンス生成時の入力ミスも、TypeScript が検知してくれる。

// isAlcohol がないので Error
const beer = new Drink({
  productCode: '1002',
  unitPrice: 300,
  name: 'Beer',
});

const beer = new Drink({
  productCode: '1002',
  unitPrice: 300,
  name: 'Beer',
  isAlcohol: true,
  author: 'someone', // author を渡しているので Error
});

抽象クラスと具象クラス

新しく書き直されたProductは、全ての商品に共通する性質や機能をまとめたものであり、何か具体的な商品を表しているわけではない。非常に抽象的な存在である。
そのため、Productのインスタンスが作られることはない。Productは、それを継承した子クラスを作るためだけに存在すると言える。
このようなクラスのことを、抽象クラスという。
それに対して、抽象クラスを継承し、具体的な商品を表現するために作られたBookやDrinkのようなクラスを、具象クラスという。

そして TypeScript は、abstractキーワードを使って、抽象クラスであるということを明示的に宣言することができる。
abstractをつけたクラスは抽象クラスになり、インスタンスを作ろうとするとエラーになる。

abstract class Product {
  productCode: string;
  unitPrice: number;
  protected static DEFAULT_CONSUMPTION_TAX_RATE = 10;
  protected static REDUCED_CONSUMPTION_TAX_RATE = 8;

  constructor(arg: Omit<Product, 'calculateTaxIncludedPrice'>) {
    this.productCode = arg.productCode;
    this.unitPrice = arg.unitPrice;
  }

  protected calculateTaxIncludedPrice(taxRate: number) {
    return Math.floor(this.unitPrice * ((100 + taxRate) / 100));
  }
}

// Cannot create an instance of an abstract class.
const someProduct = new Product({
  productCode: '9001',
  unitPrice: 1000,
});

この機能によって、誤って抽象クラスのインスタンスを作ってしまうことを防止できる。

さらに、abstractキーワードをつけることで、コードがドキュメントとして機能するようになる。
このプロジェクトに新しく入った開発者でも、「Productは抽象クラスなんだな」ということをすぐに理解できる。

抽象メンバ

開発は順調に進んでいたが、またも仕様の追加が発生した。書籍と飲料の他に、カレンダーも扱うことになったという。

だが商材の追加は予想されていたことであり、だからこそProductクラスを作ったのだ。
Productを継承することで、商品として必ず持つべき振る舞いと、カレンダーに固有の振る舞い、その両方を持ったクラスを簡単に作れる。
継承を使うことで、カレンダーを表現するクラスにはカレンダーに固有の振る舞いだけを書けばよく、商品全般に関する振る舞いを改めて記述せずに済む。
カレンダーが独自に持つべき振る舞いは何なのかを検討した結果、当面は「何年のカレンダーか」が分かればよいということになった。
そこで、Productを継承し、独自にyearメンバを持つCalendarクラスを実装した。

class Calendar extends Product {
  year: number;

  constructor(arg: Omit<Calendar, 'getTaxIncludedPrice'>) {
    const {productCode, unitPrice, year} = arg;
    super({productCode, unitPrice});
    this.year = year;
  }
}

const calendar = new Calendar({
  productCode: '2001',
  unitPrice: 800,
  year: 2020,
});

console.log(calendar.year); // 2020

一見問題なく動いているが、CalendarにgetTaxIncludedPriceを忘れてしまっている。
しかしこのコードはエラーにはならない。
なぜなら、「Productを継承した具象クラスはgetTaxIncludedPriceを実装しなければならない」とは、どこにも定義されていないからだ。

この規模のコードなら、getTaxIncludedPriceの実装を忘れてしまう可能性は低いかもしれない。
だが、実装が不可欠なメンバの数が増えたり、たくさんの具象クラスを書くようになったりすれば、ミスをすることは十分にあり得る。

そもそも、「getTaxIncludedPriceが必須である」という情報は、開発者の頭のなかにしかない。これまでの開発の経緯を把握している開発者でないと、知り得ない情報だ。
getTaxIncludedPriceは全ての具象クラスが実装すべきものなのか、それともBookとDrinkに必要だっただけで必須ではないのか、現状の実装では判断がつかない。
整備された仕様書が存在すればよいが、そうでない場合、周囲の開発者に尋ねたり、コード全体の流れを追って調査したりしないといけない。

getTaxIncludedPriceは、抽象クラスであるProduct自体には実装しないが、Productを継承した具象クラスには必ず実装しないといけない。
このようなメンバを、抽象メンバという。
そして TypeScript では、抽象メンバの表現も可能になっている。
抽象メンバの表現にも、abstractキーワードを使う。

下記のgetTaxIncludedPriceは、「引数は受け取らず数値を返す抽象メンバ」として定義されている。
constructorの引数の型情報にgetTaxIncludedPriceを追記するのも忘れないようにする。

abstract class Product {
  productCode: string;
  unitPrice: number;
  protected static DEFAULT_CONSUMPTION_TAX_RATE = 10;
  protected static REDUCED_CONSUMPTION_TAX_RATE = 8;

  constructor(
    arg: Omit<Product, 'getTaxIncludedPrice' | 'calculateTaxIncludedPrice'>
  ) {
    this.productCode = arg.productCode;
    this.unitPrice = arg.unitPrice;
  }

  abstract getTaxIncludedPrice(): number;

  protected calculateTaxIncludedPrice(taxRate: number) {
    return Math.floor(this.unitPrice * ((100 + taxRate) / 100));
  }
}

これで、具象クラスにgetTaxIncludedPriceを実装することが必須となり、忘れたり、型が間違っていたりすると、エラーを出すようになった。

// Non-abstract class 'Calendar' does not implement inherited abstract member 'getTaxIncludedPrice' from class 'Product'.
class Calendar extends Product {
  year: number;

  constructor(arg: Omit<Calendar, 'getTaxIncludedPrice'>) {
    const {productCode, unitPrice, year} = arg;
    super({productCode, unitPrice});
    this.year = year;
  }
}

Productにabstractをつけたときと同様にドキュメントとしての効果もあり、Productの実装を見るだけで、具象クラスには必ずgetTaxIncludedPriceメンバを実装しないといけないということが分かる。

これで、Calendarの実装も無事に終わった。

class Calendar extends Product {
  year: number;

  constructor(arg: Omit<Calendar, 'getTaxIncludedPrice'>) {
    const {productCode, unitPrice, year} = arg;
    super({productCode, unitPrice});
    this.year = year;
  }

  getTaxIncludedPrice() {
    return super.calculateTaxIncludedPrice(
      Product.DEFAULT_CONSUMPTION_TAX_RATE
    );
  }
}

const calendar = new Calendar({
  productCode: '2001',
  unitPrice: 800,
  year: 2020,
});

console.log(calendar.getTaxIncludedPrice()); // 880

抽象クラスと具象クラスの役割分担を見極める

これで盤石と思われたが、getTaxIncludedPriceの仕様変更をキッカケに、この実装にはまだ改善の余地があることが発覚した。

getTaxIncludedPriceの引数として商品の個数を渡して、その個数における税込価格を返すことになった。
引数を渡さなかった場合は、これまで通り 1 個あたり税込価格を返す。
つまり、以下のように動作することが求められる。

const coffee = new Drink({
  productCode: '1001',
  unitPrice: 200,
  name: 'Coffee',
  isAlcohol: false,
});

console.log(coffee.getTaxIncludedPrice()); // 216
console.log(coffee.getTaxIncludedPrice(1)); // 216
console.log(coffee.getTaxIncludedPrice(2)); // 432

「getTaxIncludedPriceのインターフェイスが変わるときに何が起こるのか」をシンプルなコードで表現したくて、このような例にした。
getTaxIncludedPriceにこの機能をもたせることの是非は、今回は問わない。
だが、getTaxIncludedPriceに渡す引数が変わったり、返り値の構造が変わったりすることは、現実的に十分にあり得る。

変更自体は、大して難しくない。
getTaxIncludedPriceの引数としてquantityを受け取るようにして、そのデフォルト値を1にする。
そして、calculateTaxIncludedPriceの返り値にquantityを掛ければよい。

  // Drink の場合
  getTaxIncludedPrice(quantity = 1) {
    const taxRate = this.isAlcohol
      ? Product.DEFAULT_CONSUMPTION_TAX_RATE
      : Product.REDUCED_CONSUMPTION_TAX_RATE;
    return super.calculateTaxIncludedPrice(taxRate) * quantity;
  }

最後に、ProductでのgetTaxIncludedPriceの型定義にも、引数を追加しておく。

  abstract getTaxIncludedPrice(quantity?: number): number;

これで完了。複雑なことは何もない。
問題は、全ての具象クラスのgetTaxIncludedPriceを変更しなければならないことだ。
もっと具象クラスが増えていたタイミングで同様の変更が発生したら、具象クラスの数だけ手間が掛かる。変更の内容が複雑なものだった場合、相当な手間になってしまう。

getTaxIncludedPriceをそれぞれの具象クラスに実装してしまったために、このような状況になってしまった。
getTaxIncludedPriceの実装が一箇所にまとまっていれば、インターフェイスが変わることになっても、変更箇所は一箇所で済む。

getTaxIncludedPriceを抽象クラスではなく具象クラスに担当させたのは、設計ミスだった。
全ての商品に共通する振る舞いは抽象クラスに書く、という原則から考えても、Productに書くべきだ。
確かに、税率に関するロジックは商材毎に異なる。しかし、その異なる部分こそを具象クラスに切り出すべきであり、getTaxIncludedPrice自体はProductに持たせたほうがよい。

quantityオプションのことは一旦忘れ、getTaxIncludedPriceをProductに移す。
代わってconsumptionTaxRateという抽象メンバを用意して、それをgetTaxIncludedPriceの中から参照する。

abstract class Product {
  productCode: string;
  unitPrice: number;
  protected static DEFAULT_CONSUMPTION_TAX_RATE = 10;
  protected static REDUCED_CONSUMPTION_TAX_RATE = 8;

  abstract consumptionTaxRate: number;

  constructor(
    arg: Omit<Product, 'consumptionTaxRate' | 'getTaxIncludedPrice'>
  ) {
    this.productCode = arg.productCode;
    this.unitPrice = arg.unitPrice;
  }

  getTaxIncludedPrice() {
    return Math.floor(this.unitPrice * ((100 + this.consumptionTaxRate) / 100));
  }
}

class Drink extends Product {
  name: string;
  isAlcohol: boolean;
  consumptionTaxRate: number;

  constructor(arg: Omit<Drink, 'getTaxIncludedPrice' | 'consumptionTaxRate'>) {
    const {productCode, unitPrice, name, isAlcohol} = arg;
    super({productCode, unitPrice});
    this.name = name;
    this.isAlcohol = isAlcohol;
    this.consumptionTaxRate = this.isAlcohol
      ? Product.DEFAULT_CONSUMPTION_TAX_RATE
      : Product.REDUCED_CONSUMPTION_TAX_RATE;
  }
}

// Book と Calendar も同様に、consumptionTaxRate を実装し getTaxIncludedPrice を削除すればよい
// consumptionTaxRate は抽象メンバなので、実装し忘れても TypeScript がそのことを検知してくれる

これで、商材毎に異なる部分をconsumptionTaxRateとして具象クラスに切り出し、getTaxIncludedPriceそのものはProductに書くことができた。

これなら、getTaxIncludedPriceの仕様変更が発生しても、Productだけを編集すれば済む。

  // Product の getTaxIncludedPrice を書き換える
  getTaxIncludedPrice(quantity = 1) {
    return (
      Math.floor(this.unitPrice * ((100 + this.consumptionTaxRate) / 100)) *
      quantity
    );
  }

具象クラスの抽象クラスへの依存を避ける

先程の設計の見直しによって、getTaxIncludedPriceをProductに移した。
このメソッドは、具象クラスがconsumptionTaxRateメンバを持っていることを知っている。そしてこのメンバが各商品の消費税率を示していることも、知っている。
一方で具象クラス側は、抽象クラスがgetTaxIncludedPriceのなかでconsumptionTaxRateを使っていることを知らない。consumptionTaxRateが抽象クラスでどのように使われているのか、全く関知しない。

このように、具象クラスはできるだけ、抽象クラスに対する知識を持たないようにするのが望ましい。
抽象クラスがどのような実装になっているのか知るべきではない。

具象クラスが抽象クラスについて知っていればいるほど、依存関係が深くなる。そうなると、抽象クラスの変更の影響が、具象クラスにも波及しやすくなってしまう。
実は、まさにそのような状況になってしまっている箇所が既に存在する。それが、具象クラスのconstructorメソッドである。

例として、Bookのconstructorを見てみる。

  constructor(arg: Omit<Book, 'getTaxIncludedPrice' | 'consumptionTaxRate'>) {
    const {productCode, unitPrice, title, author} = arg;
    super({productCode, unitPrice});
    this.title = title;
    this.author = author;
    this.consumptionTaxRate = Product.DEFAULT_CONSUMPTION_TAX_RATE;
  }

superの箇所が問題である。
このコードは、親クラス、つまりProductのconstructorが{productCode, unitPrice}を受け取ることを知ってしまっている。Productの知識を持ってしまっている。
このせいで、Productのconstructorに変更が発生した場合、具象クラスもその影響を受けてしまう。

例えば、在庫数を表現するために、Productに新たにstockメンバを持たせることになったとする。

 abstract class Product {
   productCode: string;
   unitPrice: number;
+  stock: number;
   protected static DEFAULT_CONSUMPTION_TAX_RATE = 10;
   protected static REDUCED_CONSUMPTION_TAX_RATE = 8;


   ) {
     this.productCode = arg.productCode;
     this.unitPrice = arg.unitPrice;
+    this.stock = arg.stock;
   }

この変更によって、全ての具象クラスのconstructorでエラーが発生する。
superにはproductCode、unitPrice、stockの 3 つを渡すべきなのに、stockを渡していないからだ。
そのため、全ての具象クラスで以下の変更作業を行わなければならない。

   constructor(arg: Omit<Book, 'getTaxIncludedPrice' | 'consumptionTaxRate'>) {
-    const {productCode, unitPrice, title, author} = arg;
-    super({productCode, unitPrice});
+    const {productCode, unitPrice, stock, title, author} = arg;
+    super({productCode, unitPrice, stock});
     this.title = title;
     this.author = author;

これが、具象クラスが抽象クラスに依存することで生まれる弊害である。抽象クラスで変更が発生する度に、具象クラスもそれに振り回されてしまう。

この状況を改善し、依存を弱めたのが以下のコードである。
Bookを例にしたが、他の具象クラスも同じ要領で対応できる。

class Book extends Product {
  title: string;
  author: string;
  consumptionTaxRate: number;

  constructor(
    productProperty: Omit<
      Product,
      'consumptionTaxRate' | 'getTaxIncludedPrice'
    >,
    bookProperty: Omit<Book, keyof Product>
  ) {
    super(productProperty);
    this.title = bookProperty.title;
    this.author = bookProperty.author;
    this.consumptionTaxRate = Product.DEFAULT_CONSUMPTION_TAX_RATE;
  }
}

const book = new Book(
  {
    productCode: '0001',
    unitPrice: 1500,
  },
  {
    title: 'Just for Fun',
    author: 'Linus Torvalds',
  }
);

constructorの引数を 2 つに分け、第一引数で抽象クラス用のデータを、第二引数で具象クラス用のデータを受け取るようにした。
この設計の利点は、superにはproductPropertyをそのまま渡せばよく、その中身については関知せずに済むことだ。
そのため、先程のstockの例のように抽象クラスにメンバを増やしても、具象クラスには一切手を加えずに済む。

このように、具象クラスが抽象クラスの知識を持たないようにすることで、抽象クラスの変更の影響が具象クラスに波及しにくくなる。

まとめ

こうして、共通部分をProductクラスに共通化しつつ、変更にも強いクラスを設計できた。

全ての商品に共通する性質や機能を抽象クラスにまとめるようにしているため、stockのように全ての商品に対して新しくメンバを追加するようなケースでも、それを抽象クラスに追加するだけで対応できる。
そして適切に設計することで、抽象クラスを編集しても、その影響が具象クラスに波及することはない。getTaxIncludedPriceやstockの例で見た通りである。

逆に、具象クラスで変更が発生しても、その影響が抽象クラスや他の具象クラスに及ぶことはない。
例えば、Calendarクラスに、表紙のデザインに関する情報を持つためのcoverメンバを追加したとする。この変更の影響範囲はCalendarだけに留まり、Productクラスや他の具象クラスには影響しない。

TypeScript では、abstractキーワードを使うことで、抽象クラスや抽象メンバであることを明示的に宣言できる。そのため、抽象クラスと具象クラスを使った設計を JavaScript よりも行いやすいという利点がある。

今回説明した設計が常に正しいというわけでは勿論ないが、抽象クラスや抽象メンバの使い方や利点は、イメージできたと思う。

参考資料

この記事の内容は、『オブジェクト指向設計実践ガイド　～Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方』の第 6 章をベースにしている。

この書籍の概要は以下のリポジトリにまとめており、今回もこれを読み返して参考にした。

github.com

TypeScript でクラスを書くための初歩

TypeScript は、まだ ECMAScript に追加されていない提案段階の機能を積極的に先取りしている。
それはクラスも例外ではなく、例えば先日リリースされたv3.8では、現時点ではまだ提案段階であるプライベートフィールドが使えるようになった。
この記事では、TypeScript でのクラスの書き方の基本や、アクセス修飾子などの TypeScript 独自の機能、そしてプライベートフィールドのような最新の機能について、説明していく。

動作確認はv3.8.2で行った。

TypeScript ではインスタンスメンバの宣言が必須

以下は JavaScript と同じような感覚で書いたコードだが、これだとエラーになってしまう。

class MyClass {
  constructor(x: number) {
    this.x = x; // Property 'x' does not exist on type 'MyClass'.
  }
}

xなんてプロパティは存在しない、と言われてしまう。
以下のように、予め宣言しておく必要がある。

class MyClass {
  x: number;

  constructor(x: number) {
    this.x = x;
  }
}

宣言時に値を渡すこともできる。
ECMAScript ではこの書き方はまだできず、使いたい場合は Babel のプラグイン等で対応する必要があるが、TypeScript では既に利用できる。

class MyClass {
  x: number;
  y = 2;

  constructor(x: number) {
    this.x = x;
  }
}

const instance = new MyClass(1);
console.log(instance.x); // 1
console.log(instance.y); // 2

型推論が行われるので、yの型はnumberになる。

静的メンバと継承

静的メンバや継承については、TypeScript 特有のルール等はない。JavaScript と同じように書ける。

staticキーワードをつけたメンバは、インスタンスではなく、そのクラス自身のメンバになる。

class Product {
  constructor() {
    Product.count += 1;
  }

  static count = 0;
  static getProductCount = () => Product.count;
}

const foo = new Product();
const bar = new Product();
console.log(Product.getProductCount()); // 2
console.log(Object.getOwnPropertyNames(foo)); // []
console.log(Object.getOwnPropertyNames(Product)); // [ 'length', 'prototype', 'name', 'count', 'getProductCount' ]

継承も、特に変わったところはない。
プロトタイプチェーンを辿って、親クラスのプロトタイプメソッドを利用できる。

class Parent {
  showMessage() {
    console.log('This is super class method.');
  }
}

class Child extends Parent {}

const instance = new Child();
instance.showMessage(); // This is super class method.
console.log(Object.getOwnPropertyNames(Parent.prototype)); // [ 'constructor', 'showMessage' ]
console.log(Object.getOwnPropertyNames(Child.prototype)); // [ 'constructor' ]

これらの機能については、過去にブログに書いた。

numb86-tech.hatenablog.com

numb86-tech.hatenablog.com

クラスの型情報

クラスを定義すると、その名前の型が自動的に作られる。

// MyClass というクラスを定義したのと同時に、MyClass という型も定義される
class MyClass {
  x = 1;
}

注意しなければならないのは、上記のMyClass型が指しているのはMyClassのインスタンスの型であり、MyClassそのものではないということ。

class MyClass {
  x = 1;
}

const foo: MyClass = new MyClass(); // OK
const bar: MyClass = MyClass; // Error

型の前にtypeofキーワードをつけることで、クラス自身を表現するようになる。

class MyClass {
  x = 1;
}

const foo: MyClass = new MyClass(); // OK
const bar: typeof MyClass = MyClass; // OK

TypeScript は構造的部分型を採用しており、それはクラスでも変わらない。そのため、型に互換性があると判断されれば、実際にそのクラスやインスタンスである必要はない。

下記のMyClassはインスタンスメンバとしてxを、そして静的メンバとして、つまりクラス自身のメンバとして、yを定義している。
どちらも型推論の結果、number型となる。
そのため、number型のxというプロパティを持ったオブジェクトなら、MyClassのインスタンスと同じ構造になり、MyClass型と互換性があると判断される。

class MyClass {
  x = 1;
  static y = 2;
}

const foo: MyClass = {x: 9}; // OK

kyeofを使って型のプロパティ名を抽出してみると分かりやすい。

class MyClass {
  x = 1;
  static y = 2;
}

type Foo = keyof MyClass; // type Foo = "x"
type Bar = keyof typeof MyClass; // type Bar = "prototype" | "y"

abstract

abstractキーワードは TypeScript 独自の機能で、抽象クラスや抽象メンバを表現できる。

抽象クラスについての説明や、abstractの実践的な使い方などについては、別途記事を書いた。

numb86-tech.hatenablog.com

ここでは、abstractキーワードをつけたクラスやメンバがどのような挙動をするのかを、見ていく。

abstractをつけたクラスは抽象クラスとなり、インスタンスを作成しようとするとエラーになる。

abstract class Parent {}
class Child extends Parent {}

const foo = new Parent(); // Cannot create an instance of an abstract class.
const bar = new Child(); // OK

抽象クラス内のメンバにはabstractをつけることが可能で、そのメンバは抽象メンバとなる。
抽象メンバは子クラスで実装する必要があり、実装していない子クラスはエラーになる。

abstract class Parent {
  abstract x: number;
  abstract y: () => string;
}

// Non-abstract class 'A' does not implement inherited abstract member 'x' from class 'Parent'.
// Non-abstract class 'A' does not implement inherited abstract member 'y' from class 'Parent'.
class A extends Parent {}

// OK
class B extends Parent {
  x = 1;
  y = () => 'a';
}

?をつけても、それはあくまでもundefinedが許されるというだけであり、実装は必要。

abstract class Parent {
  abstract x: number;
  abstract y: () => string;
  abstract z?: () => boolean; // (property) Parent.z?: (() => boolean) | undefined
}

// Non-abstract class 'A' does not implement inherited abstract member 'z' from class 'Parent'.
class A extends Parent {
  x = 1;
  y = () => 'a';
}

// OK
class B extends Parent {
  x = 1;
  y = () => 'a';
  z = undefined;
}

子クラスが実装していれば、孫クラスは抽象メンバを実装しなくても問題ない。

abstract class Parent {
  abstract x: number;
}

// OK
class Child extends Parent {
  x = 1;
}

// OK
class GrandChild extends Child {}

もちろん実装してもよいが、その場合は型が一致している必要がある。

abstract class Parent {
  abstract x: number;
}

// OK
class Child extends Parent {
  x = 1;
}

// Property 'x' in type 'GrandChild' is not assignable to the same property in base type 'Child'.
//   Type 'string' is not assignable to type 'number'.
class GrandChild extends Child {
  x = 'a';
}

孫クラスが抽象メンバを実装しているが子クラスは実装していない、というケースでは、子クラスのみがエラーになる。

abstract class Parent {
  abstract x: number;
}

// Non-abstract class 'Child' does not implement inherited abstract member 'x' from class 'Parent'.
class Child extends Parent {}

// OK
class GrandChild extends Child {
  x = 1;
}

アクセス修飾子

アクセス修飾子という機能を使うと、メンバのアクセス可能範囲を制御することができる。

privateはそのクラス内でのみアクセス可能、protectedはそのクラスと子クラスからのみアクセス可能、publicはどこからでもアクセス可能、となる。
アクセス修飾子をつけていない場合は、publicになる。

class Parent {
  private foo: number;
  protected bar: number;
  public baz: number;
  qux: number;

  constructor(foo: number, bar: number, baz: number, qux: number) {
    this.foo = foo;
    this.bar = bar;
    this.baz = baz;
    this.qux = qux;
  }
}

class Child extends Parent {
  method() {
    console.log(super.foo); // Error
    console.log(super.bar); // OK
    console.log(super.baz); // OK
    console.log(super.qux); // OK
  }
}

const instance = new Parent(1, 2, 3, 4);
console.log(instance.foo); // Error
console.log(instance.bar); // Error
console.log(instance.baz); // OK
console.log(instance.qux); // OK

newでインスタンスを作成する際、constructorメソッドが実行される。
そのため、constructorをprotectedにすると、外部からconstructorにアクセスできなくなるため、外部でインスタンスを作成することは不可能になる。
protectedなので子クラスからはアクセスできるため、子クラスのconstructorでsuperを使って実行することはできる。

class Parent {
  x: number;
  protected constructor(x: number) {
    this.x = x;
  }
}

class Child extends Parent {
  constructor(x: number) {
    super(x);
  }
}

const foo = new Child(1);
console.log(foo.x); // 1

const bar = new Parent(1); // Constructor of class 'Parent' is protected and only accessible within the class declaration.

アクセス修飾子をconstructorの仮引数で使うと、メンバの宣言を省略できる。

class MyClass {
  constructor(public x: number) {
    this.x = x;
  }
}

const instance = new MyClass(1);
console.log(instance.x); // 1

さらに省略することもできる。

class MyClass {
  constructor(public x: number) {}
}

const instance = new MyClass(1);
console.log(instance.x); // 1

readonlyはその名の通り、メンバを読み取り専用にするための修飾子。

class MyClass {
  x: number;
  readonly y: number;
  constructor(x: number, y: number) {
    this.x = x;
    this.y = y;
  }
}

const instance = new MyClass(1, 2);
console.log(instance.x, instance.y); // 1 2
instance.x = 8; // OK
instance.y = 9; // Error

プライベートフィールド

プライベートフィールドは ECMAScript のプロポーザルで、今日時点での Stage は 3。
TypeScript はv3.8でこの機能を取り入れたので、既に使うことができる。

接頭辞として#をつけたメンバが、プライベートフィールドとして扱われる。
プライベートフィールドは、宣言したクラスのなかでのみ利用できる。

class MyClass {
  #x: number;
  constructor(x: number) {
    this.#x = x;
  }
  getX () {
    return this.#x;
  }
}

const instance = new MyClass(1);
console.log(instance.getX()); // 1
console.log(instance.#x); // Property '#x' is not accessible outside class 'MyClass' because it has a private identifier.

プライベートフィールドとクラスフィールドはそれぞれ別のメンバなので、名前が重複しても問題ない。

class MyClass {
  #x = 1;
  x = 2;
  getPrivateX () {
    return this.#x;
  }
  getPublicX () {
    return this.x;
  }
}

const instance = new MyClass();
console.log(instance.getPrivateX()); // 1
console.log(instance.getPublicX()); // 2
console.log(instance.x); // 2

プライベートフィールドと private 修飾子の違い

プライベートフィールドは、既に紹介したprivate修飾子と似ている。
どちらも、宣言したクラスの外からは利用できず、子クラスから利用することもできない。

だが差異もいくつかある。ここからは、両者の違いを見ていく。

Soft Private or Hard Private

Soft PrivateとHard Privateという概念がある。
以下の記事が分かりやすいが、端的に言えば、後者のほうがより厳密にアクセスが制限されている。
Private Class Field の導入に伴う JS の構文拡張 | blog.jxck.io

private修飾子はSoft Privateであるため、外部から存在を確認することができるし、外部からアクセスするための抜け道もある。
だがプライベートフィールドはHard Privateであり、外部から存在を確認することはできず、抜け道もない。

class MyClass {
  private soft = 1;
  #hard = 2;
}

const instance = new MyClass();
console.log(Object.getOwnPropertyNames(instance)); // [ 'soft' ]
console.log(instance['soft']); // 1

// Element implicitly has an 'any' type because expression of type '"#hard"' can't be used to index type 'MyClass'.
//   Property '#hard' does not exist on type 'MyClass'.
console.log(instance['#hard']);

private修飾子を使ったsoftはgetOwnPropertyNamesの一覧に出てくるし、ブラケット記法でアクセスすることもできてしまう。
だがプライベートフィールドを使ったhardは、外部からのアクセスが完全に遮断されている。

エラーを無視してトランスパイルした場合の挙動

privateなどのアクセス修飾子は、TypeScript 独自の機能である。トランスパイルする際に型情報などと同じように除去されるため、生成される JavaScript のコードには影響を及ぼさない。
そのため、エラーを無視してトランスパイルした場合、作られた JavaScript のコードは問題なく動く。

以下は外部からxにアクセスしようとしているためエラーになるが、@ts-ignoreでそのエラーを無視している。
このコードをトランスパイルした JavaScript ファイルを実行すると、エラーは出ず、1と表示される。

class MyClass {
  private x = 1;
}

const instance = new MyClass();
// @ts-ignore
console.log(instance.x);

だがプライベートフィールドは、ECMAScript のプロポーザルを先行して取り入れたものであり、TypeScript 独自の機能ではない。
その挙動はプロポーザルの内容に準拠している必要があり、TypeScript 上でのエラーさえ回避すればよい、というものではない。
そのため、エラーを無視してトランスパイルしても、壊れた JavaScript ファイルが生成されてしまう。

先程と同じように@ts-ignoreでエラーを無視して以下のコードをトランスパイルしてみる。

class MyClass {
  #x = 1;
}

const instance = new MyClass();
// @ts-ignore
console.log(instance.#x);

TypeScript はエラーを出さないのでトランスパイルは行われるが、生成されたファイルは壊れており、実行するとSyntaxErrorになる。

有効な target

プライベートフィールドは、tsconfig.jsonのtargetがES2015以上でないと利用できない。
例えばES5にしてみると、以下のコードはエラーになる。

class MyClass {
  #x = 1; // Private identifiers are only available when targeting ECMAScript 2015 and higher.
}

private修飾子の場合はtargetの制限はなく、例えばES3にしても以下のコードは動く。

class MyClass {
  private x = 1; // OK
}

参考資料

• Classes · TypeScript
• Announcing TypeScript 3.8 | TypeScript
• Private Class Field の導入に伴う JS の構文拡張 | blog.jxck.io