자바언어의 패키지 코딩 관례

  이전에 코드에 임포트한 패키지들을 정리하는 실장님을 보면서 

  '왜 임포트된 패키지를 .* 으로 정리하는건가요?' 

라고 물었다가 답을 들었던 기억이 흐릿해질 때쯤, 이 책을 읽다보니 나오기에 그 기록을 남긴다.

도메인주도설계소프트웨어의복잡성을다루는지혜 카테고리 컴퓨터/IT > 네트워크/보안 지은이 에릭 에반스 (위키북스, 2011년) 상세보기

자바에서는 의존성에 해당하는 임포트 구문(import)을 반드시 개별 클래스에 선언해야 한다. 모델링하는 사람들은 아마 패키지를 다른 패키지에 대한 의존성으로 생각하겠지만, 자바에서는 꼭 그렇지만도 않다.
널리 통용되는 코딩 관례에서는 개별 클래스에 대해 임포트 구문을 작성할 것을 권장하므로 코드는 아래와 같이 작성할 것이다.

import packageB.ClassB1;
import packageB.ClassB2;
import packageB.ClassB3;
import packageC.ClassC1;
import packageC.ClassC2;
import packageC.ClassC3;
...

아쉽게도 자바에서는 개별 클래스에다 임포트할 수밖에 없지만 적어도 한 번에 전체 패키지를 임포트할 수는 있다. 이렇게 하면 패키지명을 일제히 변경하는 노력도 줄어들면서 패키지가 대단히 응집력 있는 단위라는 의도가 반영되기도 한다.

import packageB.*;
import packageC.*;

사실 이 기법은 두 가지 척도(패키지에 의존하는 클래스)를 혼용한다는 것을 의미하지만 앞서 나온 클래스 목록을 나열한 것 이상, 즉 특정 Module에 대한 의존성이 만들어진다는 의도를 전해주기도 한다.

Racing Stars by Andrew Stawarz

자바에서는 패키지단위로 클래스를 작성하고 관리하지만, 이것을 실제로 모듈화하여 관리하지는 않는다. 서로다른 모듈이라 하더라도, 사용할 때에는 실제적으로 내부적인 동일한 경로의 선상에 놓이게 된다. 이때문에 이클립스를 비롯한 IDE 에서는 관례적으로 임포트되는 클래스의 패키지 경로를 명시하는 형태로 나타난다. 

실제로 임포트 되는 것은 패키지내에 클래스들이겠지만, 

import pacakges.*;

문을 통해서 해당하는 패키지가 응집력있게 사용되는 것이라는 설명을 명시화할 수가 있다.