想写点什么东西，但是又有点懒，先放草稿，不然以后又忘记了:
1.Address类似于虚拟表的内存地址
2.binding对应着CLR类型
3.Contract代表接口。
C#中没有真正意义上的早绑定。
地址无关代码。
代理模式。
按照严格意义上的早起绑定来说，比如C语言在编译的时候，编译器就可以知道某个方法所对应的物理地址。但是C#中，方法在编译时都是一个IL token,指向的都是CLR中的JIT函数。在运行第一遍的时候，JIT才生成native code,这时才有真正的地址，并把地址返回给相应的引用。因此如果按照这个定义来说，C#中没有真正意义上的早绑定。但是，我们这里采用编译时编译器知道相应的类型来算做早起绑定，如果用的是多态特性，如虚方法等，那么就是编译时知道部分类型信息的动态绑定。
和早起绑定相对应的，就是晚绑定。编译时编译器对类型的信息一无所知。
Developers could manually place objects in separate processes, yet if the objects were distributed across multiple processes
or machines there was no way of using raw C++ for the invocations, since C++
required direct memory references and did not support distribution. Developers had
to write host processes and use some remote call technology (such as TCP sockets) to
remote the calls, but such invocations looked nothing like native C++ calls and did not
benefit from object orientation.
The solution for the problems of object orientation evolved over time, involving technologies
such as the static library (.lib) and the dynamic library (.dll), culminating in
1994 with the first component-oriented technology, called COM (Component Object
Model). Component orientation provided interchangeable, interoperable binary components.
With this approach, instead of sharing source files, the client and the server
agree on a binary type system (such as IDL) and a way of representing the metadata
inside the opaque binary components. The components are discovered and loaded at
runtime, enabling scenarios such as dropping a control on a form and having that
control be automatically loaded at runtime on the client’s machine. The client only
programs against an abstraction of the service: a contract called the interface. As long
as the interface is immutable, the service is free to evolve at will. A proxy can implement
the same interface and thus enable seamless remote calls by encapsulating the low-level
mechanics of the remote call. The availability of a common binary type system enables
cross-language interoperability, so a Visual Basic client can consume a C++ COM
component. The basic unit of reuse is the interface, not the component, and polymorphic
implementations are interchangeable. Versioning is controlled by assigning a
unique identifier for every interface, COM object, and type library.
While COM was a fundamental breakthrough in modern software engineering, most
developers found it unpalatable. COM was unnecessarily ugly because it was bolted
on top of an operating system that was unaware of it, and the languages used for writing
COM components (such as C++ and Visual Basic) were at best object-oriented but not
component-oriented. This greatly complicated the programming model, requiring
frameworks such as ATL to partially bridge the two worlds. Recognizing these issues,
Microsoft released .NET 1.0 in 2002. .NET is (in the abstract) nothing more than
cleaned-up COM, MFC, C++, and Windows, all working seamlessly together under a
single new component-oriented runtime. .NET supports all the advantages of COM
and mandates and standardizes many of its ingredients, such as type metadata sharing,
dynamic component loading, serialization, and versioning.
(.NET, Java, etc.) use the client thread to jump into the object. How can you possibly
take a .NET thread and give it to a Java object? The solution is to avoid call-stack
invocation and instead to use message exchange. The technology vendors can standardize
the format of the message and agree on ways to represent transactions, security
credentials, and so on. When the message is received by the other side, the implementation
of the plumbing there will convert the message to a native call (on a .NET or a
Java thread) and proceed to call the object. Consequently, any attempt to standardize
the plumbing has to be message-based.
内容参考自 《程序员的自我修养》 《CLR VIA C#》 《Programming WCF Service》