Liskov替代原理和冗余方法

Question

I have an interface called IRepository. This interface defines a set of generic methods such as:

 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();

I then have a class which implements this interface. This class actually uses Entity Framework to implement these methods. However the method update is redundant as the Entity Framework tracks changes made to entities retrieved so I just get the entity I want, update it then call SaveChanges. However in the future I may want to replace this concrete implementation of IRepository with something else. Which probably won't track changes like Entity framework does. So I'm thinking I want to leave the update method in the interface, but in my concrete implementation of this interface just leave the method in but doing nothing. eg

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

This seems to fit with the Liskov Substitution Principle, I can replace the implementation of the interface with something else. It's just that somethings might not need to actually implement all the methods defined on the interface.

Is this a good approach. I was thinking this was okay maybe even mark the method as obsolete in the implementation of IRepository stating why it is obsolete in this implementation.

It just seems a bit odd having an update method which does nothing and having this called all over the application even though it doesn't actually do anything. But then if we changed the implemenation of IRepository, to an implmentation that does need an update method then we can substitute this in with no code changes required.

Answer 1

IMHO, having a method on a an interface that is not implemented in most situations tells me that the scope of the interface is too wide.

You could remove the update method from the base repository interface and add it alone to an IUpdatableRepository that inherits from the base interface. You concrete classes that need to update can then implement the IUpdatableRepository interface instead.

This may not be exactly what you're looking for, but you get the point...

Answer 2

If I understand you correctly, you have a single implementation which you've wrapped in an interface. LSP isn't the only thing to worry about in design: I would argue that KISS and YAGNI are more fundamental, whereas LSP is only a way of keeping things simple and predictable in an object oriented design. Trying to design for any conceivable future change in your system will actually tend to make your system harder to change due to increased complexity. Are you reasonably likely to replace your repository with an alternate implementation which needs the Update method? Then by all means, retain it. If it's only a possibility, strip it out right now (and, possibly, consider using EF directly).

After all, "You can solve every problem by adding another layer of abstraction, except too many layers of abstraction."