Abstract Classes

Topics: General, Language Specification
Jul 14, 2013 at 1:39 AM
This bug asked for support for abstract classes. The bug was dismissed as not being useful or lacking appropriate justification.

This feature is important for me. Without it, it's not possible to statically type check implementations of the Template Method pattern. Most of my projects (even the plain JavaScript ones) use this pattern.

Here is an example from some of my code. I have a TemplateView that implements the Backbone render method by rendering a template. TemplateView is abstract, and requires its subclasses to define a getTemplate method that returns the name of the template to use.
class TemplateView extends Backbone.View {
  render() {
    var template_name = this.getTemplate();
    return this;

  // the context to use for rendering the template
  toJSON() {
    return {};

  // the name of the template to use
  getTemplate() : string {
    throw new Error("You must implement getTemplate");

class MyView extends TemplateView {
  getTemplate() {
    return '#my-template';
I feel like the presence of the getTemplate method on subclasses of TemplateView should be statically checked.
abstract class TemplateView extends Backbone.View {
  abstract getTemplate() : string;
  // ...

// compile-time error
class MyView extends TemplateView {
  getTempalte() { // misspelled the method name
    return '#my-template';

// ok
class MyView extends TemplateView {
  getTemplate() {
    return '#my-template';

// also ok
abstract class LoggingTemplateView extends TemplateView {
  render() {
    console.log('rendering template');
    return super.render();
TypeScript is supposed to perform static type checking on JavaScript, and I think abstract classes are an important part of that. The throw new Error workaround defeats the purpose of type checking, by deferring a statically-detectable error to run time.
Jul 15, 2013 at 2:44 PM
I would very much like to see support for ABCs in TypeScript. Various comments have been made that abstract classes are not something that is idiomatic in Javascript, but Typescript is supposed to be a more "OO" way to end up with Javascript and abstract classes are very useful when doing object-oriented development. It saves us having lots of error checking done by throwing an exception when a base class method that shouldn't need defining is called (see previous change request and discussion).

Could we have them, please?
Aug 12, 2013 at 1:01 PM
I'd like to add another (not so obvious) reason for supporting abstract classes: refactoring.

If you have:
class Abc {
  frobnicate():void { throw "Abstract method"; }

class Concrete extends Abc {
  frobnicate():void { console.log ("splines completely reticulated"); }
and then you rename frobnicate() to reticulate() in the Concrete class, you get no compile-time error.

However, if the Abc would be abstract, you could not have tripped over this.

This is also an argument for supporting abstract for methods as it is for supporting override.
Aug 12, 2013 at 1:45 PM
This is useful for me as well. I have base classes that have no purpose by themselves and need to be derived from.
Aug 24, 2013 at 2:15 AM
This is just an indisputable feature as long as TypeScript goes to become true application-scale language. Along with strong support for library projects that will let us develop re-usable frameworks.
Oct 21, 2013 at 12:35 AM
mtebenev wrote:
This is just an indisputable feature
Agree 100% - any OOP language should have this feature.

Adding support for this should be fairly straight forward - all it needs to do is throw a compiler error if somebody attempts to create an instance of an abstract type.

Seems kind of absurd to reject that request.
Dec 10, 2013 at 3:13 PM
I'm giving this a +1. Having abstract classes / methods are essential when building large-scale applications. I'm now using the "throw" approach, and that works quite well, but it's messy.

Are there any good reasons why abstract classes / methods are NOT implemented?
Dec 13, 2013 at 8:37 AM
I must agree, unless this is really, really hard to do it should be part of the language - most important for me was the argument for refactoring.
Dec 13, 2013 at 12:39 PM
Edited Dec 13, 2013 at 2:08 PM
One reason abstract classes are not implemented may be because abstract classes can be considered an anti-pattern.
An abstract class is both an interface and a partial implementation. You should separate this into a dependency and an interface.
You can solve this by having good dependency injection.

Rather than:
abstract class A {
  abstract function implementMe() {}
  function foo() {
class B extends A {
  function implementMe() { console.log("o hai"); }
var b = new B();
You could instead have:
interface implementMe {
  function bar();
class A {
  private im;
  constructor(implementMe im) { this.im = im }
  function foo() { this.im.bar() }
class B implements implementMe {
  function implementMe() { console.log("o hai"); }
var a = new A(new B());
Class A is still an abstract class in the sense that it needs an implementMe to do its work but now the dependency is clear.

edit: in gavinwahl's example you can have a similar construction where TemplateView has a TemplateSupplier dependency which can be used in getTemplate.
Dec 13, 2013 at 3:42 PM
I think "function implementMe()..." should be "function bar()..." in your example...?
Dec 13, 2013 at 3:54 PM
Edited Dec 13, 2013 at 3:56 PM
I'm not sure I'd call it an "anti-pattern" either, though, really. That is an alternative way to implement the functionality, but if you are not careful you end up implementing multiple hierarchies using your technique, one for each type of behaviour you want to inject. These all add considerably to the complexity of the code (just compare the complexity of your two examples). [Note: I appreciate that dependency injection is a very powerful technique but it is often overkill for many straightforward hierarchies unless it is needed for some other purpose, such as testing, run-time config, etc.]

I find that a regular occurrence in code is a hierarchy of types, for whatever purpose, with a common interface, but which also often share some implementation between closely-related types. An abstract class, placed in-between the interface and the derived classes is often a very simple solution that avoids duplicated code between classes, or the alternative of lots of helper classes with delegating functions all over the place. C++, C#, Java, etc., all have (differing) support for abstract classes and they are widely used.

And the implementation of this feature is also not complex: a keyword to mark a class as abstract and a check on instantiation that the class is not abstract.
Dec 13, 2013 at 3:56 PM
Creating another object to use from another object doubles the number of objects - and it was the TypeScript team itself that frowned upon this for the private variables discussion,
Dec 13, 2013 at 4:03 PM
rb126 wrote:
"solution that avoids duplicated code between classes, or the alternative of lots of helper classes with delegating functions all over the place...
And the implementation of this feature is also not complex: a keyword to mark a class as abstract and a check on instantiation that the class is not abstract."
I totally agree. As an API developer myself, I routinely create "helper methods/functions" so users can just call the inherited method/function as needed. It makes it easier on end users since they don't have to implement EVERY method/function - only what they need, if any at all.

I also agree, this should be very simple to implement - a simple compiler error on implementing an abstract type on its own.
Feb 13 at 9:14 AM