In what namespace should you put interfaces relative to their implementors?

Question

Specifically, when you create an interface/implementor pair, and there is no overriding organizational concern (such as the interface should go in a different assembly ie, as recommended by the s# architecture) do you have a default way of organizing them in your namespace/naming scheme?

This is obviously a more opinion based question but I think some people have thought about this more and we can all benefit from their conclusions.

Gimp

Answer 1

The answer depends on your intentions.

• If you intend the consumer of your namespaces to use the interfaces over the concrete implementations, I would recommend having your interfaces in the top-level namespace with the implementations in a child namespace
• If the consumer is to use both, have them in the same namespace.
• If the interface is for predominantly specialized use, like creating new implementations, consider having them in a child namespace such as Design or ComponentModel.

I'm sure there are other options as well, but as with most namespace issues, it comes down to the use-cases of the project, and the classes and interfaces it contains.

Labyrinthine

Answer 2

I usually keep the interface in the same namespace of as the concrete types.

But, that's just my opinion, and namespace layout is highly subjective.

Animals
|
| - IAnimal
| - Dog
| - Cat
Plants
|
| - IPlant
| - Cactus

You don't really gain anything by moving one or two types out of the main namespace, but you do add the requirement for one extra using statement.

Widow

What happens if I want to use another Dog class from another namespace? I think that it's not a good practice to have interfaces and implementation in the same namespace. – Appraise

Answer 3

What I generally do is to create an Interfaces namespace at a high level in my hierarchy and put all interfaces in there (I do not bother to nest other namespaces in there as I would then end up with many namespaces containing only one interface).

Interfaces
|--IAnimal
|--IVegetable
|--IMineral
MineralImplementor
Organisms
|--AnimalImplementor
|--VegetableImplementor

This is just the way that I have done it in the past and I have not had many problems with it, though admittedly it might be confusing to others sitting down with my projects. I am very curious to see what other people do.

Gimp

Answer 4

I prefer to keep my interfaces and implementation classes in the same namespace. When possible, I give the implementation classes internal visibility and provide a factory (usually in the form of a static factory method that delegates to a worker class, with an internal method that allows a unit tests in a friend assembly to substitute a different worker that produces stubs). Of course, if the concrete class needs to be public--for instance, if it's an abstract base class, then that's fine; I don't see any reason to put an ABC in its own namespace.

On a side note, I strongly dislike the .NET convention of prefacing interface names with the letter 'I.' The thing the (I)Foo interface models is not an ifoo, it's simply a foo. So why can't I just call it Foo? I then name the implementation classes specifically, for example, AbstractFoo, MemoryOptimizedFoo, SimpleFoo, StubFoo etc.

Aricaarick

Tat's quite complicated, though I can see how it would be effective. I've also always wondered why people grumbled about the I.. convention, that makes pretty good sense actually – Gimp

It's simple: your foo is not Foo, but generally just the implementation of its part. When IFoo's concrete implementation is just implementing IFoo and nothing more is merely a subcase so why create separate rules for a statistically insignificant subcase? interface is like an access point to some functionality of interface-implementing class. The same may be said about foo object -- it's like control panel for some concrete object, not the object itself. – Ranique

Answer 5

(.Net) I tend to keep interfaces in a separate "common" assembly so I can use that interface in several applications and, more often, in the server components of my apps.

Regarding namespaces, I keep them in BusinessCommon.Interfaces.

I do this to ensure that neither I nor my developers are tempted to reference the implementations directly.

Kg

I too do it this way. It has the additional side effect of being able to have "circular references" using dependency injection: Foo depends on Bar, Bar depends on IFoo (which resides in a common assembly) and Foo is injected into Bar via DI. voila. – Amorita

If you don't want them to reference the implementations that's an accessibility issue not a namespace issue. They should be marked as Internal. – Commodity

Answer 6

Separate the interfaces in some way (projects in Eclipse, etc) so that it's easy to deploy only the interfaces. This allows you to provide your external API without providing implementations. This allows dependent projects to build with a bare minimum of externals. Obviously this applies more to larger projects, but the concept is good in all cases.

Solitta

Answer 7

I usually separate them into two separate assemblies. One of the usual reasons for a interface is to have a series of objects look the same to some subsystem of your software. For example I have all my Reports implementing the IReport Interfaces. IReport is used is not only used in printing but for previewing and selecting individual options for each report. Finally I have a collection of IReport to use in dialog where the user selects which reports (and configuring options) they want to print.

The Reports reside in a separate assembly and the IReport, the Preview engine, print engine, report selections reside in their respective core assembly and/or UI assembly.

If you use the Factory Class to return a list of available reports in the report assembly then updating the software with new report becomes merely a matter of copying the new report assembly over the original. You can even use the Reflection API to just scan the list of assemblies for any Report Factories and build your list of Reports that way.

You can apply this techniques to Files as well. My own software runs a metal cutting machine so we use this idea for the shape and fitting libraries we sell alongside our software.

Again the classes implementing a core interface should reside in a separate assembly so you can update that separately from the rest of the software.

Persevere

Answer 8

I give my own experience that is against other answers.

I tend to put all my interfaces in the package they belongs to. This grants that, if I move a package in another project I have all the thing there must be to run the package without any changes.

For me, any helper functions and operator functions that are part of the functionality of a class should go into the same namespace as that of the class, because they form part of the public API of that namespace.

If you have common implementations that share the same interface in different packages you probably need to refactor your project.

Sometimes I see that there are plenty of interfaces in a project that could be converted in an abstract implementation rather that an interface.

So, ask yourself if you are really modeling a type or a structure.

Inhalator

Answer 9

A good example might be looking at what Microsoft does.

Assembly: System.Runtime.dll

System.Collections.Generic.IEnumerable<T>

Where are the concrete types?

Assembly: System.Colleections.dll

System.Collections.Generic.List<T>
System.Collections.Generic.Queue<T>
System.Collections.Generic.Stack<T>
// etc

Assembly: EntityFramework.dll

System.Data.Entity.IDbSet<T>

Concrete Type?

Assembly: EntityFramework.dll

System.Data.Entity.DbSet<T>

Further examples

Microsoft.Extensions.Logging.ILogger<T>
- Microsoft.Extensions.Logging.Logger<T>
Microsoft.Extensions.Options.IOptions<T>
- Microsoft.Extensions.Options.OptionsManager<T>
- Microsoft.Extensions.Options.OptionsWrapper<T>
- Microsoft.Extensions.Caching.Memory.MemoryCacheOptions
- Microsoft.Extensions.Caching.SqlServer.SqlServerCacheOptions
- Microsoft.Extensions.Caching.Redis.RedisCacheOptions

Some very interesting tells here. When the namespace changes to support the interface, the namespace change Caching is also prefixed to the derived type RedisCacheOptions. Additionally, the derived types are in an additional namespace of the implementation.

Memory -> MemoryCacheOptions
SqlServer -> SqlServerCatchOptions
Redis -> RedisCacheOptions

This seems like a fairly easy pattern to follow most of the time. As an example I (since no example was given) the following pattern might emerge:

CarDealership.Entities.Dll

CarDealership.Entities.IPerson
CarDealership.Entities.IVehicle
CarDealership.Entities.Person
CarDealership.Entities.Vehicle

Maybe a technology like Entity Framework prevents you from using the predefined classes. Thus we make our own.

CarDealership.Entities.EntityFramework.Dll

CarDealership.Entities.EntityFramework.Person
CarDealership.Entities.EntityFramework.Vehicle
CarDealership.Entities.EntityFramework.SalesPerson
CarDealership.Entities.EntityFramework.FinancePerson
CarDealership.Entities.EntityFramework.LotVehicle
CarDealership.Entities.EntityFramework.ShuttleVehicle
CarDealership.Entities.EntityFramework.BorrowVehicle

Not that it happens often but may there's a decision to switch technologies for whatever reason and now we have...

CarDealership.Entities.Dapper.Dll

CarDealership.Entities.Dapper.Person
CarDealership.Entities.Dapper.Vehicle
//etc

As long as we're programming to the interfaces we've defined in root Entities (following the Liskov Substitution Principle) down stream code doesn't care where how the Interface was implemented.

More importantly, In My Opinion, creating derived types also means you don't have to consistently include a different namespace because the parent namespace contains the interfaces. I'm not sure I've ever seen a Microsoft example of interfaces stored in child namespaces that are then implement in the parent namespace (almost an Anti-Pattern if you ask me).

I definitely don't recommend segregating your code by type, eg:

MyNamespace.Interfaces
MyNamespace.Enums
MyNameSpace.Classes
MyNamespace.Structs

This doesn't add value to being descriptive. And it's akin to using System Hungarian notation, which is mostly if not now exclusively, frowned upon.

Commodity

Answer 10

I HATE when I find interfaces and implementations in the same namespace/assembly. Please don't do that, if the project evolves, it's a pain in the ass to refactor.

When I reference an interface, I want to implement it, not to get all its implementations.

What might me be admissible is to put the interface with its dependency class(class that references the interface).

EDIT: @Josh, I juste read the last sentence of mine, it's confusing! of course, both the dependency class and the one that implements it reference the interface. In order to make myself clear I'll give examples :

Acceptable :

Interface + implementation :

namespace A;

   Interface IMyInterface
   {
       void MyMethod();
   }

namespace A;

   Interface MyDependentClass
   {
       private IMyInterface inject;

       public MyDependentClass(IMyInterface inject)
       {
           this.inject = inject;
       }

       public void DoJob()
       {
           //Bla bla
           inject.MyMethod();
       }
   }

Implementing class:

namespace B;

   Interface MyImplementing : IMyInterface
   {
       public void MyMethod()
       {
           Console.WriteLine("hello world");
       }
   }

NOT ACCEPTABLE:

namespace A;

   Interface IMyInterface
   {
       void MyMethod();
   }

namespace A;

   Interface MyImplementing : IMyInterface
   {
       public void MyMethod()
       {
           Console.WriteLine("hello world");
       }
   }

And please DON'T CREATE a project/garbage for your interfaces ! example : ShittyProject.Interfaces. You've missed the point!

Imagine you created a DLL reserved for your interfaces (200 MB). If you had to add a single interface with two line of codes, your users will have to update 200 MB just for two dumb signaturs!

Shantishantung

You had me until the last sentence, which seems to contradict the rest of your answer. Care to clarify? – Burkley