Почему иметь абстрактный подкласс конкретного класса плохой дизайн?

Question

Ведь ЛЮБОЙ java abstract является абстрактным подклассом Object.Иногда нам нужно заставить подкласс реализовывать некоторые методы, но уже может иметь довольно четко определенную иерархию с конкретными классами.

Например: у меня есть хорошо функционирующая иерархия с Транспортным средством <--- Автомобиль </p>

, и теперь я хочу добавить ElectricCar в эту иерархию.

vehicle <- Автомобиль<- ElectricCar.</p>

Я также хочу, чтобы на всех различных типах электромобилей реализовывалось определенное поведение, такое как getBatteryLife или что-то в этом роде.

Почему было бы плохой идеей делать ElectricCar абстрактным?

Answer 1

нет ничего плохого в том, чтобы сделать его абстрактным. если ваш бизнес требует от вас сделать его абстрактным, это нормально. Как вы сказали, многие классы в Java lib являются абстрактными и все еще расширяют Object.

Answer 2

Можно утверждать, что этот шаблон нарушает принцип замены Лискова , поскольку вы не можете передать "ElectricCar" везде, где ожидается "Автомобиль", если он объявлен абстрактным (конечно, вы можете передавать экземпляры подклассов ElectricCar).

В этом конкретном примере конкретные электрические автомобили (работающие на водороде / подключаемый модуль / и т. Д.) Я бы ожидал унаследовать напрямую от «автомобиля», поскольку они удовлетворяют отношениям «есть» и являютсяправильная специализация "Авто".Если вы хотите описать некоторые общие поведения и особенности, которые они должны предоставить, они также должны реализовать интерфейс ElectricCar .

. Кажется, что вы действительно хотите, это способность наследовать от Car (так какэто то, что они есть) и разделяют / повторно используют общие реализации методов, связанных с электромобилями.В этом случае вы смотрите на проблему множественного наследования или на необходимость mixins , ни одна из которых не поддерживается напрямую в Java.

Предоставление абстрактного класса в середине конкретной иерархии может быть одним из способов обойти это, но это не красиво.

Answer 3

Это неплохо, само по себе.Не часто, но не плохо.Единственное, о чем я могу думать, это понятность: если бы я увидел конкретный класс Car, который я мог бы создать, я бы обычно предполагал, что любой его потомок также был инстанцируемым, потому что 99% кода работает таким образом. Тогда я бы запуталсяна секунду о невозможности создать экземпляр ElectricCar.

Answer 4

В вашем примере я бы сказал, что предположительно класс Car также должен быть абстрактным (или интерфейсом). Но нет ничего плохого в том, что ElectricCar является абстрактным.

Answer 5

Лично я предпочел бы определить интерфейс для ElectricCar, а затем позволить классу реализации определять методы.Затем вы можете поделиться поведением getBatteryLife через другой механизм.

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