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

Question

interface IFoo 
{ 
    int MyReadOnlyVar { get; } 
} 


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


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

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

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

Answer 1

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

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

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

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

Answer 2

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