Полезна ли инъекция зависимостей в C ++

Для этого мне нужен интерфейс и, возможно, контейнер для разрешения моих экземпляров. Но как это сделать в C ++?

Точно так же. Разница в том, что если вы «программируете на интерфейс» на C #, вы «программируете на базовый класс» на C ++. Кроме того, у вас есть дополнительные инструменты в C ++, которых нет в C # (например, шаблоны на основе политик реализуют внедрение зависимостей, выбираемое во время компиляции).

В C ++ вы используете ссылку на объект, это способ использования DI в C ++, верно?

Нет; это не способ использования DI, это способ использования DI в C ++.

Также учтите:

• использовать указатель на объект (или умный указатель, в зависимости от случая)
• использовать аргумент шаблона для политики (например, см. использование std :: default_delete в интеллектуальных указателях)
• используйте lambda calcullus с введенными функторами / предикатами.

В C # у меня есть «плохой класс / плохой проект / сборка», которые регистрируют все мои экземпляры в статическом контейнере при запуске программы.

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

возможно ли это в C ++?

Да, это вполне возможно (но не стоит этого делать, так как это нарушает закон Деметры). Взгляните на boost :: any (это позволит вам хранить разнородные объекты в контейнере, аналогично хранению объектов по object ссылке в C #).

Вы используете инъекцию зависимостей или как это называется в C ++?

Да (и это называется инъекцией зависимостей :)).

Если да, то как вы это используете?

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

Использование внедрения зависимостей в C ++ довольно просто. Просто определите интерфейс (чистый абстрактный базовый класс), который вы используете в качестве аргумента ссылки или указателя (или интеллектуального указателя) для конструктора или функции инициализации класса, в который вы хотите внедрить зависимость.

Затем в модульном тесте введите фиктивный объект (экземпляр класса, наследующий от абстрактного класса интерфейса), а в реальном коде введите экземпляр реального класса (также наследующий от того же класса интерфейса).

Очень просто.

С С ++ 11 в качестве ограничения проекта я закончил свой собственный. Я вольно основал его на .NET Ninject API, конечно, без Reflection.

ServiceLocator

Обратите внимание, хотя он называется ServiceLocator (поскольку он сам не выполняет Dependancy Injection), если вы используете привязки лямбда-функций и, предпочтительно, классы ServiceLocator :: Module, вы получаете Injection (не на основе отражения), и он работает очень хорошо (IMO)

#include <iostream>
#include <vector>
#include "ServiceLocator.hpp"

template <class T>
using sptr = std::shared_ptr<T>;

// Some plain interfaces
class IFood {
public:
    virtual std::string name() = 0;
};

class IAnimal {
public:
    virtual void eatFavouriteFood() = 0;
};


// Concrete classes which implement our interfaces, these 2 have no dependancies
class Banana : public IFood {
public:
    std::string name() override {
        return "Banana";
    }
};

class Pizza : public IFood {
public:
    std::string name() override {
        return "Pizza";
    }
};

// Monkey requires a favourite food, note it is not dependant on ServiceLocator
class Monkey : public IAnimal {
private:
    sptr<IFood> _food;

public:
    Monkey(sptr<IFood> food) : _food(food) {
    }

    void eatFavouriteFood() override {
        std::cout << "Monkey eats " << _food->name() << "\n";
    }
};

// Human requires a favourite food, note it is not dependant on ServiceLocator
class Human : public IAnimal {
private:
    sptr<IFood> _food;

public:
    Human(sptr<IFood> food) : _food(food) {
    }

    void eatFavouriteFood() override {
        std::cout << "Human eats " << _food->name() << "\n";
    }
};

/* The SLModule classes are ServiceLocator aware, and they are also intimate with the concrete classes they bind to
   and so know what dependancies are required to create instances */
class FoodSLModule : public ServiceLocator::Module {
public:
    void load() override {
        bind<IFood>("Monkey").to<Banana>([] (SLContext_sptr slc) { 
            return new Banana();
        });
        bind<IFood>("Human").to<Pizza>([] (SLContext_sptr slc) { 
            return new Pizza();
        });
    }
};

class AnimalsSLModule : public ServiceLocator::Module {
public:
    void load() override {
        bind<IAnimal>("Human").to<Human>([] (SLContext_sptr slc) { 
            return new Human(slc->resolve<IFood>("Human"));
        });
        bind<IAnimal>("Monkey").to<Monkey>([] (SLContext_sptr slc) { 
            return new Monkey(slc->resolve<IFood>("Monkey"));
        });
    }
};

int main(int argc, const char * argv[]) {
    auto sl = ServiceLocator::create();

    sl->modules()
        .add<FoodSLModule>()
        .add<AnimalsSLModule>();

    auto slc = sl->getContext();

    std::vector<sptr<IAnimal>> animals;
    slc->resolveAll<IAnimal>(&animals);

    for(auto animal : animals) {
        animal->eatFavouriteFood();
    }

    return 0;
}

Да, внедрение зависимостей также полезно в C ++. Нет причин, по которым этого не должно быть, потому что для этого не требуется конкретный язык или синтаксис, а требуется только объектно-ориентированная архитектура классов (по крайней мере, это, вероятно, наиболее распространенный случай).

В то время как в C # есть только «указатели» на динамически выделяемые объекты, в C ++ есть несколько вариантов, таких как «нормальные» локальные переменные, несколько типов указателей, ссылки ... Кроме того, здесь очень актуальна концепция семантики перемещения.

В C ++ вы используете ссылку на объект, это способ использования DI в C ++, верно?

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

есть ли что-то вроде контейнера, в котором я могу разрешить все эти ссылки? В C # у меня есть «плохой класс / плохой проект / сборка», которые регистрируют все мои экземпляры в статическом контейнере.

Возможно, вы упускаете из виду точку внедрения зависимостей. Это не то же самое, что набор «глобальных» переменных. Но да, конечно, это возможно и в C ++. Есть классы, есть static, и это все, что нужно.

Если моя теория со ссылками верна, есть ли что-то вроде контейнера, в котором я могу разрешить все ссылки? В C # у меня есть «плохой класс / плохой проект / сборка», который регистрирует все мои экземпляры в статическом контейнере при запуске программы. Затем в каждом классе я могу создать экземпляр статического контейнера и разрешить конкретный экземпляр, возможно ли это в C ++?

Это не то, как предполагается использовать DI, вы не передаете свой контейнер всему своему «потребительскому» классу. В хорошо спроектированном приложении вы просто делаете несколько разрешений в точке входа, и все. В большинстве случаев потребность в «разрешении» может быть заменена использованием фабрики, которая будет зарегистрирована, а затем введена.

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

Это старый пост, но я написал образец реализации контейнера di на C ++. может тебе интересно.

https://github.com/dirkwinkhaus/widic-dicontainer