Skip to end of metadata
Go to start of metadata
패키지명
패키지명은 하나의 단어만 사용할 것이 권장되며 만약 단어의 길이가 10자를 넘어 가독성에 무리가 간다 판단될 경우에 단어의 앞 3글자만 따서 지을 수도 있다. 항상 하위 패키지는 상위 패키지와 깊은 연관을 맺어야하며 만약 서로 다른 성격의 패키지가 부모 자식 패키지로 설정될 경우 혼동이 올 수가 있다.
사용되는 대표적인 패키지명들
domain (영역, 범위, 소유지) - 단위로 표현할 수 있고 원자성을 띄는 자바빈 클래스, Enum 클래스 등이 위치한다. 다른 곳에서 VO라고 하는 것을 본적이 있는데 필자는 domain이란 이름이 더 마음에 든다.

dao (Data Access Object) - 데이터액세스 계층과 관련된 클래스와 인터페이스들이 자리한다. DB과 관련된 작업을 한다면 사용할 수 있는 패키지명이다.

service (근무, 봉사, 편익, 이용…) - 역시 웹에서 사용되는 계층 중 하나이며 대개 dao를 조합하고 트랜잭션의 경계가 설정되는 구간이기도 하다.

core (속, 중심부, 핵심…) - 어플리케이션의 핵심적인 역할을 수행하는 클래스와 인터페이스들이 자리하는 구간이다.

task (일, 과업, 과제…) - 단어와는 가장 딴판으로 사용되는 용어 중 하나이다. 자바에서 스레드와 관련된, java.lang.Runnable 클래스의 활동을 지원하는 클래스들이 위치한다.

access (접근, 진입로, 증가…) - DB 뿐만이 아니라 다른 리소스의 자원을 불러들이고 이를 자바에서 사용가능한 상태로 가공해주는 클래스들이 위치한다.

support (지지, 지원…) - 가장 잘 이해하고 사용해야 할 패키지명이며 어느 어플리케이션이든 기본적으로 하나씩은 포함되곤 한다. 스프링 프레임워크에서는 대개 구현체를 지원하는 팩토리빈 클래스라던가 객체를 다른 클래스에서 요구하는 형태로 가공해주는 역할의 클래스들이나 부모 패키지의 인터페이스들이 구현된 클래스들이 위치해 있었다.

※ 혹시 이 패키지에 대한 다른 견해가 있으면 꼭 댓글로 말해주길 바란다.

config (구성, 설정) - 다른 언어 또는 외부 자원을 자바의 형태로 파싱해주고 그 설정을 Builder와 같은 설정 구현체에 저장해주는 역할을 담당한다.

validation (확인) - 부모 패키지의 객체들을 검증하는 검사자 클래스들이 위치한다.

util (유용한, 쓸모 있는…) - 부모 패키지의 객채들에 대해 기본적인 CRUD(Create · Remove · Update · Delete)작업을 해주거나 컬렉션 프레임워크과 비슷한, 혹은 좀 더 복잡한 작업을 도와주는 도구 클래스들이 위치한다.
인터페이스
인터페이스는 굉장히 추상적이면서도 핵심의 의표를 찔러야 하는 명명규칙이 필요하다. 그러므로 가장 직관적이고 누구나 이해할 수 있는 단어로 선별해 내는 것이 중요하며 전치사나 동사를 사용하지 않는 것이 좋다.
대개 1~2 단어만 조합되므로 명명규칙이 필요 없을 것 같지만 설계가 좀 더 다양화되고 구체적이게 될수록 인터페이스 간의 관계 또한 복잡해지므로 다음의 스프링 클래스의 이름을 보면서 개발자들이 사용하고 있는 명명규칙을 조금이나마 이해하면 도움이 될 듯 하다.
예) ApplicationContext

// ApplicationContext는 사실 총 6개의 각기 다른 성격의 인터페이스들을 상속받고 있으며 스프링에서 중요한 역할을 담당하는 컨텍스트의 가장 원시적인 모델이기도 하다.

ApplicationContext -▷ EnvironmentCapable, ListableBeanFactory, HierarchicalBeanFactory, MessageSource, ApplicationEventPublisher, ResourcePatternResolver

ConfigurableApplicationContext -▷ ApplicationContext (and LifeCycle)
AbstractApplicationContext -▷ ConfigurableApplicationContext
GenericApplicationContext -▶ AbstractApplicationContext
GenericXmlApplicatonContext -▶ GenericApplicationContext
AnnotationConfigApplicationContext -▶ GenericApplicationContext
위의 인터페이스와 클래스 간의 이름들을 보면 알 수 있는 뻔한 사실이긴 하지만 ApplicationContext 인터페이스를 상속 또는 구현하고 있는 모든 객체가 동일하게 ApplicationContext란 원시 인터페이스의 이름을 유지하고 있다는 것이다. 물론 ApplicationContext 인터페이스 자체는 본인의 이름과 전혀 관계없는 인터페이스들을 구현하고 있긴 하지만 그것도 이유가 다 있다.
왜냐하면 ApplicationContext란 인터페이스에는 2가지의 개념이 적용되고 있는데 바로 인터페이스 간의 포함과 상속개념이 그것이다. 과거에 초보시절에 자바를 배우던 기억을 어렴풋이 더듬어보면 클래스끼리는 클래스 내부에 다른 클래스를 포함시키면 포함관계고 상속 받으면 상속 관계라고 배웠고 인터페이스는 상속은 가능해도 클래스처럼 포함관계를 가질 수 없다고 배웠다.
물론 인터페이스끼리 포함관계가 성립될 수 없다는 것이 맞는 말이긴 하나, 중요한 것은 원칙에 의해 프레임워크를 만들다 보면 때로는 인터페이스 간에도 포함이라는 관계가 필요하다는 것이다. (사실 필자는 그런 경지에 까지 올라가야할 어플리케이션을 만들어 본적은 없지만…) 물론 정확한 사실은 아니지만 필자가 예측하기에 스프링 개발팀은 합치기엔 너무도 다른 성격의 기능들을 각기 다른 클래스로 분리해야만 했고 분리해냄과 동시에 또 의존적 주입이 가능하도록 분리한 클래스들의 인터페이스를 구현해야만 했다. 그리고 그 분리해낸 기능이 합쳐지는 클래스 또한 의존적 주입이 가능하도록 다시 합쳐진 인터페이스를 구현해야 했기 때문에 저런 형태의 인터페이스와 클래스나 나왔던 것이다.
스프링 팀이 이런 문제를 해결하기 위해 반드시 복잡한 인터페이스 다형성 기술을 도입할 필요는 없었지만 아마 자신들의 의존적 주입방식에 대한 확고한 철학이 있었기에 이런 방식으로 문제를 해결할 수 밖에 없었을 것이다. 물론 인터페이스의 다형성 원칙이 원래는 존재하지 않았던 엄청난 기술은 아니지만 대개 인터페이스 상에서 다형성을 구현할 정도로 복잡한 코드를 짜는 프로그래머들이 많지 않기에 조금 시간을 할애해서 설명을 덧붙일 필요성은 있지 않나 싶다.
클래스
스프링을 이용한다면 Dependency Injection이 가능한 형태로 클래스를 만들도록 정말 노력해야 한다. 설마가 사람잡는다고 "이걸 확장할 필요가 있겠어?"란 생각에 인터페이스도 없이 작성한 클래스가 어쩌다보니 확장이 필요하게 되는 경우가 생길 수도 있는 것이다. 그러므로 모든 클래스는 가급적 작성 전에 원시 형태의 인터페이스를 우선 작성하는 것을 고려해야 하며 최대한 모든 조건 하에 주입관계가 이루어지도록 코드를 작성해야 한다.
그러므로 필자는 스프링을 이용하고 항시 인터페이스를 구현한 클래스를 사용한다는 조건 하에 설명하겠다.
Simple + 인터페이스명 : Simple로 시작하는 클래스명은 이 인터페이스의 가장 기본적인 구현체를 뜻한다. 간혹 인터페이스명 + Impl과 같이 사용하는 경우도 있는데 좀 더 의미를 명확하게 하기 위해 Simle이란 접두어를 사용할 것을 권장한다.

용도명 + 인터페이스명 : 기본 구현체 외에 다른 방식으로 이용된다면 용도를 접두어로 사용하는 클래스가 구현된다.

인터페이스명 + Utils : 특정 구현체를 인자로 받아 다양한 역할을 수행해주는 도움 클래스를 지칭한다.
메서드
마지막으로 메서드의 작명규칙이다. 아마 개발자들이 가장 고민하고 답답해하는 부분이 바로 메서드명이 아닐까 싶다. 사실 메서드 명에는 정말 자세히 들여다 보지 않으면 눈에 띄지 않는, 정말 깨알 같이 적용되곤 하는 규칙들이 존재한다. 뭐 get, set같은 거는 이미 오래 전부터 널리 알려진 규칙이고 아래에 작성된 규칙들 또한 프로그래머들 간에 보이지 않는 약속 축에 속한다고 보면 된다.
접두어로의 사용

get… : 어떠한 리소스를 리턴하는 메서드

set… : 프로퍼티에 해당 리소스를 내장시키는 역할의 메서드 

init… : 초기값이 필요하다면 초기값을 설정하고 내부에서 관련 validate를 실행하는 역할의 메서드

load… : 전달인자를 기준으로 어떠한 값을 불러와 내장시켜주거나 카운팅하는 역할의 메서드

is… : 불리언 메서드에서 사용되는 접두어이다. 용도는 get…과 같다.

has… : contains 메서드처럼 어떠한 값을 가지고 있는지 확인해준다. 다른 점이 있다면 contains는 좀 더 범위가 넓지만 has는 특정 값으로 범위가 한정되있다.

register… : 기본적으로 set과 동작하는 방식이 같지만 set은 자바빈 규약에 얽혀있기 때문에 복잡한 연산을 포함할 수 없다. 보다 지능적인 set이 요구될 때 register과 같은 접두어를 사용한다.

create… : register…는 보통 void 형태이지만 create는 전달인자를 통해 새로운 객체를 만든 뒤에 이 객체를 리턴해준다. 등록과 생성은 엄밀히 다르므로 create를 register처럼 써서는 안될 것이다.

to… : 많이 만들어두면 참 좋은 접두어 메서드이다. 해당 객체를 다른 형태의 객체로 변환해준다.
전치사로의 사용

A-By-B : B를 기준으로 A를 하겠다는 뜻
ex) getUserByName(String name) : 이름값을 통해 유저를 불러옴

A-With-B : B와 함께 A를 하겠다는 뜻
ex) registerWithGeneratedName(BeanDefinition beanDefinition) : beanDefinition으로 다른 메서드를 통해 GeneratedName 값을 불러와 함께 저장.
접미사로의 사용

…With : 무엇과 함께 있는지, indexOf와 비슷한 성격의 접미사이다.
…s : 해당 객체가 복수의 객체를 반환하는지 단일 객체를 반환하는지 구분하는 것은 매우 중요하다. 복수형으로 표현해야 하는 메서드는 반드시 복수형으로 표현하여야 한다.
Labels
  • None