Liskov Замена Принцип и избыточные методы

Question

У меня есть интерфейс под названием IRepository. Этот интерфейс определяет набор таких общих методов, как:

IQueryable<T> Get<T>() where T : class; 
void Add<T>(T obj) where T : class; 
void Update<T>(T obj) where T : class; 
void SaveChanges(); 

У меня тогда есть класс, который реализует этот интерфейс. Этот класс фактически использует Entity Framework для реализации этих методов. Однако обновление метода избыточно, поскольку Entity Framework отслеживает изменения, сделанные для получаемых объектов, поэтому я просто получаю объект, который я хочу, обновляю, а затем вызываю SaveChanges. Однако в будущем я, возможно, захочу заменить эту конкретную реализацию IRepository чем-то другим. Который, вероятно, не будет отслеживать изменения, такие как инфраструктура Entity. Поэтому я думаю, что хочу оставить метод обновления в интерфейсе, но в моей конкретной реализации этого интерфейса просто оставьте метод, но ничего не делайте. например

public void Update<T>(T obj) where T : class 
{ 
} 

Это, кажется, в соответствии с Лисков принцип замещения, я могу заменить реализацию интерфейса с чем-то еще. Просто для того, чтобы некоторые вещи могли реализовать все методы, определенные на интерфейсе, возможно, не понадобилось.

Это хороший подход. Я думал, что это нормально, может быть, даже обозначить метод как устаревший в реализации IRepository, заявляя, почему он устарел в этой реализации.

Как-то странно, если у вас есть метод обновления, который ничего не делает, и это вызвано всем приложением, даже если оно на самом деле ничего не делает. Но тогда, если мы изменили реализацию IRepository, к внедрению, которое действительно нуждается в методе обновления, мы можем заменить это без необходимости изменения кода.

Answer 1

IMHO, имеющий метод на интерфейсе, который не реализован в большинстве ситуаций, говорит мне, что область интерфейса слишком широка.

Вы можете удалить метод обновления из базового интерфейса репозитория и добавить его самостоятельно в IUpdatableRepository, который наследуется от базового интерфейса. Таким образом, конкретные классы, которые необходимо обновить, могут затем реализовать интерфейс IUpdatableRepository.

Это не может быть именно то, что вы ищете, но вы получите точку ...

Answer 2

Если я вас правильно понимаю, у вас есть одна реализация которой вы завернутые в интерфейсе. LSP - это не единственное, о чем можно беспокоиться в дизайне: я бы сказал, что KISS и YAGNI являются более фундаментальными, тогда как LSP - это всего лишь способ сохранить вещи простыми и предсказуемыми в объектно-ориентированном дизайне. Попытка разработать для любые Возможные будущие изменения в вашей системе на самом деле будут делать вашу систему сложнее изменить из-за повышенной сложности. Возможно, вы замените репозиторий альтернативной реализацией, которая нуждается в методе обновления? Тогда непременно сохраните его. Если это только возможность, отключите его прямо сейчас (и, возможно, подумайте об использовании EF напрямую).

В конце концов, «Вы можете решить каждую проблему, добавив еще один слой абстракции, за исключением слишком большого количества абстракций».