Дополнительный интерфейс Java в иерархии классов

Question

Предположим, что у вас есть иерархия классов Java около 30 классов с базовым классом BaseClass и двумя основными подклассами (SubclassA, SubclassB) с несколькими подклассами каждый. Некоторые из этих подклассов имеют определенное поведение. Предположим, вы можете «вытолкнуть» их, изменив свое состояние. (Это новое требование добавление поведения к существующей иерархии. «Poke» не имеет смысла для большинства классов.)

interface Pokeable { 
    void poke(); 
    int getTimesPoked(); 
} 


public class Pokey extends SubclassB 
implements Pokeable { 
    private int timesPoked = 0; 
    public void poke() { 
    timesPoked++; 
    } 
    public int getTimesPoked() { 
    return timesPoked; 
    } 
} 

Если это будет сделано путем внедрения Pokeable только в тех классах, которые нуждаются в ней, а затем делать во всем коде, который должен вызывать любой объект, который подкачивается?

public void process(BaseClass b) { 
    if (b instanceof Pokeable) { 
    ((Pokeable)b).poke(); 
    } 
} 

Или должно быть реализовано всю иерархию. Подкачивается ради немногих, которые действительно являются Pokeable?

interface Pokeable { 
    void poke(); 
    int getTimesPoked(); 
    boolean isReallyPokeable(); 
} 

public class BaseClass implements Pokeable { 
    public void poke() {} 
    public int getTimesPoked() { return 0; } 
    public boolean isReallyPokeable() { return false;} 
} 

public class Pokey { 
    private int timesPoked = 0; 
    @Override 
    public void poke() { 
    timesPoked++; 
    } 
    @Override 
    public int getTimesPoked() { 
    return timesPoked; 
    } 
    @Override 
    public boolean isReallyPokeable() { 
    return true; 
    } 
} 

public void process(BaseClass b) { 
    b.poke(); 
} 

Редактировать добавлено: Это своего рода проблема с двойной отправкой. Если код «покер» что-то делает для объекта, он должен вызывать «poke()», если объект «подкачивается», но не может, если нет. Независимо от того, что вы «ткните()» или нет, зависит от того, хочет ли что-то совать и принимает ли объект за то, что он ткнул. Я мог бы использовать шаблон посетителя, но это, похоже, усложняет ситуацию.

Answer 1

Если класс не pokable, я бы не рекомендовал его реализации интерфейса Pokeable, просто потому, что это будет путать.

Возьмите один из следующих подходов.

• Создать абстрактный или конкретный подкласс BaseClass, который реализует Pokable, и есть все ваши к Pokeable подклассы Бе продлить. Этот подход хорошо работает, если poke() ing достигается по той же логике во всех реализующих классах.
• Пусть каждый подкласс реализовать Pokeable индивидуально

Answer 2

Ваши подклассы могут быть абстрактными, если вы не хотите внедрять все методы родительского класса. Но ....

Или должно быть реализовано всю иерархию. Подкачивается ради несколько, которые действительно являются Pikeable?

Определенно нет ... Классы, которые не подкачиваются, не должны выполнять подкачиваемый интерфейс.

Если это будет сделано путем внедрения Pokeable только в тех классах , что нужно, а затем, выполнив следующие действия во всем коде, который должен совать любой объект, который pokeable?

Это немного лучшая модель ... Однако это очень процедурный дизайн.

Может также содержать коллекцию <Pokeable>, где-то направляется в сторону, затем быстро перебирайте этот набор, чтобы высунуть их все?

Можете ли вы зарегистрировать классы подкастов в диспетчере событий? ... Итак, когда происходит определенное событие, все классы трясутся?

Answer 3

Я думаю, что метод, называемый «isReallyX», является предупреждающим знаком. Если кто-то взглянет на класс с первого взгляда и увидит, что он «Pikeable», он может попытаться высунуть его и в итоге неожиданно поступить, потому что это не действительно pokeable.

Я бы свой прежний подход у него не вводит в заблуждение внешних программистов (или себя после двух месяцев игнорируя этот код!)