No. Encapsulation doesn't insist that an object "not know anything about the outside world." It generally says two things:

• Other objects don't need to know how an objects does what it says it does.
• All methods and attributes related only to serving a particular class are contained in that class.

The second point is often stated in various manners that can gives an impression that objects shouldn't rely on outside stuff; but this is a highly impractical understanding, if not an impossible one. Consider a really basic class:

class Document {
  public String Title;
  public String Body;
}

Even without any further definition, our Document class already knows about "outside" things: It knows about Strings! (String is an externally defined class.) And, ignoring the potential XSS issues for a moment, we might make a method that looks like this:

public String GetHtmlBlurb() {
  return "<div><b>" + Title.Substring(0, 60) + "</b> "
    + body.Substring(0, 120) + "</div>";
}

The Substring method doesn't exist in our Document definition either! It's an externally defined method in the String class! But, this is perfectly expected, acceptable, generally necessary OO code. With the exception of classes built exclusively around primitives (do primitives really even exist in .NET?), a class is defined in terms of other classes (external stuff, the outside world, etc.).

Regarding delegates, we could have similarly defined our Document to work with a variety of Body types we have no other information about. All we might require is some way of producing a substring wherein there are multiple ways of doing so (perhaps one version adds elipses in certain cases). All our Document cares about is the ability to call some method that claims to be a Subtring-like method.

class Document {
  public String Title;
  public Func<Int32, Int32, String> BodySubstring;

  public String GetHtmlBlurb() {
    return "<div><b>" + Title.Substring(0, 60) + "</b> "
      + BodySubstring(0, 120) + "</div>";
  }
}

In brief: A delegate is just a reference to a method, rather than the full object we might otherwise include as a property. The difference is that our delegate doesn't require the object to be of a certain type: only of a certain signature. Our class doesn't know what the object does and doesn't insist on knowing anything about it. So, in that respect, it actually knows less about "the outside world."

Perhaps it's not an infringement on encapsulation. Perhaps it's uberencapsulation.

No. Encapsulation doesn't insist that an object "not know anything about the outside world." It generally says two things:

• Other objects don't need to know how an objects does what it says it does.
• All methods and attributes related only to serving a particular class are contained in that class.

The second point is often stated in various manners that can gives an impression that objects shouldn't rely on outside stuff; but this is a highly impractical understanding, if not an impossible one. Consider a really basic class:

class Document {
  public String Title;
  public String Body;
}

Even without any further definition, our Document class already knows about "outside" things: It knows about Strings! (String is an externally defined class.) And, ignoring the potential XSS issues for a moment, we might make a method that looks like this:

public String GetHtmlBlurb() {
  return "<div><b>" + Title.Substring(0, 60) + "</b> "
    + body.Substring(0, 120) + "</div>";
}

The Substring method doesn't exist in our Document definition either! It's an externally defined method in the String class! But, this is perfectly expected, acceptable, generally necessary OO code. With the exception of classes built exclusively around primitives (do primitives really even exist in .NET?), a class is defined in terms of other classes (external stuff, the outside world, etc.).

Regarding delegates, we could have similarly defined our Document to work with a variety of Body types we have no other information about. All we might require is some way of producing a substring wherein there are multiple ways of doing so (perhaps one version adds elipses in certain cases). All our Document cares about is the ability to call some method that claims to be a Subtring-like method.

class Document {
  public String Title;
  public Func<Int32, Int32, String> BodySubstring;

  public String GetHtmlBlurb() {
    return "<div><b>" + Title.Substring(0, 60) + "</b> "
      + BodySubstring(0, 120) + "</div>";
  }
}

In brief: A delegate is just a reference to a method, rather than the full object we might otherwise include as a property. The difference is that our delegate doesn't require the object to be of a certain type: only that a particular method have a certain signature. Our class doesn't know what the object does and doesn't insist on knowing anything about it. So, in that respect, it actually knows less about "the outside world."

Perhaps it's not an infringement on encapsulation. Perhaps it's uberencapsulation.