Класс расширяет абстрактные классы. Интерфейс

Question

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

Вот мой пример: В этом случае будет модель для класса, содержащего информацию о деревьях.

Прежде всего я хотел бы сделать интерфейс:

public interface Tree{ 
    public void grow(); 
} 

Интерфейс содержит все методы, которые должны быть реализованы в конкретных деревьев. Пока что так хорошо, но для такого дерева нужны некоторые атрибуты (переменные), которые распределяются по всем семействам деревьев. Для этой цели я хотел бы использовать абстрактный класс:

public abstract class AbstractTree implements Tree { 
    private String barColor; 
    private int maxHeight; 
    private boolean isEvergreen; 
} 

Является ли это правильный путь, или я не в состоянии сделать вид договора о атрибуты (переменные), которые должны быть в других классах?

После того, как часть атрибута выполнена, я хотел бы иметь 3 типа деревьев.

• Дуб
• Maple
• Spruce

Таким образом, каждый из этих деревьев "tpyes" может иметь индивидуальные переменные.

public class OakTreeImpl extends AbstractTree{ 
    private String barColor; 
    private int maxHeight; 
    private boolean isEvergreen; 
    private String foo; 
    @Override 
    public void grow() { 
    } 
} 

Подходит ли этот подход к объектно-ориентированным принципам дизайна или я совершенно не согласен с ним?

Answer 1

Хотя это может быть частично субъективным, я должен согласиться с другими ответами, данными до сих пор.

Интерфейс пользователя TreeNOT устаревшее. Если вы хотите моделировать Tree, тогда должен быть интерфейс Tree, в котором четко указаны методы, которые есть у каждого Tree.

В частности, я рекомендовал бы просто заменить его классом AbstractTree. Некоторые люди говорят, что вы вряд ли должны использовать абстрактные классы вообще (например, Jaroslav Tulach in "Practical API Design"). Я бы хотя бы сказал, что вы должны использовать их очень консервативно. Самое главное: вы должны стараться избегать появления абстрактных классов в публичном интерфейсе других классов. Например, если у вас был еще один класс/интерфейс, с помощью метода, как

void makeGrow(Tree tree) { 
    System.out.println("Growing "+tree); 
    tree.grow(); 
} 

затем заменить этот вид Tree к AbstractTree уменьшится гибкость. Вы никогда не сможете использовать класс, который не наследует от AbstractTree - и учитывая, что вы можете наследовать только один класс, это может быть серьезным ограничением. (Вы всегда можете реализовать несколько интерфейсов - поэтому интерфейс не ограничивает здесь гибкость).

Но даже если вы используете абстрактный байт класс, я бы рекомендовал использовать поля protected консервативно. Или, в более общем плане, знать о последствиях наследования от класса, как описано в «Пункт 17 - Дизайн и документ для наследования или запретить его» от "Effective Java" by Joshua Bloch.

Во многих случаях вы не хотите, чтобы класс наследования имел полный доступ к полям. Поэтому вы должны хотя бы рассмотреть возможность создания полей private и предлагать только protected методы для доступа, которые вы хотите предоставить наследующим классам.

public interface Tree{ 
    public void grow(); 
} 

abstract class AbstractTree implements Tree { 

    // Do the values of these fields ever change? If not, 
    // then make them final, and set them only in the 
    // constructor 
    private final String barColor; 
    private final int maxHeight; 
    private final boolean evergreen; 

    protected AbstractTree(...) { ... } 

    // Subclasses are only allowed to read (but not write) these fields 
    protected final String getBarColor() { return barColor; } 
    protected final intgetMaxHeight() { return maxHeight; } 
    protected final boolean isEvergreen() { return evergreen; } 
} 

Answer 2

Я предпочел бы отмечать переменные экземпляра как protected.

Поскольку все защищенные члены суперкласса доступны для дочерних классов. Если и только если, родительские и дочерние классы в одном пакете

public abstract class AbstractTree implements Tree { 
    protected String barColor; 
    protected int maxHeight; 
    protected boolean isEvergreen; 
} 

public class OakTreeImpl extends AbstractTree{ 

    // I can access barColor, maxHeight, isEvergreen in this class 

    @Override 
    public void grow() { 

    } 
} 

Answer 3

Это работает, однако это не имеет особого смысла, поскольку интерфейс полностью устарел в этом случае.
Вы должны добавить метод вырасти до своего AbstractTree так:

public abstract class AbstractTree{ 
    protected String barColor; 
    protected int maxHeight; 
    protected boolean isEvergreen; 

    public abstract void grow(); 
} 

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

interface Plant{ 
    void grow(); 
} 

abstract class Tree implements Plant{ 
    void grow(){ /* do sth */ } 
} 

abstract class Flower implements Plant{ 
    void grow(){ /* do sth totally different */ 
} 

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