Мне все еще сложно понять, какие интерфейсы подходят. Я прочитал несколько руководств, и я до сих пор не знаю, что они на самом деле для других, "они заставляют ваши классы хранить promises" и "они помогают с множественным наследованием".
Вот об этом. Я до сих пор не знаю, когда я бы даже использовал интерфейс в реальном примере работы или даже когда определить, когда его использовать.
Из-за моего ограниченного знания интерфейсов они могут помочь, потому что, если что-то реализует его, вы можете просто передать интерфейс, позволяя проходить как разные классы, не беспокоясь о том, что он не является правильным параметром.
Но я никогда не знаю, какова реальная точка этого, поскольку они обычно останавливаются на этом этапе, показывая, что будет делать код после того, как он пройдет через интерфейс, и если они сотворят это, похоже, что они ничего не делают полезными что я мог бы смотреть и идти "ничего себе, они бы помогли в реальном мире".
Итак, я думаю, я говорю, что я пытаюсь найти пример реального мира, где я могу видеть интерфейсы в действии.
Я также не понимаю, что вы можете сделать ссылку на такой объект:
ICalculator myInterface = new JustSomeClass();
Итак, теперь, если я подойду к myInterface, точка и intellisense потянутся, я увижу только методы интерфейса, а не другие методы в JustSomeClass. Поэтому я пока не вижу смысла.
Также я начал выполнять модульное тестирование, где они, похоже, любят использовать интерфейсы, но я до сих пор не понимаю, почему.
Как, например, этот пример:
public AuthenticationController(IFormsAuthentication formsAuth)
{
FormsAuth = formsAuth ?? new FormsAuthenticationWrapper();
}
public class FormsAuthenticationWrapper : IFormsAuthentication
{
public void SetAuthCookie(string userName, bool createPersistentCookie)
{
FormsAuthentication.SetAuthCookie(userName, createPersistentCookie);
}
public void SignOut()
{
FormsAuthentication.SignOut();
}
}
public IFormsAuthentication FormsAuth
{
get;
set;
}
Как и зачем делать этот интерфейс? Почему бы просто не сделать FormsAuthenticationWrapper с помощью методов в нем и назвать его днем? Почему сначала создать интерфейс, а затем Wrapper реализовать интерфейс, а затем, наконец, написать методы?
Тогда я не понимаю, что говорит оператор.
Как я теперь знаю, что утверждение говорит об этом
FormsAuth = formsAuth ?? new FormsAuthenticationWrapper();
если formsAuth имеет значение null, затем создайте новый FormsAuthenticationWrapper и затем назначьте его свойству, являющемуся интерфейсом.
Я думаю, это восходит ко всему вопросу, почему эталонная вещь. Особенно в этом случае, поскольку все методы точно такие же. У Wrapper нет никаких новых методов, которых интерфейс не имеет, и я не уверен, но когда вы делаете это, методы заполняются правильно (т.е. У них есть тело), они не преобразуются в заглушки, потому что это действительно казалось бы бессмысленным мне (он будет преобразован обратно в интерфейс).
Затем в файле тестирования они:
var formsAuthenticationMock = new Mock<AuthenticationController.IFormsAuthentication>();
Поэтому они просто передают в FormsAuthentication то, что я угадываю, делают все поддельные заглушки. Я предполагаю, что класс-оболочка используется, когда программа на самом деле запущена, поскольку у нее есть реальные методы, которые что-то делают (например, подписать человека).
Но, глядя на новый Mock (из moq), он принимает класс или интерфейс. Почему бы просто не сделать так, чтобы класс-оболочка помещал эти методы, а затем в новый Mock-вызов?
Разве это не просто сделает для вас заглушки?
