This is an excerpt from my free and recently published on the TypeScript language, ( ). book programming Yet Another TypeScript Book https://www.gitbook.com/book/pagalvin/yet-another-typescript-book/details It’s from Here it is: chapter 9, “Classes in Depth.” Abstract Classes Abstract classes round out TypeScript’s support for hierarchies of this nature. An abstract class looks and feels like a standard class with a key exception: abstract classes may never be instantiated. If JavaScript is your first and primary programming language, this may seem strange. However, abstract classes, along with interfaces, enable developers to express many common software design patterns naturally and gracefully. Let’s consider an example. Imagine that you are a writing a game. Players place different types of military bases (e.g. “Army”, “Navy”) on a two dimensional map. Bases share some common features, like “name” but diverge from each other in important details. Army bases consist of soldiers while navy bases consist of ships. Lastly, at run-time, players can “activate” a base. This triggers the base to do something meaningful in the game. Here’s a naive way to model it: interface Activatable {    ActivateSelf: () => void;}

class NaiveBase {    private _myName: string;    public get Name() { return this._myName; }    constructor (name: string) {        this._myName = name;    }}

class NaiveArmyBase extends NaiveBase implements Activatable{    private _totalSolders: number;    public get TotalSolders() { return this._totalSolders; }

    constructor(name: string, totalSolders: number) {        super(name);        this._totalSolders = totalSolders;    }

    public ActivateSelf() {        throw "Not yet implemented";    }}

class NaiveNavyBase extends NaiveBase implements Activatable {    private _totalShips: number;    public get TotalShips() { return this._totalShips; }

    constructor(name: string, totalShips: number) {        super(name);        this._totalShips = totalShips;    }

    public ActivateSelf() {        throw "Not yet implemented";    }}

const naiveArmyBase = new NaiveArmyBase("First army base", 100);const naiveNavyBase = new NaiveNavyBase("First navy base", 3);

// This is allowed but makes no sense:const someOtherBase = new NaiveBase("what kind of base is this?"); By now, this is pretty straight-forward. A class holds a private property, and provides an get accessor to retrieve the value. Two other classes extend it and add their own properties: and . NaiveBase _myName NaiveArmyBase NaiveNavyBase Both the army an navy base classes implement the interface, albeit in this example, each class' method simply throws an exception. Activatable ActiveSelf() There is a problem with this modelling approach: there’s no such thing as plain vanilla NaiveBase. Players never create vanilla bases, they always create a specific kind of base. However, there’s nothing stopping the code from doing that. There’s another problem here as well. This approach forces us to implement the interface on every class. We could implement it on the base class, but that just compounds the first problem - now we've implemented an interface on a class we should never instantiate. Activatable Abstract classes solve this problem for us. Here’s the code re-written using an abstract class: interface Activatable {    ActivateSelf: () => void;}

abstract class AbstractBase implements Activatable{    private _myName: string;    public get Name() { return this._myName; }

    constructor (name: string) {        this._myName = name;    }

    abstract ActivateSelf(): void;}

class ArmyBase extends AbstractBase {    private _totalSolders: number;    public get TotalSolders() { return this._totalSolders; }

    constructor(name: string, totalSolders: number) {        super(name);        this._totalSolders = totalSolders;    }

    public ActivateSelf() {        throw "Not yet implemented";    }}

class NavyBase extends AbstractBase {    private _totalShips: number;    public get TotalShips() { return this._totalShips; }

    constructor(name: string, totalShips: number) {        super(name);        this._totalShips = totalShips;    }

    public ActivateSelf() {        throw "Not yet implemented";    }}

const armyBase = new ArmyBase("First army base", 100);const navyBase = new NavyBase("First navy base", 3);const anotherArmyBase: Activatable = new ArmyBase("Second army base", 250);

// Compiler throws an error - abstract classes can not be instantiated:const someOtherKindOfBase = new AbstractBase("what kind of base is this?"); This example introduces the keyword. We now have an abstract class, . This abstract class implements the interface. In doing so, you can see another characteristic of TypeScript's abstract functionality: you may mark classes and as abstract. (In fact, you must mark the class abstract if it contains any abstract members). The Activatable interface requires a method, . However, this method only makes sense for "real" bases - army and navy bases. Hence, we mark the ActivateSelf method itself as abstract: abstract Base Activatable class members ActiveSelf abstract ActivateSelf(): void; This abstract ActivateSelf method meets the requirements of the Activatable interface. This is perfect since a vanilla “base” can’t meaningfully activate itself — only army and navy bases can do that. At the same time, it forces subclasses to implement the method. This is good for two reasons: You can’t forget to do it since the IDE and compiler won’t let you. Since the subclasses implement the interface, we can write code that leverages their type as where and when we need to. Activatable The abstract Base class shows another feature: Abstract classes can define non-abstract class members. Since every base has a name, regardless of base type, it makes sense to define a concrete property and associated getter. Sub-classes inherit these concrete class members (properties and methods) just like they do with concrete classes. _myName The army and navy bases extend the abstract class just as if it were a concrete class using the same keyword. extends Wrapping up the example, you can see that newing up army and navy bases works the same way as it does in the naive example: const armyBase = new ArmyBase("First army base", 100);const navyBase = new NavyBase("First navy base", 3); Since both types of bases implement Activatable, you can do this: const anotherArmyBase: Activatable = new ArmyBase("Second army base", 250);const activatableNavyBase = <Activatable> navyBase; Let’s put it all together in a video:

Super

Too Long; Didn't Read

Get free API security automated scan in minutes

Abstract Classes in TypeScript: Text & Video

Too Long; Didn't Read

Company Mentioned

@pagalvin

RELATED STORIES