Chociaż jest to pytanie ogólne, jest ono również specyficzne dla problemu, którego obecnie doświadczam. Obecnie w interfejsie mam określony interfejs o nazwie
public interface IContextProvider
{
IDataContext { get; set; }
IAreaContext { get; set; }
}
Ten interfejs jest często używany w całym programie, dlatego mam łatwy dostęp do potrzebnych mi obiektów. Jednak na dość niskim poziomie części mojego programu potrzebuję dostępu do innej klasy, która użyje IAreaContext i wykona niektóre operacje poza tym. Więc stworzyłem inny interfejs fabryczny, aby wykonać to stworzenie o nazwie:
public interface IEventContextFactory
{
IEventContext CreateEventContext(int eventId);
}
Mam klasę, która implementuje IContextProvider i jest wstrzykiwana przy użyciu NinJect. Problem, który mam, polega na tym, że obszar, w którym muszę użyć tego IEventContextFactory, ma dostęp tylko do IContextProvider i sam używa innej klasy, która będzie potrzebowała tego nowego interfejsu. Nie chcę tworzyć instancji tej implementacji IEventContextFactory na niskim poziomie i wolę raczej pracować z interfejsem IEventContextFactory . Jednak nie chcę też wstrzykiwać innego parametru przez konstruktory, aby przekazać go do klasy, która tego potrzebuje, tj
// example of problem
public class MyClass
{
public MyClass(IContextProvider context, IEventContextFactory event)
{
_context = context;
_event = event;
}
public void DoSomething()
{
// the only place _event is used in the class is to pass it through
var myClass = new MyChildClass(_event);
myClass.PerformCalculation();
}
}
Więc moje główne pytanie brzmi: czy byłoby to do przyjęcia, czy jest to nawet powszechna lub dobra praktyka, aby zrobić coś takiego (interfejs rozszerza inny interfejs):
public interface IContextProvider : IEventContextFactory
czy powinienem rozważyć lepszą alternatywę dla osiągnięcia tego, czego potrzebuję. Jeśli nie podałem wystarczających informacji, aby podać sugestie, daj mi znać, a mogę podać więcej.