We Keep Coding

How do I implement an interface if I don't need all of its functions?

I have a simple interface defined
public interface IBla
{
public void DoThing();
public void DoAnotherThing();
public void Thing();
}
I have a bunch of classes which implement this interface. Lots of them however only need two of the three functions which that interface implements, so currently I implement the remaining ones as well and just leave them empty like so:
public void DoThing(){}
Is there some more elegant way of doing this?
I do NOT want to have multiple interfaces defined for this.
Is there perhaps something like a "partialInterface" where I don't have to implement all of the functions from that interface into a class which implements that interface?
Thanks

When implementing an interface, the type that implements the interface must provide an implementation for everything that interface details.
There is no support for partial interfaces or anything similar to what you want, other than breaking up the interface.
You're basically asking "How can I implement the calculator interface without requiring me to provide the + operator" and in short, you can't. It would no longer be a calculator according to that interface.
The closest thing you get is that you can create a base class that provides default implementations for the whole interface or parts of it, and inherit from this base type, so that inherited classes become easier to implement with less code, but they will provide the entire interface.

I know you said you don't want separate interfaces, but for the benefit of others in future who want the right answer to this question here it is:
What you describe is the point at which you separate your interfaces out, and use interface inheritance.
public interface IBasic
{
void DoThing();
}
public interface IAdvanced : IBasic
{
void DoAnotherThing();
void Thing();
}
Implementations which only need DoThing only implement IBasic. Implementations which need all functionality implement IAdvanced which includes the method from IBasic plus the additional functionality.

If you have classes which implement not all methods, then you probably need to separate this interface into smaller interfaces.
Many specific interfaces are better than one universal.
Creating the classes which implement your interface, and throw NotImplementedException or simply do nothing looks like SOLID rules violation.

Well, it is highly discouraged to only partially implement an interface, there is a way to sort of do it.
Most answers talk about breaking up your interface into multiple interfaces, which makes sense. But, if this is not possible simply implement the members that you do not want to use in an explicit manner, and if they get called you should throw a NotSupportedException.
If you want to see an example of this in use, look no further than Microsoft's own code: http://referencesource.microsoft.com/#mscorlib/system/collections/objectmodel/readonlycollection.cs
void ICollection<T>.Add(T value)
{
ThrowHelper.ThrowNotSupportedException(ExceptionResource.NotSupported_ReadOnlyCollection);
}

Given that these things are being processed in a game loop, presumably implementations of IBla are things like the player character, enemies, obstacles, missiles and the like and DoThing etc and Move, Fire and so forth.
If so, then your approach is perfectly valid. An immobile object should have a Move method (so the game loop can call it), and since it can't move, an empty method is a valid implementation.

If you control both interfaces then separate the interfaces into multiple interfaces. As suggested, one interface can inherit from the other, or you could just have some classes implement both interfaces.
In this case interface inheritance is probably the better choice because you won't have to modify the classes that already implement the larger interface.
What if the larger interface is one you don't control, so splitting it into multiple interfaces isn't an option? It's not a good idea to implement the interface and leave some methods without implementations. If a class implements an interface then it should really implement the interface.
A solution is to define the smaller interface that you actually want and create a class that adapts the larger interface to your smaller one.
Suppose you have this interface
public interface IDoesFourThings
{
void DoThingOne();
void DoThingTwo();
void DoThingThree();
void DoThingFour();
}
And you want a class that only implements two of those things? You shouldn't implement IDoesFourThings if the class really only does two things.
So first, create your own interface:
public interface IDoesTwoThings
{
void DoThingA();
void DoThingB();
}
Then create a class that adapts an implementation of IDoesFourThings to your interface.
public class DoesTwoThingsUsingClassThatDoesFourThings : IDoesTwoThings
{
private readonly IDoesFourThings _doesFourThings;
public DoesTwoThingsUsingClassThatDoesFourThings(IDoesFourThings doesFourThings)
{
_doesFourThings = doesFourThings;
}
public void DoThingA()
{
_doesFourThings.DoThingTwo();
}
public void DoThingB()
{
_doesFourThings.DoThingThree();
}
}
Just for the sake of example I avoided naming the methods in IDoesTwoThings to match the ones in IDoesFourThings. Unless they're really exactly the same thing then the new interface doesn't need to match the old one. It is its own interface. That the class works by using an inner implementation of IDoesFourThings is hidden.
This relates to the Interface Segregation Principle, the I in SOLID. One way of thinking about it is this: An interface describes what a class does, but from the perspective of the client class it should describe what the client needs. In this case the client needs two things, not four.
This approach can be very helpful because it enables us to work on one class at a time and defer the implementation of other details. If we're writing a class and we realize that it's going to require a dependency that does two things, we can just write the interface for those two things and make our class depend on it. (Now that class is more testable because it depends on an interface which we can mock.) Then, whatever that new interface is that we just created, we can also create an implementation for that.
It's a great way to manage the complexity of writing code and avoid getting stuck because now we can just work on our one class with its single responsibility, not worrying too much about how the next class and the next one will work. (We likely have an idea how they will work, but maybe we don't. Either way it doesn't slow us down.)

Dependency injection with abstract class

I am struggling for last two days to get a grip of DI.
I have two problems:
If I have a some common functionality why I can't do the same thing implementing DI with an abstract class?
In my example I have many class instance created under writefile, so should I move out all object creation from there? What if I have a layered design? Should these classes be passed all along?
public interface IWriteFile
{
void write();
}
public class WriteXMLFile : IWriteFile
{
public void write()
{
}
}
public class writefile
{
IWriteFile _file;
public writefile(IWriteFile file)
{
_file = file;
}
public void WriteMyFile()
{
_file.write();
}
}

Regarding your first point:
Let's say you want to test something that uses your abstract class. If you're directly using an abstract class, then if you want to do something different in the shared functionality in the common class, there's not much you can do.
With an interface, you've broken the coupling with the dependency. This is what the Dependency Inversion Principle in SOLID is talking about when it says "High-level modules should not depend on low-level modules. Both should depend on abstractions". Your class shouldn't depend on the lower-level class (even if it's an abstract class) to get its work done. Both the lower-level and higher-level class should depend on the interface which defines how they are going to interact. Using an interface helps separate the two, giving you loose coupling. Something else can handle wiring them together.
Regarding your second point:
Powerful DI frameworks actually handle a lot of this complexity for you.
Let's say you have a class - Thing - that has a bunch of dependencies.
public Thing(
IThingRepository repository,
IEmailer emailer,
ILogger logger,
INeedMoreStuff stuff
) : IThing
When you set up your IoC container, you'd do something like the following to associate which implementation to use for each interface:
IoC.Register<MySqlThingRepository>().As<IThingRepository>();
IoC.Register<MicrosoftExchangeEmailer>().As<IEmailer>();
IoC.Register<TruncatingFileLogger>().As<ILogger>();
IoC.Register<MoreStuff>().As<INeedMoreStuff>();
IoC.Register<Thing>().As<IThing>();
Then you can simply do:
IThing thing = IoC.Resolve<IThing>();
These fancy frameworks handle getting all the dependencies for you (since you told it how to get them) and will construct a Thing for you.
That being said, sometimes a fancy framework like that is overkill. In those cases, I usually use the factory pattern to abstract out the details of creating an object while still making sure the object being created follows good DI principles like constructor injection of its dependencies.
Regarding your polymorphism and interfaces:
Someone described polymorphism as simply "Same interface, different implementation. Substitutability". Wikipedia defines it as "the provision of a single interface to entities of different types". According to those definitions, I think using interfaces doesn't go against polymorphism. I feel in C# interfaces are usually sufficient for providing different implementations of the same "interface".
Yes, you can use an abstract base class to do the same thing, but I'd only use that if there's a common set of functionality I can factor out into the base class to keep my code DRY.
Regarding multiple implementations for an interface with StructureMap
I don't how StructureMap handles this, but presumably there's some logic that will decide when you want to use Thing1 versus Things2. You might be able to provide a delegate to StructureMap that it can use to get an IThing which would contain that logic.
Alternatively, you can have a factory that takes some parameters and decides which IThing to return. There are situations where I've put an interface on my factory and constructor injected that, or alternatively have the factory creating the object using IThing use the ThingFactory to get the right one.

Why Use Interfaces Instead of Abstract Classes With DI?

I am beginning my journey of learning about dependency injection, and one of the reasons that I saw why it is a good idea to use DI was that it explicitly specifies your dependencies, which also makes your code more clear.
I have also noticed that interfaces are used abundantly, but I want to know why would we not use abstract classes for the sole purpose of specifying a default constructor?
Of course no implementation could be included in the abstract class.
Wouldn't this:
abstract class FooBase
{
protected IBar _bar;
FooBase(IBar bar)
{
_bar = bar;
}
abstract void DoSomething();
abstract void DoSomethingElse();
}
Demonstrate more clearly what the dependency of a FooBase object is more than:
interface IFoo
{
IBar Bar { get; }
void DoSomething();
void DoSomethingElse();
}
?
Please keep in mind I am new to this whole concept so be nice :)

One technical reason - forcing particular parent class in languages without multiple inheritance (Java/C#) will significantly restrict freedom of implementation of the "interface".
Note that there are 2 concepts hidden behind "interface" word and it sort of make it harder to reason in C#:
"interface" and abstract concept: well defined set of properties/methods to interact with an object; contract to work with an object.
"interface" as type in particular language (C#/Java) - one possible representation of
contract in given language.
Abstract/concrete classes can be used to represent contract, but force restrictions on implementers of contract in C#.
Some other languages (like C++) don't have such restriction and abstract classes is good option there. Other languages (i.e. "duck-types" JavaScript) does not have such class/interface distinction, but you can still have "contract" with an object.
Sample:
To provide more context where you should be hitting this restriction yourself in C#: DI is commonly used along with some form of TDD or at least with basic unit tests. So you try write some code and tests that uses abstract base class for DI.
abstract class Duck {
abstract void Quack();
}
class ConcreteDuck : Duck {...}
Now if you decide to write tests you may already have test classes that helps you to mock objects (if you are not using existing once)
class MockBase {...}
class MockDuck : MockBase,?????? // Can't use Duck and MockBase together...

Interface defines a contract. An Abstract base class defines a behavior.
Essentially, you can provide a single class that implements multiple interfaces,
which then in turn can be injected into multiple classes, but you will only have
a single abstract base class (at least in C#).
Consider the point of registering a type at the container (the composition root at best)
and consider the point where you resolve the dependency (the constructor or a property).
This SO will cover some more aspects SO on interface vs base class

In .NET, you only have single inheritance. In languages/frameworks where this is the case, opting to use an abstract class as your abstraction gives the potential to "burn the base class".
This means that you force the implementer of your abstraction to inherit from a singular class, when forcing them to do so might result in inconveniencing them severely, depending on what the implementation is.
Let's say that you have your abstract class Contract. If someone has their own Base class that they want to use which exposes only protected methods (for inheritors).
Because the methods are protected, one can't use encapsulation (an instance of Base stored in a field) to access the methods in Base for your abstraction implementation.
Even worse, if you don't have access to modify Base, then you might have to resort to some very ugly workarounds (Reflection, namely).
That said, with interfaces, you give the implementer the choice of where to inherit from and don't limit their options.
The typical pattern you'll see is that you always provide an interface for your contract and code your consumers against the interface. You also provide an abstract base class that provides functionality that people may derive from for convenience, but are not obligated to derive from.
Also, if it's possible for you to provide this functionality in the form of something that is easily encapsulated (for the condition I describe above), it would be even more optimal (you'd have an abstract class which just calls the instance that exposes the methods).

I think I missed something on the "Programming to an interface" concept

So I am still very new to C# and using interfaces, and when I thought I understood them I realized I don't completely. The confusion I have found that I am seeking some clarification here for is, when you create an interface, and have a class inherit from it
public Interface ISomeInterface
{
//some methods/properties
}
public class FooClass : ISomeInterface
{
//implemented ISomeInterfaces methods/properties
}
And you use this class object in an implementation somewhere in your program
public class BarClass
{
private ISomeInterface _someInterface;
public BarClass(ISomeInterface someInterface)
{
_someInterface = someInterface;
}
//rest of class
}
My confusion is why do I see it setup this way. I thought that I would have instantiated a new object of type FooClass, as well as used an object of type FooClass in the constructor as such:
public class BarClass
{
private FooClass _fooClass;
public BarClass(FooClass fooClass)
{
_fooClass = fooClass;
}
//rest of class
}
What am I missing to understanding this? I didn't think I would directly be declaring objects of an Interface?
Thanks in advance.

The idea is that BarClass should not be tightly coupled to a specific implementation of ISomeInterface.
If you use this:
public BarClass(FooClass fooClass)
it means that the BarClass can work only with this specific FooClass implementation and nothing else. Whereas if you use:
public BarClass(ISomeInterface fooClass)
now the BarClass is no longer tightly coupled to FooClass. This means that the consumer of the BarClass can now pass any implementation of the interface he wants as long as it respects the defined contract (interface). So if he wants FooClass he passes an instance of FooClass, but if he is not satisfied with FooClass he can write his own implementation and pass it to the constructor and from the point of view of the BarClass this is absolutely transparent (it doesn't need to be modified).
The weak coupling between your classes is one of the most fundamental aspects of OOP as it allows you to easily replace one component with another without having to rewrite your entire application.

Suppose FooClass wrote something to a database. You'd like to test BarClass without having to actually set up a database. If you created a different TestFoo that implemented the same interface, you could pretend to be the database and more easily test your class; BarClass wouldn't have to know that it wasn't talking to the 'real' FooClass.

Do you have a C/C++ background? Then you should be aware that
private ISomeInterface _someInterface;
would be written as
private:
ISomeInterface& _someInterface;
In C++ (assuming you have an abstract base class called ISomeInterface).
This means you are storing a reference to an object implementing ISomeInterface not such an object itself. The advantage of this is that you can pass ANY object to BarClass that implements ISomeInterface which gives you more flexibility, e.g. for unit testing.

By using the interface definition instead of the concrete implementation, your code is now more loosely coupled. This technique is used in dependency injection.
In addition, this comes in handy when you need to need to implement FooClass differently. If you used the concrete implementation, you will need to make code changes where ever you have declared FooClass. Programming against the interface shields you from the effects of such changes.

One of the main benefit to program to ISomeInterface instead of FooClass, is that you might probably change your implementation of FooClass. For example, consider a database driven blog application:
interface IBlogStorage{
getPosts();
}
you then have a class like:
class XMLBlogSotrage: IBlogStorage{}
and suppose you implement everything to the interface. later on, you think XML is too slow and you want to use RDBMS, then:
class MsSQLBlogStorage:IBlogStorage{}
In this case, you don't need to change anything in other codes, you just need to create a new class and plug it in! Those already existed codes, doesn't need to bother where is the storage.

Another way of thinking about the interplay between interfaces and classes is to flip them upside down. That means to start with classes first. Let's say you have several classes that expose a method called "Sort()". Then you have another class that has a method that requires references to these classes and in turn calls their "Sort()" methods. Instead of having several methods with different parameters, you can create and attach an interface to those classes (very quick fix as these classes already contain the implementation).
A.Sort()
B.Sort()
C.Sort()
interface ISortable {void Sort();}
A : ISortable
B : ISortable
C : ISortable
D.SortSomething(ISortable foo)
{
foo.Sort()
}
Maybe this is too abstract. My favorite use of interfaces is enabling my classes to participate in foreach loops.
class SomeCollection : IEnumerable
{
List<SomeItem> _items = new List<SomeItem>();
// This is the only code I need to enable this class to participate in foreach loop.
public Enumerator GetEnumerator()
{
return _items.GetEnumerator();
}
}
Once you discover how interfaces can simplify your codes, you can even begin creating interfaces before writing your classes.

C# Interface for multiple classes

I have a data provider project to access the database. this is composed by various classes (PersonDataProvider, JobDataProvider ...)
I want to create an Interface.
Do I have to create an Interface for each class?
I was tempted to create one interface and than inherit on all the classes. This involves making all the projects classes partial and change the classes name.......But i think is not the best solution.
Any suggestion?

You don't inherit an Interface you implement it. There's no need to make a class partial to add an interface to it.
An interface is a contract that the class subscribes to saying that it will honour the methods described in the interface and will implement them appropriately. For your scenario you'd create a single interface and implement it in your classes, you can then pass the instances of the various accessor classes as instances of the interface.
For example:
public interface IDataProvider
{
void LoadData();
}
The data providers would then look as follows:
public class MyDataProvder1 : IDataProvider
{
// Some methods
// Must implement LoadData
public void LoadData()
{
// Do something
}
}
public class MyDataProvder2 : IDataProvider
{
// Some methods
// Must implement LoadData
public void LoadData()
{
// Do something
}
}
You can then pass the objects as IDataProvider as follows:
IDataProvider DataProviderA = new MyDataProvider1();
IDataProvider DataProviderB = new MyDataProvider2();
// Call function that expects an IDataProvider
DoSomething(DataProviderA);
DoSomething(DataProviderB);
...
public void DoSomething(IDataProvider DataProvider)
{
DataProvider.LoadData();
}
Hopefully that clears it up for you.

I think you are approaching this incorrectly.
When you make an interface, you're making a contract for those classes. Think of it as "my class will act as a IMyInterface".
If all of your classes have a common usage scenario, then a single, common interface may be appropriate (IDataProvider, given the class names..?).

Using interface depends how you want to arrange the classes. Interface allows some sort of plug and play behaviour. So, if you need a single interface, this will mean that you shall have a single set of interfaces accross all the classes implementing the interface. In such a case, your classes PersonDataProvider, JobDataProvider etc. will have the same set of methods. If you feel, they need to be different and still be available through a single provider facade, you can think of using a facade pattern.
The facade will have interfaces for individual provider and the provider classes will implement them.

First off, I'm assuming there are standard method calls across all your xDataProvider classes. For example, instead of a SelectPerson method, you have a Select method on the PersonDataProvider class. If not, you have some work to do to make this a valid exercise.
Within Visual Studio, there is an Extract Interface refactoring option. Right-click in a xDataProvider class and choose Refactor - Extract Interface. Now name it (IDataProvider, for example) and choose the methods / properties you want in your interface, click OK and your done with this class.
Then just implement this IDataProvider interface in your other xDataProvider classes. Assuming you've already implemented similar methods in all you DataProvider classes, you won't have to write any more code (beyond the : IDataProvider).