Я НЕНАВИЖУ, когда я нахожу интерфейсы и реализации в том же пространстве имен/сборке. Пожалуйста, не делайте этого, если проект развивается, это боль в заднице для рефакторинга.
Когда я обращаюсь к интерфейсу, я хочу его реализовать, а не получить все его реализации.
Что может быть допустимым, это установить интерфейс с классом зависимостей (, который ссылается на интерфейс).
EDIT: @Josh, я только что прочитал последнее предложение, это запутанно! конечно, как класс зависимостей, так и тот, который его реализует, ссылается на интерфейс.Для того, чтобы сделать себе ясно, что я приведу примеры:
Приемлемая:
Интерфейс + реализации:
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();
}
}
Реализация класса:
namespace B;
Interface MyImplementing : IMyInterface
{
public void MyMethod()
{
Console.WriteLine("hello world");
}
}
НЕПРИЕМЛЕМО:
namespace A;
Interface IMyInterface
{
void MyMethod();
}
namespace A;
Interface MyImplementing : IMyInterface
{
public void MyMethod()
{
Console.WriteLine("hello world");
}
}
И НЕ СОЗДАВАЙТЕ проект/мусор для ваших интерфейсов! Пример: ShittyProject.Interfaces. Вы пропустили суть!
Представьте, что вы создали DLL, зарезервированную для ваших интерфейсов (200 МБ). Если вам нужно было добавить один интерфейс с двумя строками кодов, вашим пользователям придется обновлять 200 МБ только для двух немых сигнатур!
Что произойдет, если я хочу использовать другой класс Dog из другого пространства имен? Я считаю, что не очень хорошая практика иметь интерфейсы и реализацию в одном и том же пространстве имен. – 2012-04-26 15:35:31