머리말
이 장에서 설명할 내용은 S.O.L.I.D JavaScript 언어 구현의 5가지 원칙 중 네 번째인 인터페이스 분리 원리 ISP(Interface Segregation 원리)입니다.
영문 원문:http://freshbrerewedcode.com/derekgreer/2012/01/08/solid-javascript-the-interface-segregation-principle/
참고: 이 기사의 작성자는 내용이 상당히 복잡하므로 삼촌이 내용을 이해하면 상당히 우울해집니다. 너무 깊이 들어가지 말고 읽어보세요.
인터페이스 격리 원칙에 대한 설명은 다음과 같습니다.
사용자가 자신이 사용하지 않고 다른 사용자만 사용하는 인터페이스 방식에 의존하는 경우, 즉 사용자는 사용하지 않지만 다른 사용자가 사용하는 인터페이스에 의존해야 합니다. . 다른 사용자가 이 인터페이스를 수정하면 이를 사용하는 모든 사용자가 영향을 받습니다. 이는 명백히 개방-폐쇄 원칙을 위반하며 우리가 기대하는 것과 다릅니다.
인터페이스 격리 원칙은 단일 책임과 다소 유사합니다. 둘 다 기능적 책임을 모으는 데 사용됩니다. 실제로 ISP는 단일 책임이 있는 프로그램을 공용 인터페이스가 있는 객체로 변환하는 것으로 이해될 수 있습니다.
자바스크립트 인터페이스
JavaScript에서 이 원칙을 어떻게 준수할 수 있나요? 결국 JavaScript에는 인터페이스의 특성이 없습니다. 특정 언어에서 제공하는 추상 유형을 통해 계약을 설정하고 분리하려는 인터페이스라면 괜찮다고 할 수 있지만 JavaScript에는 다른 형태가 있습니다. 인터페이스의. Design Patterns – Elements of Reusable Object-Oriented Software라는 책에서 인터페이스의 정의를 찾을 수 있습니다.
http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612
객체에 의해 선언된 모든 작업에는 작업 이름, 매개변수 개체 및 작업의 반환 값이 포함됩니다. 우리는 이것을 운영자의 서명이라고 부릅니다.
객체에 선언된 모든 작업을 객체의 인터페이스라고 합니다. 객체의 인터페이스는 이 객체에서 발생하는 모든 요청 정보를 설명합니다.
언어가 인터페이스를 나타내기 위해 별도의 구문을 제공하는지 여부에 관계없이 모든 객체에는 객체의 모든 속성과 메서드로 구성된 암시적 인터페이스가 있습니다. 다음 코드를 참고하세요:
exampleBinder.viewAdaptor = (함수() {
/* 개인 변수 */
복귀 {
바인딩: 함수(모델) {
/* 코드 */
}
}
})();
exampleBinder.bind = 함수(모델) {
/* 개인 변수 */
예제Binder.modelObserver.onChange(/* 콜백 */);
var om = exampleBinder.modelObserver.observe(모델);
예Binder.viewAdaptor.bind(om);
돌아가세요 옴;
};
위의 exampleBinder 클래스 라이브러리로 구현된 함수는 양방향 바인딩입니다. 이 클래스 라이브러리에 의해 노출되는 공용 인터페이스는 바인드에 사용되는 변경 알림 및 뷰 상호 작용 기능은 각각 별도의 객체인 modelObserver 및 viewAdaptor에 의해 구현됩니다. 방법.
JavaScript는 객체 계약을 지원하는 인터페이스 유형을 제공하지 않지만 객체의 암시적 인터페이스는 여전히 프로그램 사용자에게 계약으로 제공될 수 있습니다.
ISP 및 자바스크립트
아래에서 논의하는 섹션 중 일부는 JavaScript의 인터페이스 격리 원칙 위반이 미치는 영향에 관한 것입니다. 위에서 본 것처럼 JavaScript 프로그램에서 인터페이스 격리 원칙을 구현하는 것은 아쉽지만 정적으로 유형이 지정된 언어만큼 강력하지는 않습니다. JavaScript의 언어 특성으로 인해 소위 인터페이스가 약간 끈적이지 않는 경우가 있습니다.
가을의 실감
정적으로 유형이 지정된 언어에서 ISP 원칙을 위반하는 한 가지 이유는 잘못된 구현입니다. Java 및 C#의 인터페이스에 정의된 모든 메서드는 구현되어야 합니다. 그 중 몇 개만 필요한 경우 다른 메서드도 구현해야 합니다(빈 구현 또는 예외 발생). JavaScript에서는 객체에 특정 인터페이스만 필요한 경우 위 인터페이스의 구현을 강제할 필요는 없지만 구현 손상 문제를 해결할 수 없습니다. 그러나 이 구현은 여전히 Liskov 대체 원칙을 위반합니다.
var 기하학응용프로그램 = {
GetLargestRectangle: 함수(직사각형) {
/* 코드 */
}
};
var DrawingApplication = {
drawRectangles: 함수(직사각형) {
/* 코드 */
}
};
사각형 대체가 새 객체 기하학 응용 프로그램의 getLargestRectangle을 만족하는 경우 직사각형의 Area() 메소드만 필요하지만 LSP를 위반합니다(drawRectangles 메소드에서 사용할 수 있는 그리기 메소드를 전혀 사용하지 않기 때문입니다) .).
정적 커플링
정적 유형 언어에서 ISP 위반이 발생하는 또 다른 이유는 정적 결합입니다. 정적 유형 언어에서 인터페이스는 느슨하게 결합된 디자인 프로그램에서 중요한 역할을 합니다. 동적 언어이든 정적 언어이든 개체는 때때로 여러 클라이언트 사용자(예: 공유 상태) 간에 통신해야 할 수 있습니다. 정적으로 유형이 지정된 언어의 경우 가장 좋은 솔루션은 사용자와 개체가 상호 작용할 수 있도록 하는 역할 인터페이스를 사용하는 것입니다. 구현이 사용자와 관련 없는 작업을 분리하므로 객체는 여러 역할에 속해야 할 수도 있습니다. JavaScript에는 그러한 문제가 없습니다. 왜냐하면 동적 언어의 고유한 장점으로 인해 객체가 분리되기 때문입니다.
의미적 결합
동적 언어와 정적 유형 언어 모두에서 ISP 위반으로 이어지는 일반적인 이유는 의미 결합입니다. 소위 의미 결합은 상호 의존성입니다. 즉, 한 객체의 동작이 다른 객체에 의존합니다. , 이는 한 사용자가 동작 중 하나를 변경하면 다른 사용자에게 영향을 미칠 가능성이 있음을 의미합니다. 이는 단일 책임 원칙에도 위배됩니다. 이 문제는 상속과 객체 대체를 통해 해결될 수 있습니다.
확장성
문제의 또 다른 이유는 확장성입니다. 많은 사람들이 확장성을 보여주기 위해 콜백에 대한 예를 제시합니다(예: Ajax 성공 후 콜백 설정). 그러한 인터페이스가 구현을 요구하고 구현된 객체에 많은 친숙함이나 메소드가 있다면 ISP는 매우 중요해질 것입니다. 즉, 인터페이스가 많은 메소드를 구현해야 하는 인터페이스가 되면 구현이 매우 복잡해질 것입니다. , 이러한 인터페이스가 비고착적 책임을 맡게 될 수 있습니다. 이것이 바로 우리가 뚱뚱한 인터페이스라고 부르는 것입니다.
요약
JavaScript의 동적 언어 기능을 사용하면 고정되지 않은 인터페이스 구현이 정적으로 입력된 언어보다 영향력이 떨어지지만 인터페이스 격리 원칙은 여전히 JavaScript 프로그래밍 패턴에서 유지됩니다.