20180408 패키지 구성 방법 두가지

애플리케이션을 개발하면서 패키지를 구성하는 방법에는 여러가지 차이가 존재한다고 한다. 나 또한 이러한 문제점에 봉착했고 실제로 개발을 하면서도 느낀건 애플리케이션의 규모가 커질수록 늘어나는 패키지와 클래스 그리고 인터페이스 등을 어떻게 관리하고 이후에 확장성을 고려했을 때 혹은 협업을 하는 경우 어떤 방향으로 가는 것이 더 효과적인지 고민해볼 필요가 있었다. 

해당 글은 참고링크의 글을 구글 번역과 나름의 의역을 통해서 게시하였음을 밝힌다. 글쓴이는 패키지를 구성하는 방식을 두가지로 구분지어 설명하였다. 하나는 Package By Feature 또 다른 하나는 Package By Layer 이다. 알아보자

Package By Feature

기능별로 패키지를 묶어놓은 형태를 의미한다. 단일 기능과 관련된 특징들 혹은 그 단일 기능 자체만을 하나의 디렉토리 혹은 패키지에 배치하는 것을 의미한다. 이렇게 한다면 높은 응집력(cohesion)과 높은 모듈성(modularity)을 지니게 되며, 패키지간 결합도가 최소화된다. 하나의 패키지 내에 관련한 기능들이 모두 들어있기 때문이다. 아래는 예시이다.

• com.app.doctor

• com.app.drug

• com.app.patient

• com.app.presription

• com.app.report

• com.app.security

• com.app.webmaster

• com.app.util

각각의 패키지는 특정 기능과 관련된 항목만 포함하고 있으며 다른 기능은 포함하지 않는다. 위의 예시 com.app.doctor 아래의 파일들을 자신의 하위 파일로 가질 수 있다.

• com.app.doctor
• DoctorAction.java : an action or controller object
• Doctor.java : a Model Object
• DoctorDAO.java : Data Access Object
• database items (SQL statements)
• user interface items ( JSP.. )

위의 내용을 살피면 단순히 .java 파일이 아닌 다른 종류의 파일들도 포함될 수 있는 것을 확인할 수 있다. 실제로 패키지별로 기능을 작동시키기 위해서는 자바코드, 데이터베이스 항목 등 특정 기능과 관련된 모든 항목들을 해당 기능에 대한 패키지 내부에 배치시켜야 한다.

기능별 패키지의 아이디어는 한 패키지가 다른 패키지에 속한 항목을 절대로 사용할 수 없다는 것을 의미하는 것이 아니다. Package By Feature 는 aggressively (적극적으로) 하게 package-private 를 기본 scope로 선호하지만, 경우에 따라서는 항목의 범위를 공용으로 늘린다.

Package By Layer

레이어를 기준으로 패키지를 구별하는 것을 의미한다. 아래는 예시이다.

• com.app.action

• com.app.model

• com.app.dao

• com.app.util

각각의 패키지들은 서로 밀접하게 관련이 없는 항목들을 포함하고 있다. 이 결과 패키지 내부의 파일들은 낮은 응집력과 낮은 모듈성을 갖게 된다. 반면에 패키지간의 결합력은 높다. 따라서 어느 패키지에 수정을 가했을 경우에 해당 패키지를 참조하는 다른 패키지 내부의 파일들도 변경이 불가피하다. 그리고 특정 패키지를 삭제하게 된다면 다른 패키지의 기능들은 작업 수행이 불가하다.

[ 본인 글 ]

글쓴이는 기능별 패키지(Package By Feature)로 애플리케이션을 작성하라고 권장한다. 다음은 권장하는 이유들이다.

• Higher Modularity
  - 앞선 설명처럼 높은 응집도 및 높은 모듈성을 의미한다.
• Easier Code Navigation
  - 패키지 간의 이동에 불편함을 크게 줄이며, 패키지의 응집도가 높기 때문에 코드 탐색에 대해서 수월함을 제공한다.
• Higher Level of Abstraction
  - 하이 레벨의 추상화에 존재하는 것은 프로그래밍의 가치를 이끌어내는 기본적인 원칙이라고 한다. Package By Layer 의 근본적인 문제는 하이 레벨의 추상화보다 로우 레벨의 구현 내용들을 더 우선시하고 있다는 것이다. 표현이 어려운데, 패키지 자체로 보여지는 것들이 사실상 하이 레벨의 내용들이 아닌 로우 레벨의 내용들이기 때문에 추상화를 시켰다고 하더라도, 패키지가 보여지는 관점들은 우리 프로그래밍이 추구하는 이상적인 가치와 상이하다는 것이다.
• Separates Both Features and Layers
  
• Minimizes Scope
  - 모든 항목을 단일 패키지 내부에서 packag-private 형태로 구현하는 것이 좋은가 혹은 공용으로 다같이 여기저기서 쓰이는 것이 좋은가를 의미한다. 모듈을 쓰고자 한다면 응집도와 결합도를 생각하였을 때 우리는 어떤 부분을 낮추고 높이는 지에 대해서 잘 알고 있다.
• Better Growth Style
  - 기능이 추가되면 패키지를 늘리면서 분할하고 내부적으로 파일을 생성함으로써 확장성을 고려할 수 있지만, 레이어 단위로 패키지를 구분하게 된다면 해당 레이어 내부에 쓰이는 비즈니스 로직과 관련된 파일은 무수하게 많이 생성될 것이고 이후에는 리팩토링 하는 작업에 있어서도 결합도가 높기 때문에 많은 시간과 자원을 소모할 것이다.

나름의 해석을 하였지만 자세한 내용은 보고자 한다면 아래의 링크를 클릭하길 바란다.

[ 참고링크 ]

[ Package by Feature, not layer ]