Рефакторинг Ссылка / Ассоциация наследования

Question

Как реорганизовать / переписать ассоциацию в наследование в следующем примере.

Диаграмма UML описывает текущее рабочее состояние моей программы. Структура реального кода более сложна, поэтому, пожалуйста, извините за этот выдуманный пример.

Существует Маркет, который изначально содержит некоторые типы компьютеров в списке. Когда компьютер продан, новый объект SoldComputer создается и добавляется во второй список. Проданные компьютерные ссылки на тип компьютера. Процессор первого проданного компьютера может быть вызван:

soldComupter.ReferenceComputerType.CPU

Можно ли заменить ассоциацию наследованием? Удаление ReferenceComputerType и наследование SoldComputer от ComputerType. Вызов будет выглядеть так:

soldComupter.CPU

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

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

Answer 1

Если я правильно понимаю ваши рассуждения, ваш рынок продает SoldComputer, которые классифицируются в соответствии с общим ComputerType. Кроме того, ComputerType предварительно определяет некоторые характеристики всех компьютеров этого типа.

Композиция на наследство

Во-первых, Computer - это не ComputerType. Но, глядя на свойства этих классов, кажется, что мой аргумент касается только вопроса именования, потому что ваш ComputerType также может быть назван GenericComputer, в этом случае это будет менее шокирующим.

Но ваш ComputerType - это только малая часть проблемы. Потому что рано или поздно вы поймете, что у проданного компьютера также могут быть некоторые StorageType (например, HDD, 1To), а может быть, также некоторые GraphicType и многие другие настраиваемые параметры. А завтра у вас могут появиться компоненты нового типа, о которых вы даже не подозреваете (например, голографический проектор 2D / 3D), но которые принципиально не изменят способ описания и классификации SoldCompter.

Вот почему вы должны предпочесть состав над наследованием : вы можете иметь связь с другими типами компонентов. Большим преимуществом вашего нынешнего подхода является то, что если пользователь решает расширить ОЗУ своей SoldComputer, он / она может выбрать только соответствующий ComputerType, и все в порядке.

Если вы перейдете к наследованию, SoldComputer будет иметь CPU и memory: если пользователь изменит свое значение, это будет несовместимо с категоризацией. И, может быть, нет типа компьютера, соответствующего новой классификации ...

Альтернативный

Еще один способ взглянуть на проблему - это иметь класс Computer со всеми полями, которые технически описывают компьютер (например, процессор, память, диск и т. Д.):

• набор типов компьютеров на рынке будет заполнен Computer, но заполнены только некоторые соответствующие поля.
• набор проданных компьютеров на рынке будет заполнен Computer, у которого есть какой-то владелец.

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

В этом случае рынок больше не будет классифицироваться по типу компьютера. Поиск всегда будет динамическим (в конечном итоге инициализируется с использованием списка выбора прототипов.

Answer 2

Можно ли заменить ассоциацию наследованием?

Нет, это невозможно.

Как указал @ThomasKilian, «компьютер НЕ является типом компьютера», или, в более общем смысле, продукт НЕ является типом продукта .

Ваша модель кажется разумной.

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

Почему вы хотите использовать вместо этого наследование / подкласс?