Как классифицировать транспортные средства - наследование против интерфейсов

Question

Я пытаюсь классифицировать транспортные средства, но я не уверен, что это лучший способ сделать это.

Почему я смущен? Если вы думаете об этом, транспортные средства могут быть разделены по категориям:

1) Тип транспортного средства: Land Vehicle, WaterCrafts & AirCrafts. 2) Другой способ категоризации: Приведенные в действие транспортные средства и немобильные транспортные средства, такие как Трактор (без питания и только что прикрепленный к грузовику), грузовик и т. Д. 3) Загрузка кузова: транспортное средство может быть загружено или нет.

Позвольте мне привести пример: Транспортное средство -> Транспортное средство -> Приводное/неэлектрическое -> Нагрузочное/NonLoadable.

Если вы видите, я создаю много подклассов, но какое использование этого, кроме различия свойств, является загружаемым или нет. Я могу это сделать и с помощью интерфейсов. Реализует интерфейсы Loadable® с питанием, которые позволяют загружать.

Например: автомобиля -> LandVehicle -> Трактор LandVehicle будет реализовывать интерфейсы, такие как isPowered и isLoadable, которые будут перекрываться трактора в качестве ложных и истинных соответственно.

Я знаю, что Наследование предназначено для отношений «isa» и интерфейсов для «может делать», но как это имеет здесь значение, потому что оно может использоваться взаимозаменяемо.

Каков наилучший способ решения таких проблем.

Answer 1

Лучший способ решить такого рода проблемы заключается в использовании ПОЦЕЛУЯ правило: Keep It Simple Глупо!

В этом случае используйте наследование для «основных» разделов в категоризации и используйте интерфейсы для «младших» разделов в категоризации. Это происходит потому, что Java позволяет только одного наследованию (основного разделения), но не ставит никаких ограничений на количестве интерфейсов (минорных подразделения) класс может реализовать.

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

public class Vehicle { 
    private List<VehicleDescription> descriptions = new ArrayList<VehicleDescription>(); 

    public void addDescription(VehicleDescription description) { 
     descriptions.add(description); 
    } 

    public boolean hasDescription(VehicleDescription description) { 
     return descriptions.indexOf(description) > -1; 
} 

public enum VehicleDescription { 
    Land, Water, Air, Powered, NonPowered, Loadable, NonLoadable 
} 

Вы можете добавить как много перечислений типа «Описание» перечисляют в вашем классе Vehicle, как вы хотите (чтобы вы могли не делать такие вещи, как быть загружаемыми & NonLoadable), и вам понадобится всего несколько классов!

Таким образом, используйте состав когда возможно.

Answer 2

Являются ли эти Vehicles отличаются возможностями или атрибуты?

1. Атрибуты: Используйте Builder_pattern строить различные типы транспортных средств с разными атрибутами.

2. Возможности: Используйте интерфейс для предоставления различных возможностей и определите Decorator, чтобы добавить возможности.

Если вам нужно смешивать обоих, использовать Builder + Decorator рисунок правильно.

Вы можете использовать Composite_pattern для списка возможностей в классе Vehicle. Vehicle класс будет поддерживать List <Capability>

Посмотрите на эти примеры:

Keeping builder in separate class (fluent interface)

When to Use the Decorator Pattern?

Answer 3

Состав соответствует лучше в вашем случае. Представьте, что ваши транспортные средства состоят из таких компонентов, как система зажигания, топливная система, трансмиссия, кабина и т. Д. Как вы можете видеть, многие типы имеют уникальные компоненты: 2, 3, 4 колеса, дорожки, hover/fwd, rwd, двигатель awd/топливная система) или электрическая (электрическая система). Наследование сделает вашу архитектуру очень ограниченной и трудно модифицировать.

С составом вам даже не нужно классифицировать свои транспортные средства. Просто добавьте к ним компоненты. Если вы хотите использовать фильтр для поиска автомобилей по параметрам, например количеству колес, типу привода - вы можете реализовать интерфейс ISearchable с помощью метода, который согласуется с критериями и выполняет поиск его компонентов автомобиля, независимо от того, соответствуют ли они всем критериям.