Можно ли здесь отказаться от интерфейса?

Question

[romaro]

Я бы хотел, чтобы свойство httpStatus присутствовало бы во всех реализациях абстрактного класса BasePageServ, но при этом не являлось бы его собственным свойством.

Сейчас я выделил интерфейс, но приходится совмещать extends и implements:

abstract class BasePageServ {
    constructor(public p: any) {};
    render() { return this.p };
}

interface IConcretePageServ extends BasePageServ{
    httpStatus: number;
}

class MainPageServ extends BasePageServ implements IConcretePageServ{
    httpStatus: number;
    constructor(public p: string) {
        super(p);
        this.httpStatus = 200;
    }
}

Интерфейс тоже наследуется от абстрактного класса, чтобы иметь возможность типизировать параметры функций, например:

function fn(page: IConcretePageServ) {
	return page.httpStatus
}

Я думаю о том, чтобы шаблонизировать подобные свойства в базовом классе и при необходимости перезаписывать их в дочерних:

class MainPageServ extends BasePageServ{
    override httpStatus: number;
    constructor(public p: string) {
        super(p);
        this.httpStatus = 200;
    }
}

Это позволило бы отказаться от интерфейса, хотя типизация параметров выглядела бы не так очевидно, ведь на самом деле page не является инстансом базового класса, а только наследуется от него:

function fn(page: BasePageServ) {
	return page.httpStatus
}

Какой из этих двух шаблонов лучше использовать? И, может быть, есть более удачный вариант?

Comments

[Lynn «Кофеман»]

Непонятен смысл. Чем вам httpStatus в базовом классе мешает?

[romaro]

Lynn «Кофеман», я создаю дочерние классы для хранения значений этих (и многих других) полей, которые относятся к объекту конкретной страницы. Мне кажется, что их объявление в абстрактном классе нарушает DRY, ведь я все равно получу доступ к этим полям при инстанцировании дочернего класса. Вообще, в данной архитектуре, абстрактный класс служит для реализации методов, а дочерние — для хранения состояний. Я уверен, что на этот счет есть паттерн ООН, но не могу его найти.

Можно задекларировать поля в абстрактном классе и вроде бы это не даст возможности объявить их в дочернем без указания правильного типа:

abstract class PageServ {
    declare public templateName: string;
    declare public httpStatus: number;
    constructor() {
    }

    get template(): string {
        return this.templateName + '.html';
    }
}

class MainPageServ extends PageServ{
    constructor() {
        super();
        this.templateName = 'MainPage';
        this.httpStatus = 200;
    }
}

const page = new MainPageServ;
console.log(page.httpStatus);

Но здесь есть проблема: тайпскрипт не выдаст ошибки, если я забуду реализовать указанные поля в дочернем классе.

[romaro]

Но здесь есть проблема: тайпскрипт не выдаст ошибки, если я забуду реализовать указанные поля в дочернем классе.

Тут вроде разобрался: методы и поля, которые должны быть реализованы в дочерних классах, следует объявлять абстрактными:

abstract class PageServ {
    abstract templateName: string;
    abstract httpStatus: number;
    constructor() {
    }

    get template(): string {
        return this.templateName + '.html';
    }
}