Превосходная композиция с внутренним экземпляром объекта

Question

Я играю с композицией и задал вопрос. Скажем, у меня есть Fruit и Apple классов, где apple является Проходным к плоду

public class Apple { 
    Fruit fruit; 
} 

Fruit имеет кучу полех членов, как skin, color и т.д. Что является лучшей практикой, когда мы экземпляр Apple объекта? Должен ли я построить объект fruit внутри, не подвергая никакому признаку, что Apple содержит объект Fruit? т. е. при построении объекта Apple, я вызываю apple.setColor(), который устанавливает свойство fruit.setColor() внутри страны. Или, должен ли я построить полный объект fruit и во время создания экземпляра apple передать объект fruit, полностью построенный?

Answer 1

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

Возвращаясь к вашему вопросу, сначала давайте рассмотрим случай, в котором Fruit объект является только основная структура данных (т.е. Apple объект является полным надмножеством Fruit в ответственности). В этом случае, если вы попросите разработчиков создать для вас объект Fruit и передать его, вы подвергаете свои внутренние обязанности, и вы можете позволить разработчику получить доступ к нежелательным данным или поведением.

Fruit f = new Fruit(); 
f.doSomethingPrivate(); // This is not intended for an Apple to be set externally 

Apple a = new Apple(f); // Now the Fruit object may not comply with Apple definition 

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

Очень простой пример может быть университетским курс, в котором некоторые студенты зачислить и имеют инструктор:

public class Course { 
    private Person instructor; 
    private Person[] students; 
} 

Здесь, это не ответственность Course объекта подвергать инструктор или студент поведение. Вместо этого контейнерный объект может иметь методы getInstructor() и setInstructor(), и разработчик может принять решение о содержащихся в композиции элементах.

Answer 2

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

В других случаях может быть полезно передать предварительно сконструированный экземпляр для элемента в конструкторе. Это было бы так, например. если больше яблок относится к одному и тому же экземпляру фруктов. В общем, это было бы больше связано с a-a или uses между Apple и Fruit