들어가며: "객체를 누가 생성하고, 누가 연결하며, 누가 관리해야 하는가?"앞 장에서는 객체가 자신의 의존성을 직접 new로 생성하는 구조가 왜 단일 책임 원칙(SRP)과 개방-폐쇄 원칙(OCP)을 뒤흔드는지 살펴보았다. 객체가 자신의 비즈니스 로직뿐만 아니라 "타 객체의 생성 및 조립"이라는 무거운 책임까지 끌어안게 되면, 코드는 구체 클래스와 단단히 결합되어 작은 변화에도 쉽게 무너지는 취약한 구조로 전락한다. 그렇다면 객체지향의 이상을 실현하기 위해 객체 생성과 관리라는 거대한 책임은 대체 누가 가져야 할까? Spring이 제시하는 답은 단호하고 명쾌하다. "객체가 스스로를 제어하지 말고, 제3의 존재인 컨테이너(Container)가 객체를 제어하도록 만들자."이 수동적인 변화이자 거대한 거버넌스..

들어가며: "객체는 자신의 일을 해야 할까, 아니면 필요한 객체까지 직접 만들어야 할까?"앞 장에서는 객체지향 프로그래밍이 역할과 구현을 분리하고, 다형성을 통해 변화에 유연한 설계를 지향한다는 점을 다루었다. 하지만 실제 프로젝트 현장에서는 이러한 이상적인 구조를 지속해서 유지하기가 매우 어렵다. 그 근본적인 이유는 대부분의 객체가 자신의 본래 책임을 수행하는 것뿐만 아니라, 자신이 사용할 객체를 직접 생성하고 조립하는 책임까지 떠안고 있기 때문이다. 이번 장에서는 객체가 직접 객체를 생성하는 행위가 어떻게 객체지향의 유연성을 무너뜨리는지 철저히 파헤쳐 본다. 그리고 본인 스스로 다음 한 가지 명확한 결론을 깨닫도록 이끄는 것이 이번 장의 핵심 목적이다.💡 이번 장의 핵심 결론: "객체 생성(Cons..

들어가며: "Spring은 왜 IoC와 DI를 핵심 철학으로 선택했을까?"많은 개발자는 Spring을 처음 접할 때 @Component, @Service, @Autowired 같은 애노테이션부터 배우기 시작한다. 하지만 이러한 기능들은 Spring의 본질이 아니다. Spring이 해결하려 했던 문제를 이해하지 못하면 IoC(Inversion of Control, 제어의 역전)와 DI(Dependency Injection, 의존성 주입)는 그저 "객체를 대신 생성해 주는 단순 편의 기능" 정도로만 받아들이게 된다. Spring을 제대로 이해하려면 먼저 객체지향 프로그래밍(OOP)이 무엇을 목표로 했는지, 그리고 왜 현실에서는 그 목표를 달성하기 어려웠는지를 살펴봐야 한다. Spring은 새로운 프로그래밍 ..