Принцип замены Лисков - никакие переопределяющие/виртуальные методы?

Методы переопределения подклассов в базовом классе полностью разрешены Принципом подстановки Лискова.

Это могло бы слишком упростить его, но я помню это как «подкласс должен требовать ничего больше и не обещать ничего меньшего »

Если клиент использует суперкласс ABC с методом something (int i) , то клиент должен иметь возможность заменить любой подкласс ABC без проблем. Вместо того чтобы думать об этом в терминах типов переменных, возможно, подумайте об этом в терминах предусловий и постусловий.

Если наш метод something () в базовом классе ABC выше имеет ослабленное предварительное условие, которое разрешает любое целое число, тогда все подклассы ABC должны также разрешать любое целое число. Подклассу GreenABC не разрешено добавлять дополнительное предварительное условие к методу something () , которое требует, чтобы параметр был положительным целым числом. Это нарушит принцип замены Лискова (т. Е. Потребует большего). Таким образом, если клиент использует подкласс BlueABC и передает отрицательные целые числа в something () , клиент не сломается, если нам нужно переключиться на GreenABC .

]Наоборот,

Нет, это говорит о том, что вы должны иметь возможность использовать производный класс так же, как его базовый. Есть много способов переопределить метод, не нарушая этого. Простой пример: GetHashCode () в C # лежит в основе ВСЕХ классов, и все же ВСЕ из них могут использоваться как «объект» для вычисления хэш-кода. Классическим примером нарушения правила, насколько я помню, является производное Square от Rectangle, поскольку Square не может иметь одновременно ширину и высоту - потому что установка одного изменит другое, и, таким образом, оно больше не соответствует правилам Rectangle. Однако вы все еще можете иметь базовую фигуру с помощью .GetSize (), поскольку ВСЕ фигуры могут это делать - и, таким образом, любая производная фигура может быть заменена и использована как фигура.

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

Однако, если вы смотрите на принцип с точки зрения клиента, то есть на метод, который принимает ссылку на базовый класс. Если этот метод не может определить (и, конечно, не пытается и не должен выяснять) класс любого переданного экземпляра, то вы также не нарушаете принцип. Поэтому может не иметь значения, что вы переопределяете метод базового класса (некоторые виды декораторов могут делать это, вызывая метод базового класса в процессе).

Если клиенту кажется, что ему нужно узнать класс переданного экземпляра , тогда вас ждет кошмар обслуживания, поскольку вам действительно следует просто добавлять новые классы как часть ваших усилий по обслуживанию, а не изменять существующую процедуру. (см. также OCP )