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

Question

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

Я недавно изучал шаблон проектирования внедрения зависимости.

class User
{

private $db;

public function __construct(Database $db)
{
$this->$db = $db;
}

}

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

3

aggregation dependency-injection design-patterns oop php

Решение

Другие решения

Я не могу не удивляться, что это то же самое, что я узнал в агрегации

Рассмотрим Department класс, например, который имеет массив Professor объекты в качестве переменной экземпляра. Есть два способа, которыми вы можете инициализировать массив профессор с некоторыми Professor объекты.

Вы можете инициализировать элементы Professor массив в пределах Department класс в некотором методе, который не принимает параметров, говоря professors[0]=new Professor("CK"); а также professors[1]=new Professor("MK");,
Вы можете предоставить конструктор, который принимает массив Professor введите в качестве аргумента. Любой класс, который хочет создать экземпляр Department Затем придется также передать массив Professor объекты в конструктор.

Агрегация: Неважно, используете ли вы вариант 1 или 2, чтобы определить, как Department получает своих профессоров. Профессор будет продолжать существовать, даже если кафедры нет (при условии, что профессор принадлежит к нескольким кафедрам), и поэтому говорят, что это агрегация независимо от того, как кафедра получает своих профессоров.

Внедрение зависимости Если вы используете вариант 2 для создания Department Например, это будет называться внедрением зависимости. Отделу нужны профессора, и вы удовлетворяете эту зависимость, предоставляя ее извне Department учебный класс.

Другими словами, агрегирование это тип отношений, который может быть смоделирован с использованием опции 1 или опции 2 (или других опций, таких как получение профессоров из базы данных и заполнение Professor массив в Department внутри метода). Внедрение зависимостей — это способ разработки вашего класса, чтобы его зависимости могли быть предоставлены извне класса. Агрегированные отношения могут быть смоделированы для поддержки внедрения зависимостей, но это не означает агрегирование а также Внедрение зависимости это одно и то же.

2

Агрегация обычно моделируется как отношение один ко многим, и, кроме того, имеет тенденцию подразумевать семантику части-целого. По этим причинам БД пользователей обычно не следует рассматривать как агрегацию: отношение составляет 1: 1, и концепция пользователя не обязательно подразумевает БД.

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

Инъекция зависимости может рассматриваться как способ создания отношений. Отношение может быть 1: 1 или один ко многим. Это может подразумевать определенную семантику или нет. Критическая особенность DI заключается в том, что User не контролирует создание DBни инициировать его создание.

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

1

Агрегация — это способ поддерживать ассоциации между объектами. Вы используете этот термин при описании того, как вы структура отношений между объектами. Это предметный термин, такая же связь существует между объектами в реальной жизни.

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

1

Я решил добавить эти пункты.

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

Но есть разница. В агрегирование вы работаете с прямыми объектами. то есть объекты, которые поддерживают состояние, жизненный цикл и т. д.

Пример:
колба & Номер

Экземпляры колба могут быть помещены в случаи Номер.
Но не только Номер, некоторые случаи могут быть помещены в случаи Автомобиль, Радио и т.п.
А также случаи колба может работать независимо друг от друга, не будучи вовлеченным в экземпляры других объектов.

Но в Внедрение зависимости мы сосредоточены на взаимодействиях на уровне класса. Это несколько расходится с чистой практикой ООП. На самом деле в DI мы склонны вводить классы без гражданства (рабочие классы) в некоторые другие классы. Хотя они выглядят как объекты, на самом деле это просто классы без состояния, которые вводятся. И экземпляры этого класса тоже могут стоять независимо. ДИ широко используется в качестве альтернативы Традиционный синглтон потому что этот традиционный способ имеет некоторые негативные побочные эффекты.

Пример:

Предположим, что рабочий класс без гражданства называется StringUtils (Не Apache, который сложен со статическими методами.). Это может быть введено в классы, называемые NounUtils, VerbUtils и т. д. А также случаи StringUtils также может существовать.

Надеюсь, у вас есть идея. :))

1

Источник

Accepted Answer

Агрегация — это форма композиции объекта. Это не имеет ничего общего с внедрение зависимости.

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

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

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

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

1