Javascript 함수 파라메터 생성 패턴



  Javascript platform 환경에서 개발을 하든지, Java, C#, C platform 환경에서 개발을 하든지 지향해야 하는 패턴이라고 할 수 있겠다. 바로 함수에게 넘겨주는 파라메터에 관한 패턴이다. 이 패턴을 왜 지향해야 하는지에 대해서 알아 보자.


 소프트웨어를 개발하는데 있어서 구축시 변경되는 요구사항과 유지보수에서 변경되는 사항때문에 함수는 변경이 될 수 밖에 없는 환경이다. 예를 들어 "코드1"과 같이 함수가 생성이 되었다고 가정하자.


[코드1] 함수 생성 코드 예제


 위와 같이 코드로 생성되어 개발 하다가 변경사항 때문에 파라메터를 더 추가해야 하는 상황에 빠지게 되었다. 그리고 문제는 파라메터 순서를 어떻게 정해야 하는지도 고민에 빠지게 한다. 이런 저런 고민 끝에  "코드2"와 같이 수정하게 되었다. 


[코드2] 변경된 함수 생성 코드 예제


 "코드2"에서 추가되는 파라메터 변수의 중요도 때문에 중간에 끼워 넣게 되었다. 그래서 이 함수를 사용하는 다른 곳에서도 수정이 불가피하게 되었다. 그래서 소스를 찾아 다니면서 수정을 하게 되었고 추가된 파라메터가 필요치 않는 곳에서는 "''" 공백 문자로 바꿔주는 수고까지 하게 되었다. 이런 케이스가 합리적으로 보이는가? 이제 한번 개선시켜 보자. "코드3"을 살펴 보도록 하자.


[코드3] 객체로 파라메터 함수 생성 코드 예제


 "코드3"과 같이 선언하면 다음과 같은 장점이 있다.

  • 매개변수와 순서를 기억할 필요가 없다.
  • 선택적인 매개변수를 안전하게 생략할 수 있다. ( 이름 지원하기 위해서는 해당 함수에서 검증하는 단계에서 에러 처리를 해줘야 가능 하다. )
  • 읽기 쉽고 유지보수가 편하다.
  • 매개 변수를 추가하거나 제거하기가 편한다.
단점은 아래와 같다.
  • 매개변수의 이름을 기억해야 한다.
  • 프로퍼티 이름은 압축되지 않는다. ( 압축 프로그램에서 매개 변수의 이름은 단순한 문자로 치환하여 전체 소스 크기를 줄이는 작업이 안된다. 그렇지만 일부 유틸에서는 프로퍼티의 매개변수도 압축을 해준다. - 구글 Utility - 그렇지만 배포를 해야 하는 상황에서는 적합한 모델이 아니다. 일부 Intellisense가 지원되는 도구에서는 연상되지 않는 프로퍼티명으로 나오게 하기 때문이다. )


 함수를 생성함에 있어서 최소한의 파라메터를 받고 넘겨 줄 수 있는 방안을 고려하여 생성 하도록 하자. 더군다나 라이브러리를 배포할 때는 더욱더 신경 써야 할 것이다. 한번 배포가 되고 나면 수정하는데 비용이 상상이상으로 많이 들기 때문이다. 

+ Recent posts