메서드, 클래스 명명규칙 어떡하면 좋을까?

많은 개발자들이 개발 중에 종종 고민하는 "이 메서드명은 뭘로 해야 좋을까?"란 문제는 흡사 직장인들이 "오늘 점심 뭘 먹을까?"와 거의 비슷한…, 또 본의 아니게 심각한 트라우마에 빠질 수도 있는 고민 중 하나이다. 사실 어떻게 보면 별것도 아닌 고민일 수 있는데 한국인인지라 영어도 잘 모르는 상황에서 컴퓨터랑 영어로 대화를 하려니 발생하는 헤프닝일 수도 있겠다.

아마 대부분의 개발자들이 처음에는 구현해야할 기능의 성격이 어느 정도 명확하니까 비교적 단순한 영단어로 get, put, remove…같은 식으로 지어나가곤 한다. 그리고 그렇게 도메인 계층이나 DAO계층을 어느 정도 마무리 짓고 본격적으로 서비스 계층, 서포트 계층으로 올라가려다보면 어느덧 명명규칙의 트랩에 빠지게 되고 사전에 야기했던 본의 아닌 트라우마에 빠지기 시작한다.

예를 들어 메서드를 하나 만드는데 내용이 '클라이언트가 전달 파라미터를 가지고 User 테이블의 인덱스를 검사한 뒤, 그 결과값 바탕으로 다시 Friends 테이블에 검색해서 나온 결과값을 가공하여 뷰가 해석할 수 있는 클래스로 변환한 값을 리턴'한다고 하자. 도대체 이런 해괴망칙한 과정을 거치는 메서드 명은 당신은 뭐라고 지을 것인가?

더욱이 이런 메서드를 한 두개 만드는 것도 아니고 보통 하루에 30~40개 정도의 (어느 정도 의미있는) 메서드를 찍어내고 7~10개 정도의 클래스를 만들어내는 게 프로그래머들이다. 매번 게임 아이디 만드는 것도 아니고 쓸데없는 메서드명 창작에 심혈을 기울이고 싶은 사람은 아무도 없을 것이다.

에다가 심각한 것은 문제가 이게 끝이 아니라는 것이다. 메서드명 짓기도 짜증이 나는데 클래스명 창작은 더욱 난해하고 심오해서 세상에서 가장 어려운 단어 찾기의 게임 속으로 빠져든다. 왜냐하면 보통 클래스명은 많은 의미를 함축하고 있으면서도 명확한 목적을 표현해야 하므로 여러가지 정황을 고려해 지어지는 것이 일반적이다. 예를 들어 AnnotationConfigApplicationContext.class의 이름은 @Configuration 어노테이션으로 설정된 클래스를 ApplicationContext 형태로 가공해주는 클래스인데 스프링 제작자가 이름 짓기 귀찮아 ApplicationContextImpl과 같이 단순히 인터페이스를 구현했다고 가정해보자. 이런 상황에서 작성자는 자신이 만든 클래스의 기능을 속속들이 알고 있지만 사용자는 대개 메서드명만 보고 단순 예측한 상태에서 기능을 사용하기 때문에 자칫 혼란을 가져오는 문제를 발생 시키기도 한다.

그러므로 메서드명과 클래스명에서 발생되는 문제는 개발자 본인에게는 별 것 아닌 문제처럼 치부될 수도 있지만 직접 사용하는 사용자에게는 매우 중요한 역할을 수행하게 되므로 사전에 충분히 작성이 필요한 메서드들을 예측하여 약속된 문법과 단어들을 조합하여 메서드와 클래스를 작성하는 규칙이 필요하다.

그리고 만약에 그럴 사람은 드물겠지만 프로그래밍의 메서드와 클래스명을 짓기 위해 조금이나마 영어공부를 하고 싶다면 on, by, after, before, of…와 같은 단순전치사나 전치사구는 여러모로 프로그래밍 명명규칙에 활용하기 좋은 영단어이므로 콩글리쉬로만 알지 말고 내포하고 있는 다양한 의미를 습득하는 것이 좋다.

앞으로 여기서 나열하는 단어들과 의미는 스프링 프레임워크에서 사용되고 있는 메서드와 클래스 이름의 규칙들이며 가급적 특정한 의미만을 내포하지 않고 규칙적으로 사용되는 단어들을 선별하고자 노력하였다. 그리고 단순히 영어단어의 뜻만이 아니라 프로그래밍 적으로 사용되는 뜻까지 포함할 수 있도록 하였으니 정독만 했다면 독자의 개발과정에 어느 정도 도움이 되리라 본다.

패키지명

패키지명은 하나의 단어만 사용할 것이 권장되며 만약 단어의 길이가 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 : 해당 객체가 복수의 객체를 반환하는지 단일 객체를 반환하는지 구분하는 것은 매우 중요하다. 복수형으로 표현해야 하는 메서드는 반드시 복수형으로 표현하여야 한다.

이외에도 많은 메서드 명명 규칙이 있겠지만 여기까지 하는 것으로 마무리 하겠다. 이게 전부라고 생각하지는 말고 좀 더 구체적이고 다양한 명명규칙을 가지고 있으면 개발시에 참 편리하다. 그리고 추가로 필요한 명명 규칙이 있어야만 한다면 댓글로 신랄하게 적어주길 바란다.

출처 : http://egloos.zum.com/springmvc/v/539238