I thought so — thanks for clearing me up.

–Jason

That’s exactly what I mean.

Much like the free functions of C++ in Meyer’s article, extension methods can be seen as an optional part of a type’s API. And is a technique that improve’s a type’s encapsulation. The reason I don’t call the class in which extension methods are defined “a type”, is because it effectively isn’t — at least, not in a way that matters to a C# (or VB) programmer — it’s neither instantiable, nor inheritable. Instead, it’s a bit of a “language trick” that gives us the ability to define free functions and procedures (the static class is how you define a C# equivalent of a VB Module).

When I say extension methods should be “correctly written”, I mean all the methods in the static class in which we define extensions must only use types available in the api of the type it extends. If we want to introduce extension methods that interact with a type our original class doesn’t already know about, we should create new extension methods in a new static class. By partitioning things this way, we keep our dependencies focused, tight and flexible.

I’m struggling to understand what you are trying to convey here. Technically, extension methods are an additional type and are not part of the interface or type they extend. Since I assume you understand this, I’m guessing you mean they are part of the interface or type in the sense that they are part of the overall API available for working with the type.

you’re right about the point of LoD and that the code within the extension methods is what we are concerned with, not the fact that we have an extension method. I kinda-sort-of-almost hinted at what you’re saying when I said “There probably are scenarios where the implementation of an extension method would violate LoD and thus the extension itself would”… having read the responses of others, and your response here, it’s obvious that i left out some of the more important aspects of the principle and made some sweeping generalizations based on one specific circumstance, again.

great response! it got me thinking more about _why_ i said what i said, and provided some new ideas in understanding LoD.