Agile Java Lesson 11

기본

입출력(I/O)

이번 레슨부터 난이도가 부쩍 올라갔습니다. 그래서 테스트 코드 자체도 이해하기 좀 어려웠고 뒷쪽에 나와있는 RandomAccessFile 을 이용한 객체를 직렬화한 후 세이브/로드하는 DB 예제는 코드 이해하는데 한참 걸렸네요. DB를 만드는 이유는 강의 정보는 학기별로 거의 달라지지 않으므로 영속성을 유지하자는 거지요. 단, 수강한 학생에 대한 정보는 매번 달라질 수 있으므로 id(key)만 따로 저장합니다.

레슨은 Java IO에 대해서 설명을 하고 있는데 바이트 스트림부터 문자 스트림, 파일 시스템을 거쳐 객체 직렬화까지 단계 별로 TDD 기반의 예제가 나옵니다. (와우!) TIJ I/O 부분을 좀 봐둔게 도움이 컸네요. Java를 이 책으로 처음 시작했다면 아마 이 부분부터는 다른 책도 참고해야 하지 않을까 싶습니다.

저자는 Java의 IO를 두고 ‘완벽하다’라는 말을 합니다. 단, 그렇기 때문에 복잡하다는 말도 덧붙이죠. Java IO가 데코레이터 패턴을 썼다는 것은 누구나 다 아는 내용이지만, 그건 바이트스트림 기반(Java 1.0) 얘기고 Java 1.1에 추가된 문자 기반 Printer/Writer 클래스들과 Java 1.4에 추가된 nio는 상속을 하고 있는 정도입니다. 하지만 일반적으로 IO를 말할 땐 바이트 스트림 기반과 문자 기반을 합쳐서 말하기 때문에 더 복잡해 보일지도 모르겠습니다.

책 중간 부분에 UI Test라는 흥미로운 주제를 다루는데요. UI는 특히 웹 개발에서 테스트 하기 어려운 부분입니다. 저번 달인가요? 버즈에서 웹 UI 테스트 프레임워크를 소개하는 글이 있었는데 많이 사용되는 테스트 프레임워크를 보니 형식이 사용자가 어떤 액션을 취할 것이다라고 시나리오를 만든 후 그대로 이벤트를 발생시키게끔 하는 형식이었습니다. 책에 나와있는 UI 테스트도 그런 형식과 비슷합니다.

직렬화는 Serialization 인터페이스를 구현하면 플래그 역할을 해서 어떤 메소드를 구현하지 않고도 쉽게 직렬화가 가능합니다. 그런데 객체 필드에 동적으로 계산되는 데이터 구조나 필드가 있을 경우 이를 그대로 직렬화 시켜 저장하는 것은 프로그램의 동작을 느리게 만들고 공간의 낭비가 될 수 있으니 transient로 직렬화를 하지 않는 식으로 관리해 줘야 합니다. 또한 serialVersionUID로 직렬화 버전 관리에도 주의를 기울여야 합니다.

레슨의 끝 부분에 DB를 구현하기 위해 하나의 테스트 클래스에서 시작해 다른 테스트 클래스, 다른 테스트 클래스 식으로 계속 옮겨가며 개발을 진행하는데에 대해 저자가 하는 말이 인상적이네요.

클라이언트 코드가 클래스를 사용하고자 하는 방법을 결정하면 그 인터페이스를 기반으로 설계를 만들어 나간다.

저자는 항상 설계는 유동적인 상태라고 생각하기 때문에 설계를 바꾸는 것이 지극히 정상적인 일이라고 합니다. 물론, 가장 외부에 있는 인터페이스는 안정적으로 유지해야 하지만 그 세부 사항은 자주 바뀔 수 있습니다. 설계의 변경은 뭔가 막연하고 어려운게 아니라 단지 작은 코드 부분을 다른 곳으로 옮기고 개선하는 과정일 뿐입니다. 설계에서 왠만하면 변경하지 말아야 할 부분은 바로 시스템과 상호작용을 하는 인터페이스 부분입니다. 따라서 가장 중요한 부분이라고 할 수 있죠. 나머지는 구현하는 과정에서 설계를 개선시켜 좀 더 나은 시스템을 만들어 낼 수 있습니다.

Advertisements

답글 남기기

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

WordPress.com 로고

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

Twitter 사진

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

Facebook 사진

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

Google+ photo

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

%s에 연결하는 중