더북(TheBook)

② 프로그램 설계의 용이성

뒤에서 설명하겠지만 패키지는 선언부(스펙)와 본문(바디), 두 부분으로 구성된다. 선언부는 패키지에서 사용할 각종 변수, 상수, 타입, 커서와 함수, 프로시저를 선언하는 부분이고, 본문은 함수와 프로시저를 구현한 부분이다. 그런데 패키지는 선언부만 있어도 컴파일한 뒤 저장이 가능하다. 즉 본문은 나중에 작성해도 된다는 뜻이다. 어떤 이유에서 이것이 장점이라는 걸까? 다음과 같은 상황을 가정해 보자.

프로젝트를 수행하는 팀이 여러 개인데, 그 중에 공통 모듈을 담당하는 팀이 있다고 해 보자. 공통 모듈 팀은 다른 팀에서 사용할 수 있는 공통 테이블, 즉 마스터나 코드성 테이블을 관리하는 프로그램을 개발하고 있다. 이러한 테이블은 잘못 손대면 안 되기 때문에 공통팀만 접근 권한이 있다. 하지만 다른 팀에서도 이 테이블을 참조하고 조작할 필요가 있다. 그래서 공통 모듈 팀은 다른 팀을 위해 common이란 패키지에 code_proc란 프로시저를 만들기로 했다. 그런데 이 패키지가 완성이 되어야 다른 팀들도 이 패키지로 자신들의 패키지나 프로시저를 작성할 수 있는데, 아직 공통 모듈 팀에서는 설계만 한 상태로 구현은 시작하지도 못했다. 이때 common 패키지에서 code_proc 프로시저의 매개변수의 유형과 개수, 처리할 내용만 협의한 뒤 공통 모듈 팀에서 패키지 선언부만 일단 작성해 컴파일해 놓으면, 다른 팀에서는 자신들이 작성하는 프로그램에서 common 패키지의 code_proc를 사용하더라도 컴파일 오류 없이 진도를 나갈 수 있다. 뿐만 아니라 나중에 프로시저의 구현부가 완성된 뒤에도 자신들이 작성한 패키지나 프로시저를 다시 컴파일할 필요가 없다.

신간 소식 구독하기
뉴스레터에 가입하시고 이메일로 신간 소식을 받아 보세요.