Encapsulation and delegate contravariance - shouldn't it be the responsibility of a programmer to...

Question

1) One reason to use encapsulation is that by hidding internal implementation details we are able to modify this details without breaking the existing code – this makes perfect sense

a) But I don't understand the argument that encapsulation should be used in order to prevent users from setting the internal data of an object into an invalid or incosistent state.

If I write a class and sell it to other programmers ( who implement this class into their own applications ), then shouldn't they be responsible to access this object in a correct way? After all, if they don't use the object correctly then it will only be their applications that will suffer because of it.

An analogy ( a bad one ) of me having to implement encapsulation for the sake of other programmers not putting internal data ( either accidentally or on purpose )into incosistent state, would be selling water proof TVs just in case buyers decide to swim with their TV sets.

2) From

http://blogs.msdn.com/b/ericlippert/archive/2007/10/19/covariance-and-contravariance-in-c-part-three-member-group-conversion-variance.aspx

void Foo(Giraffe g) {}
void Bar(Animal a) {}

Action<Mammal> action1 = Foo; // illegal 
Action<Mammal> action2 = Bar; // legal

Why is the first assignment illegal? Because the caller of action1 can pass a Tiger, but Foo cannot take a Tiger, only a Giraffe! The second assignment is legal because Bar can take any Animal.«

I understand author's reasoning on why Action<Mammal> action1 shouldn't be able to accept Foo(). But on the other hand, shouldn't it be the programmer's responsibility to not pass into delegate any arguments that registered methods can't handle?

Thus, if some programer registers method Foo, then they will also know :

• not to call action1 delegate with anything else than with Giraffe argument

• Not to register methods with different signature than Foo ( except if method defines as its parameter a type from which Mammal derives )

thanx

Answer 1

You've really asked two questions here, which would have been better separated.

It sounds like you really don't care about type safety, or trying to steer people towards success.

The second question is easy to answer in a very concrete way though:

I understand author's reasoning on why Action<Mammal> action1 shouldn't be able to accept Foo(). But on the other hand, shouldn't it be the programmer's responsibility to not pass into delegate any arguments that registered methods can't handle?

Which programmer? The one creating the instance of Action<Mammal>, or the one calling it? These could be two very different programmers, working in completely different libraries. Why should the programmer using an Action<Mammal> have to worry that the delegate might not actually be able to work on any Mammal? The whole point of type safety is to guarantee that things will work appropriately... that you can't create a delegate which will go bang at execution time due to a type mismatch.

If you don't care about type safety at compile time, perhaps you should try a dynamically typed language instead.

Answer 2

One of the advantages of good encapsulation is to "force" the user of the class to use it in the proper way, and not in any other possible way. This way, the user is less frustrated about the code he has to (re)use. The productivity increases (less time spent figuring out why the code breaks, especially if the source code is not available), etc.

If I have to buy a library from someone, and I have to be very careful on how I have to use it at each step, I would consider that I wasted money.

(I excluded the library design topics, stability, maintainability and extensibility. I am mortal, and the time to cover these aspects is limited :)...)

Answer 3

I think your code should always be type-safe. To take up your example: person A writes a class R and sells it to person B. Person A has no way of controlling, what person B does with that class. B may extend class R to another class S and sell it on to other people. There is no way to make sure, that the non-type-safe class A produced, will work appropriatly for everyone using Bs class S.

Answer 4

Your TV set analogy implies that you would need to anticipate every possible scenario in which your code is used, which is impossible. Instead, think of what you're doing as making your intent obvious. You know these details about the usage of the object, so why not encapsulate them instead of putting the onus on the consumer?

Another analogy is that you could have no door in your doorway and declare that it is the world's responsibility not to come inside; that won't change the the power of an open door to spark curiosity in people. A door means "you are not allowed to enter this house" without people finding out by walking inside at runtime and you throwing an AccessDeniedException. The intent of a door is quite obvious.

Answer 5

I guess it's best expressed in code: so here goes (the point is in the comment in the last part)

disclaimer: the code does not compile and should not be able to

public interface AnimalHandler
{
   Action<Mammal> Feed{get;}
}


public class CreatedInFarAwayFromYou : AnimalHandler
{
  private void Foo(Giraffe g) {}
  public Action<Mammal> Feed
  {
     return Foo;
  }
}

public class MadeByYou
{

  private IEnumerable<Tiger> tigers;
  AnimalHandler handler;
  public void FeedAll()
  {
    foreach(var animal in tigers)
    {
       //You are by your reasoning at fault here. Not the dev that made CreatedInFarAwayFromYou 
       Feed(animal); 
    }
  }
}