Проблема проектирования множественного наследования в Java

Предпочитайте композицию наследованию.

Решение принимает во внимание, что может быть другой тип слова, которому может потребоваться WordLengthSupport.

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

.

public class WordLength {
    private int length = 0;
    public int getLength(){return length};
    public void setLength(int length){this.length = length};
}

.

public interface WordLengthSupport {
    public WordLength getWordLength();
}

.

public class BetterWord extends AbstractWord 
        implements WordLengthSupport {
    WordLength wordLength;
    public WordLength getWordLength() {
        if(wordLength==null) {
            // each time word changes 
            // make sure to set wordLength to null
            calculateWordLength(); 
        }
        return wordLength;
    }
    private void calculateWordLength() {
        // This method should be 
        //    called in constructor 
        //    or each time word changes 
        int length = // based on the variable word calculate Length..
        this.wordLength = new WordLength();
        this.wordLength.setLength(length);
    }
}

.

public class BetterWordDescriptor extends AbstractWord  
        implements WordLengthSupport {
    WordLength wordLength;
    public WordLength getWordLength(return wordLength);
    public void setWordLength(WordLength wordLength) {
        // Use this to populate WordLength of respective word
        this.wordLength = wordLength;
    }
}

.

Шаблон стратегии определяет семейство алгоритмов, инкапсулирует каждый из них и делает их взаимозаменяемыми. Стратегия позволяет алгоритму изменяться независимо от клиентов, которые его используют.

В этом решении не используется шаблон стратегии, но его можно реорганизовать.

Просто используйте композицию вместо наследования:

a BetterWord является AbstractWord, который имеет Length:

public class BetterWord extends AbstractWord {

    private Length length;

    public void setLength(int value){
        length.setLength(value);
    }
}

ИЗМЕНИТЬ

Если API нужен объект типа Length, просто добавьте геттер:

public class BetterWord extends AbstractWord {

    private Length length;

    public void setLength(int value){
        length.setLength(value);
    }

    public Length getLength() {
        return length
    }
}

Или переименуйте реализацию Length в LengthImpl и определите интерфейс Length, поскольку класс может реализовывать несколько интерфейсов.

В вашем конкретном примере вы можете использовать шаблон декоратора в сочетании с интерфейсами, чтобы дополнить ваш Word класс дополнительный функционал; например

// *Optional* interface, useful if we wish to reference Words along with
// other classes that support the concept of "length".
public interface Length {
  int getLength();
}

// Decorator class that wraps another Word and provides additional
// functionality.  Could add any additional fields here too.
public class WordExt extends AbstractWord implements Length {
  private final Word word;

  public class(Word word) {
    this.word = word;
  }

  public int getLength() {
    return word.getKind().length();
  }
}

Кроме того, стоит отметить, что отсутствие множественного наследования в Java на самом деле не является проблемой; это скорее случай переработки вашего дизайна. В целом считается плохой практикой чрезмерное использование наследования, поскольку глубокие иерархии наследования трудно интерпретировать/поддерживать.

Глядя на это, первое, что я чувствую, это то, что ваша модель немного сложна.

У слова есть строка, описывающая само слово, которое хранится в объекте Word, а также класс, указывающий, что это существительное, глагол, прилагательное и т. д. Другое свойство слова — длина строки, хранящейся в объекте Word.

Подумайте о вещах с точки зрения отношений «есть-а» и «имеет-а», и вы сможете избавиться от многих сложностей.

Например, зачем вам WordDescriptor, расширяющий AbstractWord? Превратится ли слово из глагола в прилагательное? Я бы подумал, что тип слова был установлен при создании объекта и не изменится в течение всего времени существования объекта Word. Если у вас есть объект Word для слова «Австралия», вид слова не изменится в течение всего времени существования объекта.

Хм. Возможно, у вас может быть объект Word, представляющий слово «лай», после создания экземпляра объекта с типом «глагола» для описания звука, издаваемого собакой. Затем вы понимаете, что на самом деле вам нужно было иметь объект Word для представления существительного, описывающего покрытие дерева. Возможно, но может существовать и кора собаки, и кора дерева.

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

Начните с того, что задайте себе вопрос по каждому из аспектов наследования вашей базовой модели.

Когда я говорю, что класс B расширяет класс A, могу ли я сказать, что класс B «является» классом A и что я специализируюсь на его поведении?

Например, базовый класс Animal может быть расширен для предоставления специализированного класса Kangaroo. Тогда вы можете сказать, что «кенгуру» — это «Животное». Вы специализируетесь на поведении.

Затем посмотрите на атрибуты, у кенгуру есть атрибут местоположения, описывающий, где он находится. Тогда вы можете сказать, что кенгуру «имеет» местоположение. Расположение кенгуру «есть-а» не имеет смысла.

Точно так же слово «имеет» длину. И утверждение, что длина Word "is-a" просто не имеет смысла.

Кстати, все ссылки на Австралию в этом посте сделаны специально для празднования Дня Австралии, который отмечается сегодня, 26 января!

ХТН

(Я не могу просто добавить одно поле к другому из-за обратной совместимости, оно нарушает методы equals и тому подобное).

Это не нарушит совместимость источника. Нет, если вы не делаете что-то действительно сумасшедшее в своих методах equals.

И переименование ваших классов, как правило, не способ справиться с двоичной совместимостью.

Проблема не в том, «как поступить с одиночным наследованием». Чего вам не хватает, так это не шаблона проектирования, а обучения разработке API отдельно от реализации.

Я бы реализовал это так:

public interface WordDescriptor {
    void getKind();
    Word getWord();
}

public interface Word {
    String getWord();
}

public class SimpleWord implements Word {
    private String word;

    public SimpleWord(String word) { this.word = word; }
    public String getWord() { return word; }
}

public class SimpleWordDescriptor implements WordDescriptor {
    private Word word;
    private String kind;

    public SimpleWordDescriptor(Word word, String kind) {
        this.word = word;
        this.kind = kind; // even better if WordDescriptor can figure it out internally
    }

    public Word getWord() { return word; }

    public String getKind() { return kind; }
}

С этой базовой настройкой, когда вы хотите ввести свойство длины, все, что вам нужно сделать, это следующее:

public interface LengthDescriptor {
    int getLength();
}

public class BetterWordDescriptor extends SimpleWordDescriptor
                                  implements LengthDescriptor {
    public BetterWordDescriptor(Word word, String kind) {
        super(word, kind);
    }

    public int getLength() { getWord().length(); }        
}

Другие ответы, в которых используется композиция свойств, а также шаблон декоратора, также являются вполне допустимыми решениями вашей проблемы. Вам просто нужно определить, что представляют собой ваши объекты, насколько они «композитны» и как их следует использовать, поэтому сначала разработайте API.

/** * Первый пример */

class FieldsOfClassA {
    public int field1;
    public char field2;
}

interface IClassA {
    public FieldsOfClassA getFieldsA();
}

class CClassA implements IClassA {
    private FieldsOfClassA fields;

    @Override
    public FieldsOfClassA getFieldsA() {
        return fields;
    }
}

/**
 * seems ok for now
 * but let's inherit this sht
 */


class FieldsOfClassB {

    public int field3;
    public char field4;
}

interface IClassB extends IClassA {

    public FieldsOfClassA getFieldsA();
    public FieldsOfClassB getFieldsB();
}

class CClassB implements IClassB {

    private FieldsOfClassA fieldsA;
    private FieldsOfClassB fieldsB;

    @Override
    public FieldsOfClassA getFieldsA() {
        return fieldsA;
    }

    @Override
    public FieldsOfClassB getFieldsB() {
        return fieldsB;
    }
}

/**

• вау, этот монстр стал больше

• представь что тебе понадобится 4 лвл наследства

• столько времени ушло бы на то, чтобы написать этот ад

• Я даже не говорю, что пользователь этих айфейсов подумает

• какие поля мне понадобятся поляA поляB поляC или другое

Так что композиция здесь не работает и ваши жалкие попытки бесполезны

Когда вы думаете об объектно-ориентированном программировании

вам нужны БОЛЬШИЕ модели с 6-7 уровнями множественного наследования

потому что это хороший тест и потому что он соответствует моделям реальной жизни или математическим моделям, проверенным цивилизацией за 4 тысячи лет.

Если ваши модели требуют 2 уровня наследования, перестаньте притворяться, используя OO

Вы можете легко реализовать это на любом языке, даже на процедурном, таком как язык C или Basic */