Агрегирование по сравнению с [закрытым] составом

Вы можете попробовать этот способ,

1) Удалить

multiDexEnabled true

из приложения gradle и добавить только

реализация 'com.android.support:multidex:1.0.3'

для ваших зависимостей приложения

Как это

apply plugin: 'com.android.application'
apply plugin: 'com.google.gms.google-services'
android {
compileSdkVersion 27
defaultConfig {
    applicationId "com.heizolscout.itclanbd.heizolscout"
    minSdkVersion 18
    targetSdkVersion 27
    versionCode 1
    versionName "1.0"
    testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
}
buildTypes {
    release {
        minifyEnabled false
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard- 
rules.pro'
    }
}
}
dependencies {
implementation fileTree(include: ['*.jar'], dir: 'libs')
implementation 'com.android.support:appcompat-v7:27.1.1'
implementation 'com.android.support:multidex:1.0.3'
implementation 'com.android.support.constraint:constraint-layout:1.1.2'
implementation 'com.android.support:support-v4:27.1.1'
testImplementation 'junit:junit:4.12'
androidTestImplementation 'com.android.support.test:runner:1.0.2'
androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2'
}
86
задан reinierpost 13 March 2012 в 08:07
поделиться

7 ответов

Различие между агрегацией и составом зависит от контекста.

Возьмите пример автомобиля, упомянутый в другом ответе - да, Это правда, что выхлопные газы автомобилей могут стоять «сами по себе», поэтому могут не входить в состав автомобиля - но это зависит от области применения. Если вы создаете приложение, которое на самом деле имеет дело с автономными выхлопами автомобилей (приложение для управления автомагазином?), Агрегация будет вашим выбором. Но если это простая гоночная игра, а выхлопные газы автомобиля служат лишь частью автомобиля - ну, состав будет вполне нормальным.

Шахматная доска? Та же проблема. Шахматная фигура не существует без шахматной доски только в определенных приложениях. В других (например, у производителя игрушек) шахматная фигура, безусловно, не может быть составлена ​​из шахматной доски.

Ситуация становится еще хуже, когда вы пытаетесь отобразить композицию / агрегацию на ваш любимый язык программирования. В некоторых языках разницу легче заметить («по ссылке» и «по значению», когда все просто), но в других может вообще не существовать.

И последний совет? Не тратьте слишком много времени на эту проблему. Это того не стоит. Различие вряд ли полезно на практике (даже если у вас есть совершенно четкая «композиция», вы все равно можете реализовать ее как агрегацию по техническим причинам - например, кеширование).

И последний совет? Не тратьте слишком много времени на эту проблему. Это того не стоит. Различие вряд ли полезно на практике (даже если у вас есть совершенно четкая «композиция», вы все равно можете реализовать ее как агрегацию по техническим причинам - например, кеширование).

И последний совет? Не тратьте слишком много времени на эту проблему. Это того не стоит. Различие вряд ли полезно на практике (даже если у вас есть совершенно четкая «композиция», вы все равно можете реализовать ее как агрегацию по техническим причинам - например, кеширование).

88
ответ дан Hexagon 24 November 2019 в 07:53
поделиться

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

36
ответ дан David M 24 November 2019 в 07:53
поделиться

Примером, который я выучил, были пальцы на руке. Ваша рука состоит из пальцев. Он владеет ими. Если рука умирает, пальцы умирают. Вы не можете "собирать" пальцы. Вы не можете просто взять дополнительные пальцы, прикрепить и отсоединить их от руки по желанию.

Значение здесь, с точки зрения дизайна, часто связано с продолжительностью жизни объекта, как сказал другой автор. Скажем, у вас есть клиент, и у него есть аккаунт. Эта учетная запись является «составленным» объектом клиента (по крайней мере, в большинстве случаев, о которых я могу думать). Если вы удаляете Клиента, Учетная запись сама по себе не имеет значения, поэтому она также будет удалена. Обратное часто верно при создании объектов. Поскольку учетная запись имеет значение только в контексте клиента, создание учетной записи будет происходить как часть создания клиента (или, если вы сделаете это лениво, это будет частью какой-то транзакции Заказчика.)

В дизайне полезно подумать о том, какие объекты владеют (составляют) другие объекты по сравнению с теми, которые просто ссылаются (объединяют) другие объекты. Это может помочь определить, где лежит ответственность за создание / очистку / обновление объекта.

Что касается кода, часто трудно сказать. Большинство всего в коде является ссылкой на объект, поэтому может быть неочевидным, является ли объект, на который ссылаются, составленным (владельцем) или агрегированным.

Большинство всего в коде является ссылкой на объект, поэтому может быть неочевидным, является ли объект, на который ссылаются, составленным (владельцем) или агрегированным.

Большинство всего в коде является ссылкой на объект, поэтому может быть неочевидным, является ли объект, на который ссылаются, составленным (владельцем) или агрегированным.

18
ответ дан Chris Kessel 24 November 2019 в 07:53
поделиться

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

, поэтому этот код ...

Class Order
   private Collection<LineItem> items;
   ...
   void addOrderLine(Item sku, int quantity){
         items.add(new LineItem(sku, quantity));
   }
}

предполагает, что LineItem является компонентом Order - LineItems не существуют вне своего содержащего порядка. Но объекты Item не создаются в порядке - они передаются по мере необходимости и продолжают существовать, даже если в магазине нет заказов. поэтому они связаны, а не компоненты.

* nb контейнер отвечает за создание экземпляра компонента, но на самом деле он может не вызывать сам новый ... () - это Java, там '

8
ответ дан Chris May 24 November 2019 в 07:53
поделиться

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

Я получил некоторое преимущество от UML для генерации кода, для исходного кода или DDL для реляционной базы данных. Там я использовал состав, чтобы указать, что в моем коде таблица имеет ненулевой внешний ключ (в базе данных) и ненулевой «родительский» (и часто «конечный») объект. Я использую агрегацию, когда я предполагаю, что запись или объект могут существовать как «сирота», не привязанные к какому-либо родительскому объекту, или «быть принятыми» другим родительским объектом.

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

0
ответ дан 24 November 2019 в 07:53
поделиться

Пример, который мне нравится: Состав: Вода является частью пруда. (Пруд представляет собой композицию из воды.) Агрегация: В пруду есть уток и рыб (в пруду скопления уток и рыб)

Как вы можете видеть, я выделил жирным шрифтом слова «часть» и «имеет», поскольку эти 2 фразы обычно указывают на то, какой между классами существует связь.

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

0
ответ дан 24 November 2019 в 07:53
поделиться

Состав и агрегирование - это типы ассоциаций. Они очень тесно связаны между собой, и с точки зрения программирования особой разницы нет. Я попытаюсь объяснить разницу между этими двумя примерами java-кода

Агрегация : объект существует вне другого, создается снаружи, поэтому он передается как аргумент (например) конструктору. Пример: Люди - машина. Автомобиль создается в другом контексте и затем становится собственностью человека.

// code example for Aggregation:
// reference existing HttpListener and RequestProcessor
public class WebServer {
  private HttpListener listener;
  private RequestProcessor processor;
  public WebServer(HttpListener listener, RequestProcessor processor) {
    this.listener = listener;
    this.processor = processor;
  }
}

Композиция : объект существует только или имеет смысл только внутри другого, как часть другого. Пример: Люди - сердце. Вы не создаете сердце, а затем передаете его человеку.

// code example for composition:
// create own HttpListener and RequestProcessor
public class WebServer {
  private HttpListener listener;
  private RequestProcessor processor;
  public WebServer() {
    this.listener = new HttpListener(80);
    this.processor = new RequestProcessor(“/www/root”);
  }
}

Объясняется здесь на примере Разница между агрегированием и составом

47
ответ дан 24 November 2019 в 07:53
поделиться
Другие вопросы по тегам:

Похожие вопросы: