pandaterry's 개발로그

모던 자바의 새로운 API들은 개발자에게 더 나은 코드를 작성할 수 있는 도구를 제공합니다. 하지만 이러한 API들의 설계 의도를 제대로 이해하지 못하고 사용하면 오히려 코드 복잡도를 높이고 성능을 저하시키며, 시스템 설계에 구조적인 문제를 야기할 수 있습니다. 이는 해외 자바 커뮤니티와 언어 설계자들도 지적하는 중요한 문제입니다. Optional: 메서드 반환 타입으로만 설계된 API 설계 의도: null을 명시적으로 표현Optional의 핵심 설계 의도는 "null을 반환할 수 있는 메서드의 반환 타입"으로 사용하는 것입니다. Java Language Architect Brian Goetz는 "Optional은 메서드 반환 타입으로만 사용하도록 설계되었다"고 명시했습니다. 안티패턴: 메서드 파라미터..

JPA와 도메인 모델을 함께 사용하면서 객체지향적으로 설계하다 보면, 조회 쿼리가 복잡해지는 문제에 직면하게 됩니다. 특히 페이지네이션이 필요할 정도의 복잡한 조회에서는 이 문제가 더욱 두드러집니다. 이는 해외 스프링부트 및 자바 커뮤니티에서도 오래 논의된 주제입니다. 실무에서 겪는 문제들 객체지향과 SQL의 근본적 불일치도메인 모델은 비즈니스 로직과 불변성 보장을 위해 풍부한 연관관계를 가져야 합니다. 하지만 이는 조회 쿼리를 복잡하게 만듭니다. JPA는 CRUD 보일러플레이트를 피할 뿐만 아니라 관리되는 엔티티에서 작업할 때 대부분의 수동 레포지토리 호출을 피할 수 있게 해줍니다. 하지만 동작이 신비롭게 느껴질 수 있으며, 쓰기에는 편리하지만 읽기에는 제어권이 부족한 것이 문제입니다. N+1 문제연관..

CH5. 책임 할당하기 도입부 공감이 되는 문장 책임 할당하는 것의 가장 어려운 지점은 어떤 객체에게 어떤 책임을 할당할지 정하는 것이다. 객체지향 설계에서 가장 중요한 것은 올바른 책임 할당입니다. 하지만 어떤 객체에게 어떤 책임을 할당해야 할지 결정하는 것은 쉽지 않습니다. 책임 할당 작업 자체가 트레이드오프 과정이며, 다양한 관점에서 설계를 평가할 수 있어야 합니다. 이번 장에서는 GRASP 패턴을 사용하여 책임을 올바르게 할당하는 방법을 학습합니다. GRASP는 General R..

옛날에도 읽었지만 업무를 하면서 체화가 안되었다고 판단해서 다시 읽어보면서 정리해보려 합니다. 여러번 읽어도 괜찮은 책이라 생각하기도 하고, 더 광범위한 사례가 필요할 때 다른 책도 구매해보려 합니다. 암튼 목표는! 데이터 중심 사고에서 어느정도 벗어나서 객체지향적인 사고를 해봐야겠습니다. 1. 협력협력이란?다양한 객체들이 영화 예매라는 기능을 구현하기 위해 메시지를 주고 받으며 상호작용하는 것여기서 협력에 참여하기 위해 수행하는 로직이 책임협력 안에서 수행하는 책임들이 모여 역할을 구성 메시지 전송객체 사이 협력을 위해 사용할 수 있는 유일한 커뮤니케이션 수단왜 유일하냐면, 내부 구현에 직접 접근할 수 없기 때문. 메시지 전송만을 통해 요청을 전달가능메시지 발신자가 메서드를 실행하여 메시지를 보내고, ..

서비스 클래스가 점점 무거워질 때, 우리는 한 번쯤 이런 생각을 합니다.“나는 오케스트레이션만 하니까 괜찮지 않나?”“도메인 객체는 그냥 데이터 구조잖아.”“유효성 검사는 서비스에서 다 하면 되는 거 아냐?” 실제로 몇몇 개발자들도 이런 구조를 문제 삼지 않고 넘기곤 합니다. SRP를 지켰다거나, 도메인을 분리했다는 형식적 명분으로 충분하다고 느낄 수도 있기 때문입니다. 하지만 진짜 중요한 건 그 구조가 정말 도메인의 책임과 역할을 반영하고 있는가입니다. 이번 글에서는 흔히 "이 정도면 괜찮다"라고 여겨지는 코드들이 실제로는 어떤 문제를 유발할 수 있는지를 검토하고, 그에 대한 개선 방향을 구체적인 코드와 함께 살펴보았습니다. 총 4가지 예시를 준비해봤습니다 :) 예시 1. OrderService – ..