Объектно-ориентированный дизайн — как вложить один класс в другой класс

Вы должны добавить поле в свой класс Product, который является объектом класса ProductFamily. Добавив метод getProductFamily() в свой класс Product, вы можете вернуть семейства продуктов для конкретного продукта.

Это может быть так, если предположить, что между классами ProductFamily и Product существует отношение 1 к N:

class ProductFamily{

    private List<Product> products;

    //add all other members and getters and setters
}

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

 class ProductFamily{

    private List<Product> products;

    //add all other members and getters and setters

    public void addProduct(Product newProduct){
        this.products.add(newProduct);
    }
}

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

Если вы пришли из мира реляционных баз данных, у вас может быть четкое представление о нескольких взаимосвязанных концепциях, включая реляционные соединения, нормализацию данных, логическую независимость данных, самоописывающие данные, транзакции ACID и управление параллелизмом. Новичку трудно по-настоящему осознать силу и простоту каждой из этих концепций, не зная их всех. Хотите верьте, хотите нет, но специалистам по объектному моделированию нелегко понять каждую из этих концепций, просто сравнивая их с тем, что они уже знают.

То же самое происходит, когда вы впервые начинаете изучать объектное моделирование. Три взаимосвязанных понятия — это наследование, инкапсуляция и полиморфизм. Ни один из них не имеет большого смысла без некоторого понимания двух других. Все они работают вместе, чтобы создать мощную и простую систему.

Не поддавайтесь искушению рассматривать объектную модель как реляционную модель, только без некоторых функций. Это чрезмерное упрощение объектной модели. Правда в том, что каждая из этих парадигм моделирования была огромным шагом вперед в современном искусстве моделирования примерно сорок-пятьдесят лет назад. Каждый из них значительно упрощает размышления о существующих системах или предлагаемых системах, которые еще предстоит построить.

Но они не похожи друг на друга, и ни один из них не был производным от другого.

Если вы собираетесь начать с реляционного мышления, вот с чего начать. Решите, является ли отношение между Product и ProductFamily отношением HAS-A или отношением IS-A. Отношения HAS-A легко моделируются (реляционно) с использованием отдельных таблиц и внешних ключей. Что касается объектов, их лучше всего моделировать как отдельные классы со ссылкой из одного на другой. Отношения IS-A разные. Например, в зоомагазине могут быть кошки, собаки, птицы и змеи, но все они домашние животные. есть некоторые атрибуты или методы, которые относятся только к птицам или кошкам, но есть и другие, которые относятся ко всем им.

Ближайший аналог суперкласса/подкласса в реляционном моделировании находится не в реляционной модели, а в модели расширенных отношений сущностей. Здесь есть понятие, называемое Обобщение/Специализация. Кошка, собака, птица или змея — это специализация домашнего животного. Это отношения IS-A. Если обобщение/специализация имеет для вас смысл в данном случае, то подклассы и наследование сослужат вам хорошую службу. Если нет, то вам лучше не пытаться использовать здесь подклассы.

Здесь, в StackOverflow, есть буквально сотни вопросов, которые задают люди, привыкшие к объектному моделированию и желающие узнать, как реализовать отношения IS-A с таблицами SQL. Последний пример находится рядом с вашим вопросом и называется Расписание присоединения к нескольким столам. Для таких людей есть тег наследование таблицы классов. Им трудно понять, как реляционная модель может что-либо делать без концепции наследования. Ваша проблема в обратном. Как и когда использовать наследование, чтобы сделать жизнь проще, чем в реляционной схеме. И когда не использовать наследование.

Вам нужно решить, являются ли Product и ProductFamily тем случаем, когда полезно наследование. Опять же, если это отношение HAS-A, забудьте о подклассах и наследовании. Если это отношения IS-A, наследование является ключом к простому решению. Чтобы выполнять значимые операции над суперклассом, вам придется либо ограничиться операциями, значимыми для суперкласса, либо научиться создавать полиморфные операции. Этому нужно многому научиться, но в конце пути есть большая ценность.