抽象クラス
AbstractClass
抽象methdを1つ以上持つclassのこと
継承して使う
直接instantiateできない
エラーになる
全ての抽象methodをoverrideしないといけない
全てしなかったらエラーになる
抽象method以外はoverrideしないでいい #??
サブクラスでコンストラクタを記述しなければならない
多重継承はできない
言語に依るのでは #??
Interfaceとの差異
抽象クラスは、「継承されるclassの特殊版」と捉えると良さそう
Interfaceとはそもそもの意義が異なる
似てるっぽく解説しているものは、解説の順序が悪いと思う
似てるところから話すからそうなる
継承とInterfaceの存在意義から広げていけばそうはならないはず
この例はなんかわかった気になれた
抽象クラスという概念がなくても「継承される普通のクラス」というの元からあって、
これを、さらに「継承されるのが前提のクラス」と捉え、
「継承されるのが前提のクラスを前提」して抽象methodを実装することができる
と解釈すると良さそう
だから「アンチ継承」な思想で実装されているプロダクトでは、継承が存在しないので、そもそも抽象クラスは必要とされるわけがない
〇〇できる・できないで差異を説明するのおかしい
「それぞれの責務」みたいなので説明しないと、選択間違えるだろう
ということを踏まえた上でわざわざ比較をするなら
多重継承できるかどうかは異なる
Interfaceは多重継承できる
抽象クラスは多重継承できない
抽象classは抽象methodを1つ以上持つ
持たない、かつ、abstract classの場合は？
tsabstract class A {
baz() {
console.log("baz");
}
}別にエラーにはならないが、抽象クラスである理由が1つもなくなる
普通の親classとしてでええやん、という感じになる
抽象methodではない、普通のmethodも持つことはある
tsabstract class A {
abstract foo: string;
abstract bar(): string;
baz() {
console.log("baz");
}
}抽象method
実装を持たず、名前と引数、戻り値の型が決まっているmethod
tsabstract class A {
abstract bar(): string;
}普通のmethod
抽象class内の、普通のmethodの話
普通のclass内の、普通のmethodと同等のものである
抽象methodと異なり、実装は書かないといけない
このmethodの内部で、抽象methodを書くこともある ref
複雑ダナー
overrideしてもしなくてもいい
memo
この説明だと、「新しいclassを作る際のtemplate」としての存在に見えるな
メソッド名を統一し、ロジックを共通化し、大体何の処理をしているか把握しやすくなる
共通の処理をいちいち全てのクラスに書き込む必要がなくなり、個別の処理も追加しやすくもなる
開発者がサブクラスを定義した際に、メソッドの実装忘れやメソッド名に間違いがあればコンパイルエラーが起き、コーディングミスを防ぐ
Interfaceとはかなり目的が異なる
プロダクトがかなり大きく、複数人開発であることが前提にある用に見える
1人ならルールは自分で決められるので、名前のブレなどはあまりお消えないので。
でもそれなら「この場合にはこの抽象クラスを継承してclassを作れ」というルールを共有しないといけないが？
これが正しいのかどうかはわからん
そもそもの「継承」がこのために利用されるものなのであればたぶん正しいんだろう
普通の継承とは何が違う？
抽象クラスと全く同じことを普通のclassを作って、継承させることもできるよね？
なんでわざわざ抽象クラスとして表現する？
抽象methodに、実装がないことが重要だから？
この視点で見れば、普通のclassのoverrideされるべきmethodは、抽象methodのdefault実装として見れるね
抽象クラスとすることで「継承することが前提」というのを明示するのが重要だから？