Метод скрывается с интерфейсами

Question

interface IFoo
{
    int MyReadOnlyVar { get; }
}


class Foo : IFoo
{
    int MyReadOnlyVar { get; set; }
}


public IFoo GetFoo()
{
    return new Foo { MyReadOnlyVar = 1 };
}

Является ли вышеуказанный приемлемый способ реализации объекта только для чтения / неизменяемого?Неизменность IFoo может быть нарушена с помощью временного приведения к Foo.

В общих (некритических) случаях скрывает ли функциональность через интерфейсы общий шаблон?Или это считается ленивым кодированием?Или даже анти-шаблон?

Answer 1

Использование интерфейсов для сокрытия делает интерфейс класса меньше, это правильное использование. Я видел много такого кода в приложениях Spring, где зависимости выражаются только в классе (и используются инъекцией зависимостей Spring), а не в интерфейсе, потому что они ничего не предоставляют для домена.

Вы не можете защитить свой код от других кодеров. Если вы боитесь, что кто-то приведёт интерфейс к изменяемой версии, то же самое может произойти, если вы вернете настоящий снимок только для чтения, а кто-то из вашей команды добавит в него методы мутации.

Это также зависит от вашего кода. Внутри проекта / приложения вы можете доверять своим коллегам. При разработке фреймворка все иначе. Затем вы должны решить, следует ли всегда возвращать «сохраненные» объекты, например, клоны списков вместо реальных списков, которые могут быть изменены.

Так что да, в общих (некритических) случаях, ИМХО, уместно делать это по-своему.

Answer 2

Вы можете сделать класс Foo видимым только на уровне сборки (внутренний в C #) или сделать настройщик внутреннего MyReadonlyVar, чтобы ваш код был защищен от ненужных приведений вне сборки.