Я понимаю, что вы здесь пытаетесь сделать, и у меня есть несколько предложений, но я не уверен на 100%, что вы сможете полностью достичь того, чего хотите. Посмотрим.

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

class Int implements NumBase {
  isInt = true

  constructor(public n: number) { }

  incr(): number {
    return this.n + 1;
  }
}

class Real implements NumBase {
  isInt = false

  constructor(public n: number) { }

  round(): number {
    return Math.round(this.n);
  }
}

type Num = Int | Real

function numFactory(n: number): Num {
  if (Math.round(n) === n) {
    return new Int(n);
  } else {
    return new Real(n);
  }
}

Теперь вы не можете вызвать неправильный метод для неправильного типа, компилятор не позволит вам предварительно распознать объединение, и вы можете вызвать фабрику со статически известной константой или динамическим значением из сетевого вызова и получить обратно правильный тип. А в вашем примере inxr вы довольно быстро получите ошибку компиляции, как только попытаетесь ее использовать (например, в модульном тесте).

Я также не уверен, что полностью понимаю суть класса LazyNum, придерживаясь этой темы, если у вас еще нет числа для передачи, вместо того, чтобы свойство n было потенциально неопределенным и «смешивало» два несовместимых типа, которые я просто отложил бы создание экземпляра класса и вызвал бы фабрику, когда все будет готово.

Я понимаю, что вы хотите скрыть лень за фасадом, но если вы это сделаете, у вас не будет возможности напечатать ее статически. Вы можете сделать так, чтобы защищенный _n был Num, и просто выбрасывать его во время выполнения, если вызывающий объект обращается к «неправильному» методу, по сути заставляя вызывающий объект проверять isInt. Для корректного вызова метода LazyNum можно просто делегировать его защищенному Num экземпляру, но вы не сможете заставить этот LazyNum класс работать каким-либо статически проверяемым способом, а объектно-ориентированный шаблон для обработки этого состоит в том, чтобы просто использовать фабрику. .

Полагаю, вопрос в том, какую часть вашего проекта вы готовы переработать, чтобы получить эти улучшения в типобезопасности? Вопрос, на который можете ответить только вы, но я изложил здесь подход, который вы можете использовать, если решите, что оно того стоит.

Редактировать

Учитывая комментарий jcalz: это позволяет вам в некоторой степени получить свой торт и съесть его, и это может быть лучшим подходом к тому, что вы хотите. Просто убедитесь, что логика в вашей защите пользовательского типа правильна, поскольку функционально это все еще является утверждением для компилятора (что, честно говоря, не делает его плохим).

На самом деле сделать это нелегко, особенно если isInt быть добытчиком. Если вы позволите isInt быть методом, вы можете получить то поведение, о котором говорите, но это довольно беспорядочно. Так:

class MyNum {

    n: number;
    isInt(): this is { __isInt: true } {
        return this.n % 1 === 0;
    }

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

    incr(this: { __isInt: true } & MyNum) {
        if (!this.isInt()) throw new Error(`incr() can only be called on integers`);
        return this.n + 1;
    }
    round(this: this extends { __isInt: true } ? never : MyNum) {
        if (this.isInt()) throw new Error(`round() can only be called on integers`);
        return Math.round(this.n);
    }
}

const n = new MyNum(123);
if (n.isInt()) {
    n.incr(); // okay
    n.round(); // error
} else {
    n.incr(); // error
    n.round(); // okay
}

Идея состоит в том, что isInt() — это метод защиты пользовательского типа, который делает вид, что isInt() возврат true добавляет к экземпляру фантомное __isInt свойство типа true.

Это не может работать, когда isInt() является геттером, поскольку геттеры не могут возвращать предикаты типа. По адресу microsoft/TypeScript#43368 есть открытый запрос на поддержку этой функции, но на данный момент это невозможно.

В любом случае, методы incr и round используют параметр this , чтобы проверить, есть ли в экземпляре свойство __isInt типа true. Если да, то incr() разрешено (поскольку this можно присвоить {__isInt: true}), а round() запрещено (поскольку this нельзя присвоить условному типу this extends { __isInt: true } ? never : MyNum). Если нет, то происходит обратный процесс.

Тип для round() более сложен, поскольку если isInt() возвращает false, то MyNum не сужается, и round() необходимо проверить наличие несуженного случая. Условный тип по сути выполняет эквивалент Exclude, так что если this было сужено, вы получаете never (что не удается), в противном случае вы получаете MyNum (что удается).

Это работает, но я не уверен, что рекомендую такой подход. Я бы рассмотрел это только в том случае, если бы вы не могли провести рефакторинг своего кода, исключив из одного класса с запрещенным поведением, основанным на состоянии... но если вы не можете провести рефакторинг, то isInt(), вероятно, нельзя будет превратить из геттера в метод. Но это, по крайней мере, близко к тому, о чем вы просите.

Детская площадка, ссылка на код