Дополнительные открытые методы в производных классах?

В этом прелесть производных классов.

Хотя класс Pen может иметь функцию write (), класс RetractablePen, расширяющий Pen, также может иметь функцию retractPoint ().

Когда вы расширяете класс, это означает - буквально - расширение его функциональности.

Да, мы действительно используем его на Chess.com и в целом очень им довольны. Может возникнуть проблема с попыткой выяснить, как / где хранить все эти QFormStates, когда вы получаете более миллиона просмотров страниц в день. Каждое представление страницы - это собственный QFormState! Мы решили это, поместив их все в кэш памяти! У него действительно есть некоторая кривая обучения, но как только вы это узнаете, вам больше не понадобится документация. На самом деле я полностью отказался от использования QQ и использую все пользовательские sql в наших файлах ORM. QQ просто недостаточно мощен, чтобы выполнять сильно оптимизированные запросы, а точно настроенные запросы более важны, чем абстракция базы данных. В конце концов, сайт должен работать и быть быстрым. Вот один пример статического метода ORM в нашем классе User для загрузки случайного пользователя из базы данных (мы использовали его для отображения случайного "

В целом это нормально.

Чего вы хотите избежать, так это использования специфического в общем. т.е.

foreach(Animal a in myFarm.Animals)
{
    a.Feed();
    // this is a bit grim
    if( a is Horse )
    {
       ((Horse)a).CleanStable();
    }
}

Так что это не добавление общедоступных методов, а то, откуда вы их вызываете.

Нет, вполне разумно (а иногда и очень необходимо по замыслу) добавлять дополнительные общедоступные методы. Рассмотрим (полностью надуманную) ситуацию абстрактного базового класса Shape , который имеет член Location и метод Size . Например, когда вы производите Polygon из Shape , вы можете добавить общедоступный метод с именем GetNumberOfSides () ; но вы не хотите, чтобы это было, когда вы производите Circle из Shape .

Таким же образом производные типы могут иметь очень разные требования к построению; На самом деле невозможно знать, какие могут быть все требования при определении абстрактного базового класса, поэтому не стесняйтесь иметь разные подписи. Тот факт, что ваши dervied-типы будут полиморфными абстрактному базовому классу, не означает, что этот базовый класс налагает строгие ограничения на то, как вы можете реализовать абстракции, определенные в этом базовом классе; вы можете делать это, как хотите.

производные классы не должны предоставлять дополнительные общедоступные методы

Может ли собака делать то, что не может сделать животное?

Кроме того, допустимо ли иметь другую сигнатуру метода конструктора для каждого производного класса?

Здесь нет никаких проблем. Производные типы не обязаны соответствовать сигнатурам конструктора своих братьев и сестер или родителей.

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

public Square(double size)

, в то время как конструктор Rectangle будет

public Rectangle(double width, double height)

Что действительно должно произойти, так это то, что конструктор подкласса должен вызвать некоторый соответствующий конструктор суперкласса.

Что касается дополнительных общедоступных методов, это может зависеть от использования. Для случая Square я бы не стал добавлять никаких дополнительных методов. Однако в Java есть подкласс PrintWriter из Writer чья цель - добавить некоторые удобные методы. В этом случае я думаю, что это нормально (в Java конечно есть несколько плохих примеров, но я не думаю, что это один из них). Я также ожидал бы возможности некоторых дополнительных методов для типов контейнеров / подчастей.

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

Если вы соблюдаете принцип замены Лисков , вы можете делать все, что хотите.

Конечно, добавление метода к производному классу нисколько не нарушает принципа.