토비의 스프링 6장 AOP를 읽고 더 나은 설계 및 테스트를 위한 내용을 별도로 정리합니다. 스프링의 ProxyFactoryBean의 설계를 보면서 기술적인 영역에서도 변하는 것과 변하지 않는 것을 구분하면 재사용성을 높일 수 있고 최소한의 노력으로 변경에 대처할 수

객체지향적인 코드는 다른 오브젝트의 데이터를 가져와서 작업하는 대신 데이터를 갖고 있는 다른 오브젝트에게 작업을 요청한다. 오브젝트에게 데이터를 요구하지 말고 작업을 요청하라는 것이 객체지향 프로그래밍의 가장 기본이 되는 원리이기도 하다. 테스트 코드와 애플리케이션 코

다루고 있는 코드의 덩치가 커지면 문제의 원인을 찾는게 어려워 진다. 문제와 관련있을 법한 코드를 내 머리에 담지 못한다. 들어가지를 않아 아무것도 담지 못했으니 무엇 부터 손대야 될지 모르겠는 막막한 상태에 놓이곤 한다. 결국 내 머리에 담을 만한 단위로 나누어 내지

하루를 돌아보며 오늘 했던 몇 가지 설계 결정 사항들의 이유를 정리하는게 쉽지 않다. 뭔가 이거다 싶어서 방향을 잡고 나아갔는데 처음 생각과는 달리 새로운 상황을 계속 마주하며 어떻게 어떻게 나아간 느낌이 더 많이 든다. 그래도 하나씩 정리해 보자. 하나의 전송 메시지

프로젝트가 끝날 때까지 메시지가 추가되지 않을 것 같다면 if-else 체인으로 그냥 처리해도 될 것 같다. 좋은 디자인 패턴을 먼저 적용하려고 하기 보다 테스트를 통과하는 코드를 빠르게 작성하고 코드를 점진적으로 개선해 나가는게 더 도움이 된다. 어제 읽기모임을 통해

토비의 스프링 3장(템플릿)에서 거대하고 복잡한 하나의 메서드에서 변하는 것과 변하지 않는 것을 분리하며 객체지향의 핵심 원칙(개방폐쇄원칙)을 점진적으로 구현해 나가는 과정을 보여줍니다. 중복을 제거하고 재활성을 높였으며 변경에는 닫혀 있고 확장에는 열려있는 이 코드를

토비의 스프링을 읽고 인상적이었던 부분과 느낀점을 정리합니다.매 장을 읽을 때 마다 새롭고 좋습니다. 3장이 변하지 않는 것과 변하는 것을 분리하는 개념이 나오는데 책에는 스프링이 버전업 되어도 변하지 않는 가치가 풍성하게 담겨있다는 생각이 듭니다. 3장에서 하나의 메

처음으로 배운 프로그래밍 언어는 대학 1학년 때 C 언어였다. 그리고 다음해 Java를 배우는데 과제를 엄청 내주셨다. C 수업에서 구구단 출력하기 같은게 과제였다면 Java 수업에서는 도서관 대출 프로그램 같은게 과제로 나왔다. 그때 나는 프로그래밍을 그만하고 싶을