타사 코드는 무엇입니까?

이 질문에서 영감을 얻음 타사 라이브러리 사용-항상 래퍼를 사용합니까? 사람들이 실제로 타사 라이브러리로 무엇을 고려하는지 알고 싶었습니다.

PHP의 예 :
Zend 프레임 워크를 사용하여 응용 프로그램을 빌드하는 경우 Zend 프레임 워크 라이브러리를 타사 코드로 취급해야합니까?

C #의 예 :
데스크톱 응용 프로그램을 구축하는 경우 모든 .Net 클래스를 타사 코드로 취급해야합니까?

Java의 예 :
JDK의 모든 라이브러리를 타사 라이브러리로 취급해야합니까?

어떤 사람들은 도서관이 안정적이고 자주 바뀌지 않는다면 그것을 감쌀 필요가 없다고 말합니다. 그러나 랩핑하지 않고 타사 코드에 의존하는 클래스를 테스트하는 방법을 보지 못했습니다.

예제는 모두 타사 코드이지만 래퍼를 작성해서는 안됩니다. 안정적이고 잘 계획된 API를 갖춘 크고 성숙한 프로젝트입니다.

랩퍼는 코드와 라이브러리 사이에 추상화 계층을 제공해야합니다. 라이브러리가 수행중인 특정 작업에 대해 좋은 API를 제공하지 못한다는 것을 발견 할 때만이 추상화가 필요합니다. 그런 다음 자신의 코드를 단순화하기 위해 랩퍼를 작성하고 API 호출이 어색하다는 사실을 숨길 수 있습니다.

의존성 주입을 사용하면 코드를 테스트 할 수 있습니다. 단위 테스트에서 라이브러리 종속성을 모의 객체와 교체하여 테스트중인 코드를 분리 할 수 ​​있습니다.

라이브러리를 정리하는 목표는 다음을 가능하게하기 위해 해당 라이브러리에 대한 자신의 코드 종속성을 해제하는 것입니다.

• 단위 테스트-코드를 테스트 할 수 있어야합니다. 라이브러리가 클래스를 조롱하거나 테스트에 필요한 응답을 강요 할 수없는 경우 해당 라이브러리를 랩핑해야합니다. 이것은 명백한 문제이며 아마도 당신이 궁금한 것은 아닙니다.
• 구현 변경-코드 작성자는 진행중인 변경 사항과 변경 가능성에 대한 변경 비용을 이해해야합니다. .NET에서 JVM으로 전환 할 수 있습니까? 어려울 것 같지 않습니다. 그러나 향후 UI 기술 또는 XML 엔진을 변경할 가능성이 큽니다.

타사 라이브러리 및 프레임 워크를 격리하는 것은 격리 변경의 일부일뿐입니다.

표준 라이브러리의 멤버를 타사 코드로 취급하지 않습니다. 결국 표준이며 사용중인 플랫폼에서 사용 가능하고 기능적으로 간주 될 수 있습니다.

젠드와 같은 것에 관해서는, 나는 그것을 감싸지 않을 것이라고 생각합니다. 다른 프레임 워크를 사용한다면 프로그램을 다시 작성해야 할 것입니다. 솔직히 말해서, 심각한 외부 구성 의존성이 아니거나 실제로 그 조각을 교환 할 수 있도록 계획하지 않은 경우 많이 포장하지는 않을 것입니다.

특정 프로그래밍 언어에서 제공하는 라이브러리를 언어의 일부로 간주합니다.

보다, 나는 다른 엔티티에 의해 제공되는 모든 라이브러리를 확장, 또는 프로그래밍 언어 자체와는 별도의 도구로 제삼자를 고려할 것입니다.

예를 들어, 젠드를 제 3 자라고 생각합니다. 또한 핵심 비즈니스 로직이 Zend에 의존하지 않는 방식으로 애플리케이션을 구성 할 것입니다.

Wikipedia는 타사 구성 요소 를 다음과 같이 정의합니다 .

컴퓨터 프로그래밍에서 타사 소프트웨어 구성 요소는 개발 플랫폼의 원래 공급 업체가 아닌 다른 회사에서 자유롭게 배포하거나 판매하도록 개발 된 재사용 가능한 소프트웨어 구성 요소입니다.

가장 엄격한 의미에서, 귀하가 제공 한 모든 예는 제 3 자 코드입니다. 그러나 모든 타사 코드를 감쌀 필요는 없습니다. 모든 타사 라이브러리 를 래핑해야합니다. 정의에 따라 프레임 워크는 코드의 일부가되므로 랩핑 할 수 없습니다. 그렇기 때문에 .NET 프레임 워크 나 Zend 프레임 워크가 아닌 로깅 라이브러리를 래핑해야합니다. 실제로 코드를 .NET에서 분리 할 수는 없습니다. 물론 좋은 프레임 워크에는 프로그래밍 할 인터페이스가있어 문제를 어느 정도 우회 할 수 있습니다.

참조 : https : //.com/questions/148747/what-is-the-difference-between-a-framework-and-a-library