2

Take the following example:

public interface ISerialRVD
{
    RouteValueDictionary ToRVD();
}

public interface IViewModel : ISerialRVD // Here?
{
    Int32 Page { get; set; }
    String Action { get; set; }
}

public class myViewModel : IViewModel, ISerialRVD // Or Here?
{

}

I understand that if I make IViewModel inherit ISerialRVD that is forcing all who implement IViewModel to implement ISerialRVD but should I do just : IViewModel or : IViewModel, ISerialRVD on the class implementing IViewModel?

To my knowledge repeating the ISerialRVD part does not hurt anything, and I want to put it there to make it clearer it's implementing that interface, but if I were to have many more interfaces it would become quite the clutter. Am I wrong?

Is there a sensible way of dealing with this? On one-hand I feel it should be verbose and tell you what you're implementing, but on the other hand it should be infer-able from the interface itself. All IViewModels implement ISerialRVD.

5

Imagine the following cases:

interface IReadable { }

interface IWriteable extends IReadable { }

class MemoryStream implements IWriteable { }

By looking at the signature of MemoryStream only, is it obvious that the stream can be read? Probably not: you may believe that the stream is write-only, unless you know that in that specific business logic, you can always read from a writeable stream.

Thus, declaring both interfaces improves readability in this case.

Now consider another example:

interface IEquatable<T> { }

interface IComparable<T> extends IEquatable<T> { }

class Price implements IComparable<int> { }

Here, the natural thing is to believe that an object which can numerically be compared to another (that is, determine if an object is inferior or superior to another), the object can also be compared strictly to another one (that is, determine if an object is equal to another). Indeed, the second interface extends the first one, matching the expectations.

Thus, declaring both interfaces is redundant in this case.

  • Okay, so it's part intention of design and also part naming. If you were to call it IReadableWritable or something less silly then it would make sense for it to implement just it. This helped me basically connect the dots, thanks! – Shelby115 Jun 24 '15 at 13:49
  • @Shelby115: indeed, IReadableWriteable is a better name, since it is less misleading (especially in a context of a stream, where often reading a stream and writing to it is mutually exclusive). – Arseni Mourzenko Jun 24 '15 at 13:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.