Agile Java Lesson 4, 5

기본

레슨 4 부터는 본격적으로 클래스에 대한 얘기가 나옵니다. 그러면서 메소드 디자인 하는 방법에 대해 말하는데, 객체의 상태를 바꾸거나 정보를 반환하는 것 중 한 가지만 하도록 디자인 해야 한다고 합니다. 그런데 가끔 위의 두 가지를 하지 않고, 매개변수에 대한 연산만 하고 반환하는 메소드가 있는데 이를 유틸리티 메소드(다른 언어에선 함수)라고 합니다. Java에서 대표적인 유틸리티 메소드를 가진 클래스로 Math가 있죠. 이런 유틸리티 메소드 같은 경우엔 객체를 생성하는게 의미가 없기 때문에 클래스 메소드(static)로 만드는게 좋습니다.

클래스 메소드나 변수를 사용할 때는 클래스명.멤버 식으로 호출해 주는게 좋습니다. 그렇지 않을 경우 불필요한 혼란을 줄 수 있습니다. 또한 static import 역시 무분별하게 사용할 경우 불필요한 혼란을 일으킬 수 있습니다. 책에선 만약 클래스 멤버 호출이 많아질 경우, 왜 이런 호출이 필요한지 생각해 보고 디자인을 바꿔보라고 합니다.

static import가 적절히 사용될 수 있는 부분은 어떤 클래스에 모여있는 관련있는 클래스 상수들을묶어서 하나의 클래스로 만든 후, static import를 사용해 편하게 사용하는 겁니다. 단, 여러 곳에서 자주 사용되는 요소를 클래스 멤버로 만드는게 좋습니다. 또한 클래스 멤버 호출로 코드가 너무 지저분해질 경우 정리하기 위해 사용될 수 있습니다.

static import는 어느 클래스 내부에 있는 클래스 멤버들을 가져오는 것으로, 다음과 같이 사용할 수는 없습니다.

import static java.lang.*;

저자가 말하는 클래스 멤버 사용 기준

클래스 멤버가 필요하질 때까지 사용하지 않는다.

오버라이딩된 생성자가 늘어나고 점차 객체 생성이 복잡해 짐에 따라 책에서 팩토리 메소드를 소개합니다. 팩토리 메소드는 보통 클래스 메소드로 만들고 객체 생성을 하는 역할을 맡습니다. 팩토리 메소드가 객체 생성을 전담하기 위해 생성자엔 private 접근자를 붙여 더이상 new로 객체 생성을 할 수 없습니다. 팩토리 메소드의 가장 큰 장점은 알기 쉬운 이름을 붙일 수 있다는 겁니다.

객체 지향 디자인의 중요한 부분 중 하나는 코드의 의미가 명확하고 의미상 알맞은 부분에 위치하도록 하는 것입니다. 물론 항상 처음부터 ‘알맞은 곳’에 위치시킬 순 없습니다. 하지만 좀 더 나은 위치를 알게 되면 리팩토링 해야합니다.

책에서 단순한 디자인에 관해 설명하는 부분이 있는데 아마 이 책에서 말하고자 하는 바가 담긴 핵심적인 내용 같습니다.

항상 코드를 깨끗하게 유지하라.

  • 테스트가 항상 100% 녹색인 것을 확인한다.
  • 중복을 없앤다.
  • 코드가 깨끗하고 명확한지 확인한다.
  • 클래스와 메소드 수를 최소화한다.

현재의 기능을 지원하기 위한 것보다 더 많은 설계를 포함하지 마라.

TDD에서 말하는 테스트에 대해서도 흥미로운 내용이 있습니다. 테스트는 단지 코드가 올바른지 검사하는 도구가 아니라 일정한 속도로 개발하는 방법을 제공하고 점진적으로 코드를 추가해 나가는 방법을 알려주며 올바르게 개발을 하고 있는지 신뢰감을 준다는 것입니다.

TDD는 시스템의 설계에 영향을 주기 위해 하는게 아니라 쉽게 테스트할 수 있는 시스템을 만드는데 목적이 있으며, 테스트 하기 쉬우려면 테스트할 부분이 시스템의 다른 부분과 분리돼 있어야 하기 때문에 OOD의 원칙과 맞닿아 있다고 할 수 있습니다.

그렇다고 TDD가 코드의 결점을 완전히 없애는 은총알은 아니며 TDD가 말하고자 하는 핵심 가치는 피드백의 중요성이 아닌가 합니다.

레슨 5는 인터페이스와 다형성을 다룹니다. 인터페이스의 단골 메뉴인 Comparable이 예제로 나옵니다. 저는 Comparable/Comparator 를 처음 봤을 때 어떤 행동을 주입시키는 광경을 보고 좀 놀랬던 기억이 있습니다. 인터페이스는 코드 상속이 안되는 이상한 녀석일 뿐이라는 생각을 송두리째 날려 버렸다고 할까요?

인터페이스는 상속 보다 한 단계 더 높은 추상화를 제공함으로써 인터페이스를 구현하는 구체 클래스나 이를 사용하려는 클라이언트 사이에 단 하나의 통로를 만들어 줍니다. 이 통로가 있는 한 구체 클래스와 클라이언트는 서로를 몰라도, 서로가 변화해도 소통할 수 있습니다. 문제는 클라이언트에서 인터페이스를 사용할 때 구체 클래스를 알아야 하는 아이러니한 점인데 이 문제는 DIP 원칙으로 우아하게 해결할 수 있습니다.

책에서 enum 클래스가 나오는데, enum 클래스는 static final 변수 대용으로 사용할 수도 있지만 그 태생이 static이란 점을 활용해 이펙티브 자바에선 최고의 싱글턴용 클래스로 소개 되며, 기초 자료형이 아닌 클래스 이기 때문에 enum 클래스 내부에 생성자만 만들어 줘도 정말 유용하게 써먹을 수 있습니다.

연습 문제로 나오는 체스가 점점 복잡해 지고 있습니다 (…)

Advertisements

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중