Kontenery - co jeśli kilka klas implementuje dany interfejs?

Zacząłem czytać o kontenerach na przykłądzie Ninject i mam pytanie. Co jeśli mamy kilka klas implementujących dany interfejs? W konfiguracji podajemy jedną zależność, jak sobie poradzić gdy mamy tego więcej?

public interface Animal
{
  void Noise();
}

public class Dog : IAnimal
{
 //implementacja
}

public class Cat: IAnimal
{
 //implementacja
}

public class Duck: IAnimal
{
 //implementacja
}

w konfiguracji kontenera mam np

kernel.Bind<IAnimal>. To<Dog>();

no i teraz co w przypadku jeśli mam w aplikacji strategie, że czasem potrzebuje klasy Dog, czasem Cat a czasem Duck, kontener już tego nie obsłuży. Co się robi w takich sytuacjach?

Jeden interfejs powinien mieć jedną implementację "końcową" (czy to wynikającą z designu, czy też przez runtime *) - w sytuacji, którą pokazałeś, masz prawdopodobnie błąd projektowy bądź rozważasz sytuację, która nigdy nie będzie mieć miejsca w rzeczywistości.

* - np. gra może mieć konfigurowane OpenGL vs DirectX, które można wybrać dopiero po przetworzeniu pliku konfiguracyjnego.

No dobrze, ale wracając do tego przykłądu co podałem, to przecież mogę mieć w głównej części aplikacji coś w stylu

IAnumal animal;
switch(selectedAnimal)
{
  case "Dog":
    animal = new Dog();
    break;
  case "Cat":
    animal = new Cat();
    break;
  case "Duck":
    animal = new Duck();
    break;
}

i gdzieś później wybrany zwierzak jest wstawiany jako parametr

public void MakeNoise(IAnimal animal)
{
   animal.Noise();
}

Na chwilę obecną kontenery to dla mnie czarna magia i jeszcze nie widzę sensu po co ich używać.
Mógłbyś mi trochę rozjaśnić sprawę z kontenerami i też szerzej napisać o tej "koncowej" implementacji o której wspominasz?
Dziekuję.

Wydaje mi się, czy też faktycznie próbujesz uczyć się działania kontenerów bez zrozumienia do czego służą i jak działają interfejsy same w sobie?

Na pewno brakuje mi tej wiedzy, ale tak ogólnie z tego co do tej pory czytałem to interfejsy umożliwiaja "podmiane "klas

i zapewniają ze klasa będzie miała jakieś dane zachowanie

Wzorzec strategii to nie jest po prostu przykład na użycie kontenera. Kontener się przydaje, jeśli twoja aplikacja składa się z klasy, która ma swoje zależności, one mają jeszcze swoje itp. Wtedy konfigurujesz je w kontenerze i tworzysz za jego pomocą tylko główny obiekt, a wszystkie jego zależności są wstrzykiwane automatycznie. Podobnie z kontrolerami w przypadku ASP.NET. A dzięki zastosowaniu wstrzykiwania zależności i interfejsów np. w testach jednostkowych możesz wstrzykiwać do klasy mocki jej zależności, dzięki czemu w testach możesz przetestować każdą klasę osobno w oderwaniu od jej zależności.

[mad_penguin napisał(a)]:

Wzorzec strategii to nie jest po prostu przykład na użycie kontenera.

w tym przykładzie chodziło mi o to ze interfejs moze miec wiele implementacji i ciekawy byłem jak kontener sobie poradzi z czyms takim skoro w jego konfiguracji mam podana tylko jedną implementację

Myślę że ten artykuł odpowie na Twoje pytania.
http://autofaccn.readthedocs.io/en/latest/faq/select-by-context.html
Inny kontener ale założenia podobne.