Dependency Inversion, IList<Interface>

Hi Guys,

I'm trying to seek some advice here in terms of DI.

I'm trying to avoid doing MyClass mObj = new MyClass(); in my classes to ensure my higher level classes don't depend on any lower level classes, only on abstractions. SO with this in mind say I have a class that needs to return an IList of type IMyInterface

so the "easy" way, by implementing a concrete class would be something like;

public class ListRetriever
{

public IList<IMyInteface> ReturnList()
{
IList<IMyInterface> returnList = new List<IMyInterface>();

//so problem is here, which I want to avoid
IMyInterface singleItem = new ConcreteClassThatImplementsInterface();
returnList.Add(singleItem);
return returnList;
}
}

To avoid implementing a concrete function I can think of doing something like this:

public class ListRetriever
{
 private IMyInterface myInteface;
public LIstRetriever(IMyInterface _myInterface)
{
myInterface = _myInterface;
}
public IList<IMyInteface> ReturnList()
{
IList<IMyInterface> returnList = new List<IMyInterface>();
IMyInterface singleItem = (IMyInterface)Activator.CreateInstance(myInterace.getType());
returnList.Add(singleItem);
return returnList;
}
}

SO - to all the EE experts out there - You can see that my returnList is only ever going to be of the "one" concrete type that is passed in this particular case.
In terms of not "relying" on any concrete implementation, this is achieved, HOWEVER -  the whole solution just seems wrong to me. I'm all ears regarding any and all advice you all might have.

Regards,

chud
chudmarekAsked:
Who is Participating?
 
Bob LearnedCommented:
Gang of Four Design Patterns - Does it stand the test of time?
http://www.infoq.com/news/2007/07/GoFCriticism

Design patterns are a form of complexity. As with all complexity, I'd rather see developers focus on simpler solutions before going straight to a complex recipe of design patterns.
0
 
Bob LearnedCommented:
This seems like a bit of work to get abstraction, but I don't see the benefit, yet.  I am not sure that I understand what you mean by "I'm trying to avoid doing MyClass mObj = new MyClass();"
0
 
Bob LearnedCommented:
Rumination topic:

Dependency Inversion Principle in C# – SOLID Design Principles – Part 5
http://johnlnelson.com/2014/07/23/dependency-inversion-principle-in-c-solid-design-principles/

A word of caution – we cannot just program to interfaces and say that we have implemented Dependency Inversion!  I will admit that this is a great idea in and of itself, but by itself it does not give us Dependency Inversion.  To truly realize the benefits, we have to ensure that the interfaces we use are owned and controlled by the higher-level objects.  In other words, the top-level consumers own the contracts that must be honored by the lower-level providers.
0
Cloud Class® Course: Microsoft Azure 2017

Azure has a changed a lot since it was originally introduce by adding new services and features. Do you know everything you need to about Azure? This course will teach you about the Azure App Service, monitoring and application insights, DevOps, and Team Services.

 
Bob LearnedCommented:
Here is a good description of a change for Dependency Inversion:

The SOLID Principles in C# – Dependency Inversion
http://www.remondo.net/solid-principles-csharp-dependency-inversion/

In the traditional N-tier layering structure, where we have maybe a GUI, Business Layer and Data Access Layer, we see higher level modules instantiate and call lower-level modules. This is creating a dependency from the high-level GUI through the BLL to the lower-level DAL. These dependencies make it much harder for us to change, maintain and test the system.
0
 
ste5anSenior DeveloperCommented:
hmm, sounds more like: How to  use generics?

E.g.

public class ListRetriever<T> where T : new(), IMyInteface
{
	public IList<T> ReturnList()
	{
		IList<T> returnList = new List<T>();
		T singleItem = new T();
		returnList.Add(singleItem);
		return returnList;
	}
}

Open in new window

0
 
apeterCommented:
Since you have your abstractions defined, just to avoid creating concrete class you can use Unity or Castle Windsor
0
 
Andrew BeersTechnology LeadCommented:
There are many dependency injection frameworks you could use to accomplish this.

Structure Map
Ninject
Windsor

I'm guessing you want to get around this due to testing and injection concerns.  There are ways to accomplish this without using a framework however:

public static class MyObjectFactory
{
   private static Func<IMyInterface> _activator;
   static MyObjectFactory()
   {
      //This sets you default
      _activator = () => new MyConcreteClass();
   }

   public static IMyInterface Get()
   {
      return _activator();
   }

   public static void Set<T>() where T : IMyInterface, new() 
   {
      _activator = () => new T();
   }
}

Open in new window


Then you can consume this to create instances of your interface without directly referencing the type you want.

private IMyInterface _instance;
public MyConstructor()
{
   _instance = MyObjectFactory.Get();
}

Open in new window


In your tests you can init the status of your application by doing:

MyObjectFactory.Set<MyMockedVersion>();

Open in new window


This is the poor man's dependency injection, but still works exactly the same it's just a little more code.

I hope this helps!
0
 
chudmarekAuthor Commented:
I had to split the points here due to the following:

ste5an got me through the solution in the short term using some generics, HOWEVER the other answers delivered some more long term solutions in terms of Dependancy Inversion that i will need to investigate, and research further.

Thank you for the help Experts!

Regards,
Chud
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.