Мы все знаем, почему Java имеет/не должна иметь множественное наследование. Так что это не вопрос о том, что уже обсуждалось до тех пор, пока не вернется корова.Набор композиций для многослойных композиций с несколькими классами и котелкой
В этом обсуждается, что мы будем делать, когда хотим создать класс, который имеет характеристики двух или более других классов.
Возможно, большинство из нас сделало это, чтобы «наследовать» из трех классов. Для простоты, я вышел из конструктора .:
class Car
extends Vehicle
{
final public Transport transport;
final public Machine machine;
}
Так что, класс автомобиля непосредственно наследует методы и объекты класса Vehicle, но должен был бы обратиться к транспорту и машина явно ссылаться на объекты, экземпляры которых в области транспорта и машины ,
Car car = new Car();
car.drive(); // from Vehicle
car.transport.isAmphibious(); // from Transport
car.machine.getCO2Footprint(); // from Machine
Я думал, что это была хорошая идея, пока я не встречу фреймворки, которые требуют методов сеттера и геттера. Например, XML
<Car amphibious='false' footPrint='1000' model='Fordstatic999'/>
будет выглядеть для методов setAmphibious (..), setFootPrint (..) и setModel (..). Поэтому я должен проецировать методы из классов Transport and Machine
class Car
extends Vehicle
{
final public Transport transport;
final public Machine machine;
public void setAmphibious(boolean b){
this.transport.setAmphibious(b);
}
public void setFootPrint(String fp){
this.machine.setFootPrint(fp);
}
}
Это все в порядке, если бы было несколько характеристик. Прямо сейчас я пытаюсь адаптировать все SmartGWT к GWT UIBinder, особенно к тем классам, которые не являются виджетами GWT. Есть много характеристик для проекта.
Не было бы хорошо, если существует некоторая форма структуры аннотаций, которая, как это:
class Car
extends Vehicle
@projects {Transport @projects{Machine @projects Guzzler}}
{
/* No need to explicitly instantiate Transport, Machine or Guzzler */
....
}
Где, в случае общих имен характеристик существуют, характеристики машины бы старшинство Guzzler годов, и транспорт будет иметь приоритет над машинами, а у транспортных средств будет преобладание над транспортными средствами. Затем структура аннотаций создала экземпляр Transport, Machine и Guzzler в качестве скрытых элементов Car и расширилась, чтобы выявить защищенные/общедоступные характеристики в приоритете, продиктованном последовательностью аннотаций @project, в фактический исходный код или в байт-код. Предпочтительно в байтовый код. Чтобы метод setFootPrint был найден как в Machine, так и в Guzzler, будет проецироваться только модель Machine's.
Вопросы:
- Не кажется ли вам, что это хорошая идея, чтобы иметь такую структуру?
- Существует ли такая структура уже существует? Скажи мне, где/что.
- Есть ли плагин eclipse, который это делает?
- Есть ли предложение или план где-нибудь, что вы знаете о такой структуре аннотаций?
Было бы замечательно также, если рамка аннотации/плагина позволяет мне указать, что логическое, int или что-то еще нужно преобразовать из String, и для меня также выполняется преобразование/синтаксический анализ.
Пожалуйста, сообщите, кто-нибудь. Надеюсь, что формулировка моего вопроса была достаточно ясной. Спасибо.
Отредактировано: Чтобы избежать энтузиастов OO, переходящих к завершению, я переименовал название этого вопроса.
Не вопрос, а попытка начать обсуждение. Рассматривая это как вопрос, мои ответы: 1) Нет, 2) AFAIK No, 3) AFAIK No, 4) AFAIK No. –
Я бы не стал распространяться из одного из классов, а затем использовал композицию для других. Если вам нужен полиморпизм, сделайте три интерфейса и выполните три из них и возьмите класс Vehicle, сделайте его абстрактным (или нет) транспортным средством и используйте композицию, чтобы получить доступ к ее методам. Почему вы выбрали Vehicle вместо Machine или Transport для наследования? Таким образом, вы не можете сделать это Список list = new ArrayList (); list.add (new Car()) –
Lombo
Я бы подумал, что необходимость такой структуры - плохой дизайн. Может быть, вы используете фреймворк, который хотите адаптировать неправильно? Попытайтесь использовать больше интерфейсов :) – Janusz