많은 사람들이 제 3 자 API 라이브러리에 대한 호출을 중심으로 추상화 계층을 구축하는 것이 좋은 습관 인 소프트웨어를 설계 할 때 제안한다고 들었습니다.사용중인 API를 추상화하는 것이 좋은 습관입니까?
예를 들어 내가 올바르게 이해한다면 jQuery로 웹 응용 프로그램을 구축하고 있다고 가정 해보십시오. jQuery에 대한 추상 레이어를 만들어야하고 내 응용 프로그램 코드의 나머지 부분에 내 추상화 API와 jQuery에 대한 직접 호출을 사용해야합니다.
내 질문 :
미리 감사드립니다.
jQuery는 "응용 프로그램 코드"수준에서 매우 효과적으로 작동하도록 고 가용성 API입니다. &을 추상화 할 필요가 없으므로 그렇게하지 않으면 도움이되지 않습니다.
앱에 특정한 반복적 인 UI 구성 요소 & 패턴의 응용 프로그램 수준 사용을 고려하여 일부 "라이브러리 구성 요소"또는 그 위에 소량의 라이브러리 코드를 작성하는 데 사용할 수 있습니다.
일반적으로 "모든 것을 추상화"하라는 조언은 대부분 잘못된 것으로 들립니다. 추상화는 사용자가 교환 할 수있는 일에 사용됩니다. 필요가없는 곳의 추상화가 잘못되어 유용하지 않은 경우 & 그렇지 않으면 비용이 들지 않습니다.
jQuery는 이미 추상화 계층입니다. 따라서이 말을하는 사람은 누구나 자신이 말하는 것에 대해 처음 알지 못합니다.
추상화보다는 jQuery 이외의 다른 라이브러리와 함께 더 일반적인 상황은 응용 프로그램 코드가 작동하는 수준 아래의 "라이브러리 구현"또는 SPI 수준에서 설계된다는 것입니다.
이 경우 일반적으로 응용 프로그램 코드에서 응용 프로그램 코드와 함께 사용되는 독자, 라이터, 빌더 및 기타 "작업 위주의"클래스와 같은 고유 한 라이브러리 코드/클래스를 빌드하는 것이 유용합니다. 레벨 API를 사용하고 라이브러리로 내려가십시오. 그러나 다시, 이것은 추상화가 아닙니다.
실제로 추상화를 사용하는 세 가지 가장 유용한 장소
은 및본질적으로 매우 우수한 DOM 조작 및 AJAX 라이브러리 인 합리적으로 복잡한 웹 응용 프로그램 (UI, 상호 작용 및 데이터 무거움) jQuery 만 작성하는 경우 필요한 도구가 제공되지 않습니다 유지 보수가 가능한 방식으로 클라이언트 측 코드를 구조화합니다.
는 당신이 사람들이 무엇에 관해 얘기 들었어요 추상화 같은 Backbone, Knockout, Angular 및 Ember, 대부분 사용의 (또는 사용) jQuery를 지난 몇 년 동안 나타나기 시작했다 다양한 클라이언트 측 프레임 워크 생각 DOM을 조작하는 것이 좋다.
이러한 프레임 워크 중 하나는 휠 재발견없이 모듈화되고 유지 보수가 가능한 방식으로 코드를 구조화하는 데 필요한 도구를 제공합니다. 웹 애플리케이션이 모두 복잡하다면 (또는 시간이 지나면 복잡해질 가능성이 있음) 위의 사항 중 하나를 출발점으로 생각해 두는 것이 좋습니다.
jQuery와 같이 매우 널리 퍼져 있다고 생각합니다. 직접 사용하는 것만으로도 안전합니다. 이 제안은 특히 DLL 인터페이스를 작성할 때 벤더 플러그인 API를 더 목표로 할 수 있습니다. – paddy
우리가 작성한 코드는 100 % 완벽하지는 않지만 복잡성, 추상화 수준, 가독성, 재사용 가능성 사이에서 적절한 균형이 이루어져야합니다. –