Блог

Главная - Вопросы по программированию - Реализация интерфейса I и расширение класса B, реализующего интерфейс J родителя I

Реализация интерфейса I и расширение класса B, реализующего интерфейс J родителя I

#java #oop #solid-principles #command-pattern

Вопрос:

У меня есть интерфейс для сущности игры IEntity , такой, что

 public interface IEntity {
    getATK();
    setATK();
    getDEF();
    setDEF();
}

Таким образом, я могу называть конструкторы команд игровых элементов, например, atkPotion(IEntity entity) без зависимости от какой-либо реализации (по крайней мере, именно поэтому я научился у SOLID DIP). Однако у меня также есть два общих типа сущностей (с эксклюзивными атрибутами), точно так же, как

 public interface IPlayer extends IEntity {
    setEXP();
    getEXP();
}
    
public interface IMonster extends IEntity {
    setElement();
    getElement();
}

это также интерфейсы для использования expPotion(IPlayer) , elementDungeon(IMonster) команды, а не сломанное ПОГРУЖЕНИЕ.

Проблема возникает , когда я хочу реализовать StdPlayer IPlayer и другой StdMonster из IMonster , но оба подхода имеют одинаковое поведение для getATK() , setATK() , getDEF() , setDEF() . Правильно ли делать общую реализацию StdEntity такой , которая StdPlayer расширяет StdEntity и реализует IPlayer , а StdMonster также расширяет StdEntity и реализует IMonster ? Или есть способ лучше подойти к этой проблеме?

Комментарии:

1. Как насчет ILivingEntity этого ? Он может разделять общие черты монстров и игроков, не уточняя IEntity их . Также нет никаких требований к конкретному StdEntity

2. То, что вы предлагаете, нормально. Но обратите внимание, что этот подход работает только с одним базовым классом … потому что Java позволяет классу расширять только один другой класс. (Альтернативы могут включать методы по умолчанию в интерфейсах … в зависимости от характера распространенных методов.)

3. Мой совет: попробуйте и убедитесь сами! ОО программированию лучше всего научиться, делая это,

4. В этом и заключается проблема с ТВЕРДЫМ ТЕЛОМ. Вместо разработки моделей, соответствующих требованиям их приложений, разработчики теперь разрабатывают модели, соответствующие принципам SOLID.

Метки: ,