초기 및 후기 바인딩

초기 및 후기 바인딩

---

C #에서 초기 / 늦은 바인딩이 발생할 때 머리를 돌리려고합니다.

비가 상 방법은 항상 초기에 바인딩됩니다. 가상 메서드는 항상 늦게 바인딩됩니다. 컴파일러는 실행시 바인딩 할 실제 메서드를 확인하기 위해 추가 코드를 삽입하고 형식 안전성을 확인합니다. 따라서 하위 유형 다형성은 후기 바인딩을 사용합니다.

리플렉션을 사용한 메서드 호출은 후기 바인딩의 예입니다. 컴파일러가 아니라이를 달성하기 위해 코드를 작성합니다. (예 : COM 구성 요소 호출)

VB.NET은 Option Strict가 꺼져있을 때 암시 적 후기 바인딩을 지원합니다. 객체는 Object 유형으로 선언 된 변수에 할당 될 때 후기 바인딩됩니다. VB 컴파일러는 실행시 올바른 메서드에 바인딩하고 잘못된 호출을 포착하는 코드를 삽입합니다. C #은이 기능을 지원하지 않습니다.

올바른 방향으로 가고 있습니까?

대리자를 호출하고 인터페이스 참조를 통해 메서드를 호출하는 것은 어떻습니까? 그게 일찍 또는 늦게 구속됩니까?

---

Reflection 인터페이스를 거치지 않는 한 모든 것이 C #에서 조기 바인딩됩니다.

얼리 바운드는 컴파일 타임에 타겟 메소드가 발견되고이를 호출하는 코드가 생성된다는 것을 의미합니다. 가상 여부 (통화 시간에 찾을 수있는 추가 단계가 있음을 의미 함). 메서드가 없으면 컴파일러는 코드를 컴파일하지 못합니다.

Late bound는 대상 메서드가 런타임에 조회됨을 의미합니다. 종종 메서드의 텍스트 이름을 사용하여 검색합니다. 방법이 없으면 쾅. 프로그램은 런타임에 충돌하거나 일부 예외 처리 체계로 이동합니다.

대부분의 스크립트 언어는 후기 바인딩을 사용하고 컴파일 된 언어는 초기 바인딩을 사용합니다.

C # (버전 4 이전)은 늦게 바인딩하지 않습니다. 그러나 리플렉션 API를 사용하여 수행 할 수 있습니다. 이 API는 런타임에 어셈블리를 파헤쳐 함수 이름을 찾는 코드로 컴파일됩니다. Option Strict가 해제 된 경우 VB는 지연 바인딩 할 수 있습니다.

바인딩은 일반적으로 성능에 영향을 미칩니다. 후기 바인딩에는 런타임에 조회가 필요하기 때문에 일반적으로 메서드 호출이 초기 바인딩 된 메서드 호출보다 느리다는 것을 의미합니다.

---

일반 함수의 경우 컴파일러는 메모리에서 숫자 위치를 계산할 수 있습니다. 그런 다음 함수가 호출 될 때이 주소에서 함수를 호출하는 명령을 생성 할 수 있습니다.

가상 메서드가있는 개체의 경우 컴파일러는 v 테이블을 생성합니다. 이것은 본질적으로 가상 메소드의 주소를 포함하는 어레이입니다. 가상 메서드가있는 모든 개체에는 v 테이블의 주소 인 컴파일러에 의해 생성 된 숨겨진 멤버가 포함됩니다. 가상 함수가 호출되면 컴파일러는 v 테이블에서 적절한 메서드의 위치가 무엇인지 알아냅니다. 그런 다음 객체 v-table을 살펴보고이 위치에서 가상 메서드를 호출하는 코드를 생성합니다.

따라서 가상 기능에 대해 발생하는 조회가 있습니다. 이것은 매우 최적화되어 있으므로 런타임에 매우 빠르게 발생합니다.

조기 바인딩

• 컴파일러는 컴파일 타임에 호출 된 함수가 어디에 있는지 알아낼 수 있습니다.
• 컴파일러는 함수가 존재하고 런타임에 호출 가능하다는 것을 조기에 (프로그램 코드가 실행되기 전에) 보장 할 수 있습니다.
• 컴파일러는 함수가 올바른 수의 인수를 취하고 올바른 유형인지를 보장합니다. 또한 반환 값이 올바른 유형인지 확인합니다.

늦은 바인딩

• 단순한 오프셋 계산이 아니기 때문에 조회 시간이 더 오래 걸리며 일반적으로 텍스트 비교가 필요합니다.
• 대상 기능이 없을 수 있습니다.
• 대상 함수는 전달 된 인수를 받아들이지 않을 수 있으며 잘못된 유형의 반환 값을 가질 수 있습니다.
• 일부 구현에서는 대상 메서드가 실제로 런타임에 변경 될 수 있습니다. 따라서 조회는 다른 기능을 실행할 수 있습니다. Ruby 언어에서 이런 일이 발생한다고 생각합니다. 프로그램이 실행되는 동안 객체에 새로운 메서드를 정의 할 수 있습니다. 지연 바인딩을 사용하면 함수 호출이 기존 기본 메서드를 호출하는 대신 메서드에 대한 새 재정의 호출을 시작할 수 있습니다.

---

C # 3은 초기 바인딩을 사용합니다.

C # 4는 dynamic키워드를 사용하여 후기 바인딩을 추가 합니다. 자세한 내용 은 주제에 대한 Chris Burrow의 블로그 항목 을 참조하십시오.

가상 방법과 비가 상 방법의 경우 이것은 다른 문제입니다. 을 호출 string.ToString()하면 C # 코드가 가상 object.ToString()메서드에 바인딩됩니다 . 호출자의 코드는 개체 유형에 따라 변경되지 않습니다. 오히려 가상 메서드는 함수 포인터 테이블을 통해 호출됩니다. 개체의 인스턴스는 개체의 ToString()메서드를 가리키는 개체의 테이블을 참조합니다 . 문자열의 인스턴스에는 해당 메서드를 가리키는 가상 메서드 테이블이 ToString()있습니다. 예, 이것은 다형성입니다. 그러나 그것은 늦은 구속력이 아닙니다.

---

대부분의 경우 조기 바인딩은 우리가 매일하는 일입니다. 예를 들어, Employee컴파일 타임에 사용할 수 있는 클래스 가있는 경우 해당 클래스의 인스턴스를 만들고 인스턴스 멤버를 호출하기 만하면됩니다. 이것은 초기 바인딩입니다.

//Early Binding
**Employee** employeeObject = new **Employee**();
employeeObject.CalculateSalary();

반면에 컴파일 타임에 클래스에 대한 지식이 없다면 리플렉션을 사용하여 늦게 바인딩하는 것이 유일한 방법입니다. 저는 이러한 개념을 설명하는 훌륭한 비디오를 보았습니다 . 여기 링크가 있습니다.

---

매우 오래된 게시물이지만 더 많은 정보를 추가하고 싶었습니다. 레이트 바인딩은 컴파일 타임에 개체를 인스턴스화하고 싶지 않을 때 사용됩니다. 에서 C#당신이 사용하는 Activator런타임에 바인딩 개체를 호출 할 수 있습니다.

---

초기 바인딩

이름 자체는 컴파일러가 어떤 종류의 객체인지, 포함 된 모든 메서드와 속성에 대해 알고 있음을 설명합니다. 개체를 선언하자마자 .NET Intellisense는 점 버튼을 클릭하면 해당 메서드와 속성을 채 웁니다.

일반적인 예 :

ComboBox cboItems;

ListBox lstItems; 위의 예에서 cboItem을 입력하고 뒤에 점을 배치하면 컴파일러가 이미 콤보 상자임을 알고 있기 때문에 콤보 상자의 모든 메서드, 이벤트 및 속성이 자동으로 채워집니다.

늦은 바인딩

이름 자체는 컴파일러가 어떤 종류의 객체인지, 포함 된 모든 메서드와 속성을 알지 못한다고 설명합니다. 객체로 선언해야하며 나중에 객체의 유형, 저장된 메소드를 가져와야합니다. 모든 것은 런타임에 알려집니다.

일반적인 예 :

개체 objItems;

objItems = CreateObject ( "DLL 또는 어셈블리 이름"); 여기서 컴파일 시간 동안 objItems 유형은 결정되지 않습니다. 우리는 dll의 객체를 생성하고 objItems에 할당하고 있으므로 모든 것이 런타임에 결정됩니다.

초기 바인딩 vs. 후기 바인딩

이제 그림 속으로 ...

Application will run faster in Early binding, since no boxing or unboxing are done here.

Easier to write the code in Early binding, since the intellisense will be automatically populated

Minimal Errors in Early binding, since the syntax is checked during the compile time itself.

Late binding would support in all kind of versions, since everything is decided at the run time.

Minimal Impact of code in future enhancements, if Late Binding is used.

Performance will be code in early binding. Both have merits and demerits, it's the developer decision to choose the appropriate binding based on the scenario.

---

In very simple terms, early binding happens at compile time and the compiler has the knowledge about the type and all it's members, and late binding happens at run time, the compiler doesn't know anything about the type and it's members. I have come across an excellent video on youtube which explains these concepts.

http://www.youtube.com/watch?v=s0eIgl5iqqQ&list=PLAC325451207E3105&index=55&feature=plpp_video

http://www.youtube.com/playlist?list=PLAC325451207E3105

---

This article is a guide to building a .net component ,using it in a Vb6 project at runtime using late binding, attaching it's events and get a callback.

http://www.codeproject.com/KB/cs/csapivb6callback2.aspx

This article is a guide to building a .NET component and using it in a VB6 project. There are many samples about this issue, so why did I write a new one? In my humble opinion, in other articles, the missing part is to attach its event at runtime. So in this article, we will build a .NET component, mark it as a COM visible component, use it at runtime in VB6 and attach to its events.

https://www.codeproject.com/Articles/37127/Internet-Explorer-Late-Binding-Automation

Most developers often need Internet Explorer automation, which basically means opening a browser, filling some forms, and posting data programmatically.

The most common approach is to use shdocvw.dll (the Microsoft Web Browser control) and Mshtml.dll (the HTML Parsing and Rendering Component), or Microsoft.Mshtml.dll which is actually a .NET wrapper for Mshtml.dll. You can get more information about Internet Explorer - About the Browser here.

If you pick the above method and DLLs, let's see some of the problems you may have to deal with:

You have to distribute these DLLs because your project would be dependent to these DLLs, and this is a serious problem if you cannot deploy them correctly. Simply do some Googling about shdocvw and mshtml.dll distributing problems, and you'll see what I'm talking about. You have to deploy an 8 MB Microsoft.mshtml.dll because this DLL is not part of the .NET framework. In this case, what we need to do is use a late binding technique. Writing our own wrappers for the above mentioned DLLs. And of course, we'll do this as it is more useful than using these DLLs. For instance, we won't need to check if the document download operation is complete because IEHelper will do this for us.

참고URL : https://stackoverflow.com/questions/484214/early-and-late-binding