모듈화 수용을 위한 JavaScript_javascript 팁

우리는 다시 한번 컴퓨터라는 용어와 개념에 휩싸였습니다.
backbone, emberjs, spinejs, batmanjs 및 기타 MVC 프레임워크가 침입했습니다.
CommonJS, AMD, NodeJS, RequireJS, SeaJS, curljs 모듈식 JavaScript가 나올 때까지 기다리십시오.
특히 모듈형 JavaScript 개념이 강해 2007년 Ajax 트렌드를 따라잡는 것 같습니다.
1. 함수 작성(절차적)
2005년 이전에는 JavaScript에 관심을 가진 사람이 없었고 양식 유효성 검사와 같은 소수의 응용 프로그램에서만 사용되었습니다. 당시에는 웹 페이지에 JS 코드를 몇 줄만 작성할 수 있었고, 1,000줄은 매우 복잡한 것으로 간주되었습니다. 이때, 코드를 정리하는 방법은 프로세스이며, 수십 줄의 코드에 대해 하나의 함수도 작성할 필요가 없습니다. 조금 더 복잡하면 함수를 추상화해야 하고, 더 복잡하면 더 많은 함수가 필요하며 함수는 서로를 호출합니다.


2. 글쓰기 수업(객체지향)
2006년 Ajax가 전 세계를 휩쓸었습니다. JavaScript는 진지하게 받아들여지며 점점 더 많은 백엔드 로직이 프런트엔드에 배치됩니다. 웹페이지의 JS 코드 양이 급격히 증가했습니다. 현재로서는 많은 양의 코드를 정리하는 함수를 작성하는 것만으로는 부족한 것 같습니다. 때로는 작은 함수를 디버깅할 때 한 함수에서 N번째 함수로 점프할 수도 있습니다. 이때 글쓰기 수업 방식이 등장하며 프로토타입이 대중화되는 데 앞장섰다. 이를 사용하여 코드를 구성하고 클래스를 하나씩 작성합니다. 각 클래스는 Class.create에 의해 생성됩니다. YUI 및 Ext와 같은 중량급 프레임워크도 있습니다. 클래스를 작성하는 방법은 다르지만 디자인 아이디어는 모두 대량의 JavaScript 코드 개발에 적합합니다.

3. 모듈 작성(지금, 미래?)
2009년, Nodejs가 탄생했습니다! 이 서버 측 JavaScript는 모듈식 작성 방법을 채택하고 브라우저 측 JSer를 빠르게 정복했습니다. 우수한 인재들이 속속 등장하고 있으며, 라이팅 모듈에 대한 다양한 사양도 속속 등장하고 있다. CommonJS는 프론트엔드와 백엔드의 작성 방식을 통일하고 싶어하는 반면, AMD는 브라우저 측에 적합하다고 믿고 있습니다. 글쎄요, 모듈 작성 스타일이 무엇이든 모듈식 JavaScript 작성이 인기를 얻었습니다. 준비됐나요? (어, 도발적이네요)

야, 모듈형 자바스크립트가 뭐야? 이것이 우리가 발명한 또 다른 묘책인가요? 무슨 일이 있어도 그냥 공부하세요. 프로젝트에 사용하기에 적합한지 여부는 각 개인이 결정합니다.

이 글을 쓰면서 '모듈'에 대해 아무 말도하지 않았습니다. 실제로 컴퓨터 분야에서는 모듈화 개념이 거의 40년 동안 장려되어 왔습니다. 소프트웨어의 전체 구조는 모듈화 아이디어를 구현합니다. 즉, 소프트웨어는 독립적으로 명명된 몇 가지 구성 요소로 나누어지고, 각 구성 요소는 모듈이라고 불리며, 모든 모듈이 함께 조립되면 문제에 대한 해결책이 될 수 있습니다. 획득.

모듈화는 분할 정복 방식을 기반으로 하는데, 소프트웨어를 무제한으로 세분화할 수 있다는 뜻인가요? 실제로 분할을 너무 세밀하게 하여 전체 모듈 수가 늘어나면 모듈당 비용은 낮아지지만 모듈 인터페이스 비용은 증가하게 됩니다. 모듈의 합리적인 분할을 위해서는 정보 은닉, 응집, 결합을 이해하는 것이 필요합니다.

정보 숨기기
모듈은 포함된 정보(프로세스 및 데이터)가 이를 사용할 필요가 없는 모듈에 표시되지 않도록 설계되어야 합니다. 각 모듈은 독립적인 기능만 완료한 다음 이 기능에 대한 인터페이스를 제공합니다. 모듈은 인터페이스를 통해 액세스됩니다. JavaScript에서는 함수를 사용하여 인터페이스 개체를 숨기고 캡슐화한 다음 반환할 수 있습니다. 다음은 이벤트 관리를 제공하는 모듈 이벤트이다.

코드 복사 코드는 다음과 같습니다.

event = function() {
// 더 많은 작업 수행
return {
bind: function() {},
unbind: function() {},
trigger: function() {}
}; ()


함수 내에서 원하는 인터페이스 바인딩, 바인딩 해제 및 트리거를 구현하려면 많은 코드를 작성해야 할 수 있지만 이러한 코드(프로세스 및 데이터)를 다른 모듈에 공개할 필요는 없습니다. 인터페이스 바인딩, 바인딩 해제 및 트리거를 외부에서 액세스할 수 있는 한 가능합니다.

모듈 설계에 대한 정보 은닉의 이점은 매우 분명합니다. 모듈의 병렬 개발을 지원할 뿐만 아니라 테스트 또는 사후 유지 관리 작업량을 줄여줍니다. 나중에 코드를 수정하려는 경우 인터페이스가 변경되지 않은 경우 모듈의 숨겨진 부분을 마음대로 변경할 수 있습니다. 예를 들어, 이벤트 모듈이 처음 구현되었을 때 이전 버전의 IE 및 표준 브라우저와 호환되도록 많은 IE Special 코드가 작성되었습니다. 어느 날 이전 버전의 IE가 사라졌습니다(원숭이 해에). 말의 달), 침착하게 삭제하면 됩니다.

결합력
결합력은 모듈의 내부 구현을 의미하며, 이는 정보 은닉 및 위치 파악 개념의 자연스러운 확장입니다. 모듈. 이점도 분명합니다. 관련 작업을 그룹화하면 읽기가 훨씬 쉽습니다.
설계 시 모듈 응집력을 최대한 높여 모듈 독립성을 높여야 합니다.

결합도
응집도는 특정 모듈의 내부 구현 정도를 나타내는 척도이고, 결합도는 모듈 간의 결합 정도를 나타내는 척도입니다. 결합 정도는 모듈 간 인터페이스의 복잡성, 모듈이 들어가거나 호출되는 위치 등에 따라 달라집니다. 응집력과 달리 느슨하게 결합된 시스템을 설계할 때 추구해야 합니다.