Комментарии 13
Главное, что про С++, ведь инверсия зависимостей она только там.
Схема сильно упрощена, но в ней отражена суть инверсии - в какой-то момент времени стрелка становится направлена в обратном направлении
Объяснение от бога, конечно
Написано в стиле источника [1]. Кратко и по-сути.
С той лишь разницей, что показано, **где возникает инверсия**.
В ваших диаграммах даже не понятно, что обозначает стрелочка. Что уж говорить о том, каким же волшебством она разворачивается?
Мне одному кажется, что в статье пропущено 99 процентов текста?
Работник должен сам себе зарплату рассчитывать ?
На первой схеме: Работник обращается - в отдел бухгалтерии - бухгалтеры заходят в программу 1С и расситывают зарплату.
На второй схеме: Работник обращается - в отдел бухгалтерии - бухгалтеры говорят: посчитайте себе зарплату сами :-)
т.е. первая схема лучше :-)
Есть же примеры получше. Например, надо писать логи, для этого есть какой-то ConsoleLogger, мы его у себя используем - т е зависим от него. Применяя этот принцип, выделяем интерфейс ILogger, и теперь мы не зависим от конкретного логгера, а наоборот - логгер зависит от нас (при условии что интерфейс определен например в том же модуле что и потребитель, а конкретный логгер - в другом модуле).
Чтобы до конца покончить с дилетантами оставлю здесь комментарий о том, как бы автор реализовал данную систему с использованием языка C++.
Объявить базовый класс Worker(сотрудник), от которого унаследовать производные классы PartialTimeWorker, FullTimeWorker и т.д.
Создать объект Department(штат сотрудников), который хранит список всех сотрудников в виде списка vector
Создать объект Accounting(бухгалтерия), который содержит метод calculate_salary(WorkerType) и само перечисление WorkerType
При необходимости расчитать зарплату, объект Department для каждого сотрудника в списке vector выполняет downcast, определяя при этом значение переменной workerType и вызывает метод accounting.calculate_salary(worker_type)
Таким образом объект Department зависит только от типов работников (инверсия), но не от деталей реализации расчета заработной платы. Также каждый объект Worker не знает о существовании других типов сотрудников.
как бы автор реализовал данную систему с использованием языка C++.
Какую "данную систему"? У вас даже задача не озвучена.
Объявить базовый класс Worker(сотрудник), от которого унаследовать производные классы PartialTimeWorker, FullTimeWorker и т.д.
А зачем вам производные классы, если вы все равно пользуетесь каким-то перечислением?
Department для каждого сотрудника в списке vector выполняет downcast, определяя при этом значение переменной workerType
Каким образом "определяя значение"?
Прямо скажем, все, что вы описали, делается вообще без ООП, потому что это тривиальный процедурный алгоритм.
Инверсия зависимости предполагает развернуть зависимости в сторону устойчивых классов/компанентов создавая при этом ацекличный граф зависимостей, а не вот это вот всё ....
Сейчас бы в сущность бизнес логику закидывать, ага. Сколько помню, у Дядюшки Боба диаграмма была понятнее и жизненнее, вот ее бы и привели как пример.
Целью этой статьи была передача опыта и, что более важно, желание находится в среде образованных профессионалов, а не дилетантов.
Странные цели и способы их достичь:
Передача опыта: в статье не рассказано ничего полезного про инверсию зависимостей вообще, не говоря уже о своём опыте (хотя какой тут нужен особый опыт - непонятно. Допускаю, что у кого-то на каких-то проектах могут быть интересные кейсы)
Желание "находится" в среде образованных профессионалов. Я совсем не понял, как желание может быть целью, типа автор надеялся, что напишет статью и у него появится желание? Или что?
Инверсия зависимостей (dependency inversion principle)