RedTiger

저자는 다음과 같은 4가지에 대한 코딩 규칙을 제안하고 있다.

1. 지역변수, 메소드 인자, 필드에 대한 변수명
2. 레이어별 패키징과 특징별 패키징
3. 퍼시스턴스 객체의 생김새 및 사용법
4. private 멤버의 위치

각각에 대해 어떤 의미로 제안을 하고 있는지 살펴보고 실효성과 효과를 생각해 보자.

지역변수, 메소드 인자, 필드에 대한 변수명

통상 헝가리안 변수명명 규칙을 이용하는 경우 변수명에 타입(형)을 prefix로 지정한다. 하지만 통상 자바 코더들은 그런 규칙을 사용하지는 않는것으로 보이고 그렇다고 지역변수, 메소드 인자등을 따로 구분하는 명명 규칙을 사용하지도 않는것 같다.

대 체로 사용되는 명명 규칙으로는 상수(통산 public static final로 지정하거나 enum으로 사용하는 경우)명의 경우는 모두 대문자로, private 필드의 경우는 prefix로 _ 문자를 붙여 사용하는 경우는 있다. 또는 웹개발에서 request parameter의 경우에 대해서는 q_ 를 prefix로 사용하는 등의 비범용 규칙을 사용하는 경우는 본 것 같다.

이 에 대해 저자는 유지보수성 및 가독성을 높이기 위해 범위에 따른 prefix 명명 규칙을 제안하고 있다. 예를 들어 지역변수의 경우는 prefix를 사용하지 않고 메소드 인자의 경우 a를 필드명의 경우 f를 prefix로 사용하는 것이다. 다음의 코드를 보자.

public boolean equals(Object aOther){
   if( ! (aOther instanceof Range)) return false;
   Range other = (Range)aOther;
   return fStart.equals(other.fStart) && fEnd.equals(other.fEnd);
}

위의 코드에서보면 메소드 인자를 aOther라 명명하고 있으며 필드를 fStart, fEnd로 명시해 필드임을 분명히 하고 있다. 아무런 prefix없는 other는 해당 영역에서 사용되는 지역변수임을 한눈에 볼 수 있다.

저자의 생각에 동참.

레이어별 패키징과 특징별 패키징

웹 개발을 하다보면 패키지명을 레이어별로 짓는 경우가 대부분이다. 즉, dao, controller, manager, entity 등이 그것이다. 하지만 본래 패키지명은 관련기능별로 묶어 사용하는 경우가 일반적인 자바에서 제시하는 기준이다. 패키지 범위에서의 은닉성을 가질 수 있기 때문이다.

따라서 저자는 기본 자바의 기준에 따라 웹개발에서도 레이어별 패키징보다는 특징별 패키징을 해야 한다는 이야기를 한다. 즉, com.apex.painting 패키지라면 그 안에 다음과 같이 파일들이 위치되어야 한다는 것이다.

• Painting.java(entity)
• PaintingDAO.java(dao)
• PaintingController.java(controller, action)
• PaintingService.java(service, manager)
• view.jsp

하지만 저자가 생각지 못한게 있는것 같다. entity는 대체로 DB의 table별로 생성되는게 많고 dao는 entity들을 그룹(parent-child관계가 있는 테이블들 끼리)으로 묶어 사용하는 경우가 많으며 service 부분은 업무별, controller는 화면별로 클래스를 생성해서 사용하게 된다는 것이다. 이렇게 하는 경우 위의 예시처럼 하나의 패키지에 같이 관련 클래스들이 들어가지 못하고 특징별로 패키징을 하더라도 사용되는(또는 참조되는) 클래스들이 다른 패키지 여기저기에 흩어지게 되어 똑같은 상황이 연출될 것이다.
즉, 웹개발에서 사용되는 클래스들은 하나의 차원으로 묶이지 않고 다수의 차원에 의해 구분되기 때문에 하나의 기준으로 패키징을 하게 되면 결국 다른 차원들에 의한 분류 기준에는 부합하지 않게 되는 것이다.

퍼시스턴스 객체의 생김새 및 사용법

요즘 entity 객체는 인자없는 생성자와 private field들, 모든 field들에 대한 public getter, setter로 이루어지는 경우가 대부분이다. 저자는 이 부분에 대해서는 일반적인 자바 코딩 규칙과 어긋난다는 이야기를 한다. 인자가 반드시 주어져야 하는 생성자가 필요하거나 getter, setter 중에는 protected도 있고, 어떤 메소드는 몇몇 관련있는 인자로 field를 채우기도 하는 방식이 개념적으로 적당해 보인다.

역시 이 부분은 저자가 개념적으로는 적당하게 접근하고 있는것 같지만 현실적으로 entity는 DB와 연동되며 이를 수작업으로 하지 않고 jpa 구현체나 hibernate, ibatis 등의 orm 툴을 이용하게 되는데 이들 현실에서 사용되는 solution들은 reflection을 이용해서 값을 읽고 채우기 때문에 인자없는 생성자, private field들과 모든 field에 대한 public getter, setter를 요구하게 된다. 물론 반드시 요구하는 것은 아니지만 위와 같이 생성된 entity로 작업하는 것이 매우 편리하다. 따라서 개념적인 면은 맞지만 현실적으로 생산성을 높이는데는 저자의 생각이 부적당하다고 판단된다.

private 멤버의 위치

클래스의 소스를 보면 대체로 private 필드들이 나오고 public getter, setter 메소드들이 그 아래쪽에 붙게 되는데 이는 잘못된 관행으로 보인다. 클래스를 이해하고 사용하는 개발자의 입장에서 보면 어떤 interface가 있는지가 중요하지 그 클래스의 내부 필드를 봐야할 필요는 없다.(해당 클래스를 개발한 개발자는 필요하겠지만) 이런 관점에서 본다면 클래스 소스에서 제일 위쪽에 public, 그 다음 protected 마지막으로 private을 작성하는 것이 올바른 방법인것 같다.

저자의 생각에 동감한다. 다만, 문서(javadoc과 같은)를 보고 클래스를 이용하는 개발자의 경우는 클래스 소스를 볼 필요가 없으므로 결국 클래스 소스를 보고 어떤 필드들이 private인지 public인지를 봐야 할 필요가 있는 사람은 대체로 해당 클래스를 수정하는 개발자일텐데 이들은 해당 클래스를 구성하는 모든 필드나 메소드를 살펴야 하기 때문에 실효성에 있어서는 어떨지 모르겠다. 물론 오픈소스가 많아지면서 문서가 오히려 줄고 직접 소스를 보면서 참조하는 경우도 많기 때문에 어떨지 모르겠지만, 이클립스와 같은 IDE 툴의 도움을 얻는다면 이야기는 좀 달라지지 않을까 싶다.

전반적으로 근본적으로 생각해 봐야 할것들에 대한 주제를 던져준 저자에게 고맙다는 이야기를 해야 하겠다.

원문 : http://www.javaworld.com/javaworld/jw-07-2008/jw-07-harmful-idioms.html

이올린에 북마크하기(0) 이올린에 추천하기(0)

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.