안드로이드에서 프로젝트를 만들 때 프로젝트 이름과 패키지 이름을 정하는걸로 시작한다.
그런데 이런 패키지 이름을 정하는 것도 규칙이 있을까 해서 찾아봤더니 규칙이 있다.
패키지 이름 규칙에 대해서 알아보자.
패키지 작명방식
- 일반적으로 패키지 이름을 지을 때는 회사가 개발한 도메인이름을 거꾸로 배열한다.
- 그 뒤에 프로젝트 명을 붙인다.
- 필요하면 그 뒤에 기능별로 세분화하는 방식으로 붙인다.
예시,
-
도메인 : kotlin.com
-
프로젝트 이름 : tutorial
-
도메인 이름을 거꾸로 배열 : com.kotlin
-
프로젝트 이름 붙임 : com.kotlin.tutorial
-
기능별로 세분화
com.kotlin.tutorial.base
com.kotlin.tutorial.kotlin
com.kotlin.tutorial.android
com.kotlin.tutorial.talk
Package 구조 방식
Package 이름에 규칙이 있다면, Package 구조 방식에도 규칙 같은 것이 있을까 해서 한번 찾아보았다.
(안드로이드 스튜디오에서는 Package = 폴더, 라고 동일하게 사용한다. 즉, Project안에 폴더를 지칭할 때는 패키지를 말하는 것이다.)
Package 구조 방식에 대해서 검색하거나 여러 방면으로 찾아보았는데 어느게 맞다, 이게 정확하다라는게 딱히 정해지지가 않아서 그나마 구글링하면서 찾은 방법중에 괜찮은 패키지 구조 방식이 보여서 사용해보려고 한다.
보통 사용하는 구조
보통 안드로이드를 접해서 사용하는 구조를 보면 종류별로 구분지어서 묶는 구조이다. ( 나또한 이 구조를 사용하고 있었다. )
- com.kotlin.tutorial
- activity : 액티비티 들을 모두 모아 둠
- fragment : 프래그먼트 들을 모두 모아 둠
- adapter : Adapter와 관련한 모든 class 모음
- util : Util과 관련한 class 모음
- etc...
장점
이러한 구조가 초기에는 구조파악이 쉽고 누구나 쉽게 알 수 있는 구조이다.(activity/adapter 집합 등)
단점
- 하지만 초기를 지나 파일의 양이 많아지면 파악하기가 힘들어진다.
( EX. 홈메뉴와 관련된 기능을 보려면 여러 패키지들을 둘러봐야 한다.) - 즉, 컴포넌트 구조라 모으는건 쉽지만, 기능별 파악하기가 힘든것이다.
전체 패키지 구조를 보는건 Double Shift를 통해 검색하는게 더 빠르다고 합니다.
관리하기 좋은 Package 구조는?
기존 방식에서 MVP/MVVM 패턴을 적용해보면서 만들어진 구조라고 한다.
- com.example.appname
-adapter : 공용으로 사용할 adapter 정의
-data : 기존과 동일하지만 source 패키지를 추가(Google Architecture 참고)
-view : 여기에서의 View에는 adapter/presenter/Activity/Fragment 등을 모두 모아둔다
-util : 기존과 동일
안드로이드 스튜디오에서 폴더 구조로 보면
여기에서 핵심은 View안에 adapter/presenter/Activity/Fragment 등을 모두 모으는데에 있다.
또한 공용으로 사용되는 부분에 있어서는 외부에 따로 둔다고 한다. 아니면 Common 이름으로 폴더를 새로 만들어 구분해도 될것같다.
View를 모으는데에 있어서 장점으로는 해당 기능에 대해서 한눈에 파악하기가 쉽다라는 점이있다.
하지만 이런 식의 구조가 된다면 동일한 이름의 폴더들이 많아진다는 점이 있고, 이 구조를 도입하는데에 있어 각각의 기능들에 대해서 어디에 넣어야할지 고민을 많이 할 것 같다.
마치며,
안드로이드 스튜디오를 하면서 프로젝트를 진행할 떄 패키지 구조를 너무 컴포넌트기반으로 만들어서 나중에 크기가 커지면 내가 만들었는데도, 어떤 기능에 대해서 찾으려고 하면 이 파일이 맞나? 라는 해프닝이 발생했다.
그래서 패키지 구조에 대해서도 어떤 방식이나 규칙들이 있을까 해서 찾아보았다.
MVP나 MVVM 등 디자인 패턴들이 많이 있었지만 어려운 구조였고 당장에 내가 쉽게 따라할 수는 없는 구조들이었다.
그러다가 딴 방식들을 둘러보다가 찾은게 이 Package 구조 방식이었다.
물론 이 방식도 쉽지는 않아보이지만 기존 방식대로 쓰는것보다는 구조 파악이나 관리적인 면에서 볼 때는 괜찮을것 같다.
참고 : https://thdev.tech/androiddev/2017/02/20/Android-MVP-Package-Structure/
