쉼, 그리고 망설임 없는 마침표. 쉼, 그리고 망설임 없는 마침표.

이전 장에서 말한 것처럼 Spring에서 가장 중요한 3가지 개념 중 하나인 AOP(Aspect Oriented Programming:애스펙스 지향 프로그래밍) 이다. 계속 말하지만, Spring이 추구하는 가장 중요한 개념은 서비스 추상화이다. (이것은 결국 객체지향 프로그램의 근본적인 목표이기도 하다.) 그리고 AOP 역시 서비스 추상화의 한 축을 담당하고 있는 것이다. 일반적으로 서비스 추상화를 위해서는 IoC/DI 개념을 바탕으로 인터페이스를 사용하면 된다. 하지만 책에서 소개된 바와 같이 트랜잭션과 같은 경우 각 메소드에 강한 응집력을 가지고 있지만, 해당 메소드의 코드 내에 트랜잭션 관련 코드를 매번 삽입해야 하므로 낮은 결합도를 유지할 수 없다. 따라서 일반적인 방식의 서비스 추상화를 이루기..

Spring에서 중요한 3가지 개념이 있는데, 바로 IoC/DI, 서비스 추상화, AOP 이다. 이 중 JAVA라는 객체지향 프로그램과 이를 이용한 Spring 프레임워크가 지향하는 가장 중요한 개념을 꼽으라면 바로 서비스 추상화일 것이다. (심지어 IoC/DI는 이 서비스 추상화를 용이하게 하기 위한 부차적인 개념이라고 봐도 무방하다는 생각이다.) 추상화란 하위 시스템의 공통점을 뽑아내서 분리시키는 것을 말한다. 그렇게 하면 하위 시스템이 어떤 것인지 알지 못해도, 또는 하위 시스템이 바뀌더라도 일관된 방법으로 접근할 수가 있다.(본문 p.371) 다시 말해 서비스 추상화를 적용한다는 것은, 코드들을 비슷한 것들끼리 모으고(강한 응집력) + 서로 다른 코드들이 서로를 구속하지 않는(낮은 결합도) 프로그..

지난 번에 다니던 회사에서는.. 경우에 따라(라고 쓰고 매번이라 읽어야 한다) 다른 사람들이 만들어 놓은 소스를 수정해야 할 필요가 있었다. 보통 프로젝트를 진행한 사람들은 따로 있고, 이 사람들이 일을 대충 해 놓고 사라지면 그 일을 마무리 하거나 버그를 수정해야 하는 건 모조리 내 몫이었기 때문이다. 대개 이런 경우 - 일이 하기 싫었는지, 아니면 시간이 턱없이 부족했는지, 그것도 아니면 애초에 실력이 부족한건지, 아니면 그 모든 이유가 복합적으로 작용했든지.. 상식적으로 이해하기 어려운 코드들이 작성된 경우가 많았다. 그 중에서도 특히 잦은 것은, 예외처리가 되어 있지 않은 경우였다. 다수의 메소드가 하나의 프로세스를 이룰 때, 어느 하나에서 오류가 나는데도 그냥 프로그램은 흘러간다거나.. 아니면 ..

새로 나온 a77을 구매한 후 잠깐 잠깐 카메라 셔터를 눌러 볼 뿐 제대로 사진을 찍어 볼 기회가 없다. 엊그제 잠깐 나갔다가 돌아 오는 차 안에서 황혼 빛이 아름답기에 카메라를 집어 들었다. 조수석에 앉아 차 앞유리 너머의 풍경을 찍었다. 차의 다른 부분들이 화각에 들어 오지 않도록 하기 위해 노력했는데, 의외로 좋은 구도의 사진이 된 것 같다. 얻어 걸렸다. ^^ 집에 다 와서 보니 완전 어스름녘이다. 멀리 미명이 눈에 들어와 사진을 몇 장 더 찍었다. 원래 이런 사진을 찍을 때는 당연히 ISO 감도를 낮추는데.. a77의 고감도 노이즈가 얼마나 좋은가 보기 위해 그냥 ISO 오토로 놓고 찍어 봤다. 결과는 약간 실망, 노이즈 입자가 상당히 거칠다. 라룸으로 깎아도 저 거친 노이즈는 쉽게 제거 되지 ..

이번 장에서는 템플릿과 콜백의 개념, 그리고 이것들을 적용해야 할 상황과 이를 구현하는 방식에 대해 설명한다. 템플릿과 콜백은 객체지향 설계의 핵심 원칙인 개방폐쇄원칙과 깊은 관계가 있다. 개방폐쇄원칙 개발된 코드 중 어떤 부분은 변경을 통해 그 기능이 다양해지고 확장하려는 성질이 있고, 어떤 부분은 고정되어 있고 변하지 않으려는 성질이 있을 때 변화의 특성이 다른 부분을 구분해주고, 각각 다른 목적과 다른 이유에 의해 다른 시점에 독립적으로 변경될 수 있는 효율적인 구조를 만들어 주는 원칙을 말한다. (본문 211p) 한마디로 말해서, 반복적으로 재사용 되는 코드를 별도로 묶어서 언제든 재활용할 수 있도록 만들어야 한다는 것이다. 사실 이게 객체지향의 핵심인데, 그 중 템플릿/콜백은 메소드나 클래스와는..

프로그램을 개발할 때 테스트가 얼마나 중요한지에 대해서는 말해봐야 입만 아프다. 하지만 테스트가 얼마나 중요한지 아는 것과, 테스트를 실제로 수행하는 것과는 약간의 차이가 있다. 프로젝트를 진행할 때 당장 코드 써내려가기만도 바빠 죽겠는데 테스트까지 면밀하게 하기가 여간 어렵지 않기 때문이다. 통상적으로 웹프로그램 테스트를 한다고 하면 WEB UI위에 올려 놓고 하는 경우가 많다. 하지만 이는 클래스나 모듈에 대한 단위테스트로는 매우 부적절하다. 프로그램이 오류가 났을 때 이게 지금 개발한 클래스나 모듈의 문제인지, 브라우저의 문제인지, 서버의 문제인지 기타 다른 부분의 문제인지 알기가 쉽지 않기 때문이다. 따라서 작성코드에 대한 단위테스트는 WEB UI가 아닌 실행 가능한 자바 클래스 자체에서 수행해야..

클래스간에 의존관계를 주입하는 방법에 대해서 설명하고 있다. 클래스 모델이나 코드에서 각각의 클래스들간의 관계를 직접 지정하게 되면, 향후 클래스나 코드의 변경이 일어날 때 마다 관련된 모든 코드를 손봐야 한다. 이는 소프트웨어 개발 시 높은 응집도와 낮은 결합도를 고려해야 한다는 원칙에 위배된다. 따라서 클래스를 개발 할 때 IoC(Inversion of Control)과 DI(Dependency Injection)을 고려해 개발한다. 사실 뭐 이 정도는 그리 대단한 내용이 아니다. 스프링 아니어도 기존에 개발할 때 마다 늘 하던 일이기도 하다.(xml이나 배열등의 노가다로) 하지만 스프링을 쓰면 이런 작업들을 하나하나 수동으로 하는 대신, 스프링의 특정 기술을 쓰면 된다. 거기에 더해, 싱글톤 레지스..

너무나 강렬한 인상의 그림 - @방콕 수쿰빗 여행에서 돌아온지 오늘로 6일째 - 시간이 어떻게 지나갔는지 모르겠다. 아마도 추석이 껴있다보니 더 그런 것 같다. 돌아오면 해야 할 일이 꽤 많았는데.. 아직 그다지 많이 처리하지 못했다. 그러고보면 한 이틀 정도는 그냥 멍하니 보낸 것 같다. 현실은 그다지 녹록지 않아, 얼른 정신을 차리고 다음 목표를 향해 가야 할텐데.. 딱히 여행지에 마음을 놓고 온 것 같지도 않은데.. 붕 떠 있는 마음을 추스르기가 어렵다. 사진과 여행기를 정리하고, 여행의 목적을 되새기자고 마음 먹었지만.. 하드디스크에 사진을 옮기기만 했을 뿐, 엄두도 내지 못하고 있다. 하긴.. 그 전에 블로그부터 싹 정비해야겠지. 자, 다시 시작이다.