![]()
싱글톤 패턴이든 스프링 같은 싱글톤 컨테이너를 사용하든 객체 인스턴스를 하나만 생성해서 공유하는 싱글톤 방식은 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지(stateful)하게 설계하면 안된다. 그러므로 무상태(stateless)로 설계해야 한다. 특정 클라이언트에 의존적인 필드가 있으면 안된다. 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다. 가급적 읽기만 가능해야 한다. 필드 대신에 자바에서 공유되지 않는 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다. 스프링 빈의 필드에 공유 값을 설정하면 상황이 심각해지니 조심하자 이런 식으로 StatefulService를 만들고 테스트를 실행해 보자. 사용자 A와 B가 10000원, 20..
![]()
일반적인 자바 프로그래밍 웹은 보통 여러 고객이 동시에 요청을 한다. 일반적인 자바 프로그래밍에서는 고객이 요청을 할 때마다 객체를 생성(new)한다. memberServiceImpl()을 리턴해주는 memberService 객체를 두 개 만들어서(new) 출력해보자. 각 memberService 객체를 보면 서로 다른 두 개가 생성이 된 것을 확인할 수 있다. 문제점 MemberService 객체를 생성할 때 MemberServiceImpl 객체만 생성하는 것이 아니라 MemberServiceImpl의 인자 값으로 넘겨준 memberRepository()에서의 MemoryMemberRepository() 또한 생성되기 때문에 고객의 요청이 들어올 때 마다 2개의 객체가 생성된다고 볼 수 있다. 트래픽이..
SOLID SRP : 단일 책임 원칙 (Single Responsibility Principle) OCP : 개방-폐쇄 원칙 (Open/Closed Principle) LSP : 리스코프 치환 원칙 (Liskov Substitution Principle) ISP : 인터페이스 분리 원칙 (Interface Segregation Principle) DIP : 의존관계 역전 원칙 (Dependency Inversion Principle) 단일 책임 원칙 (SRP) 한 클래스는 하나의 책임만 가져야 한다. -> 여기서 하나의 책임이라는 말이 애매한데, 문맥과 상황에 따라 클 수도 있고, 작을 수도 있다. 중요한 기준은 변경! 변경이 있을 때 파급 효과가 적으면 SRP를 잘 따른 것이라고 보면 된다. ex) U..
![]()
객체를 사용하는 두 가지 방법 첫 번째 그림은 A가 B와 C를 직접 생성해서 사용하는 것이므로 A가 갑이라고 할 수 있다. 두 번째 그림은 A가 B와 C에게 요청을 해서 받아온 것을 setter()나 construct()로 주입하기 때문에 A가 을, B와 C가 갑이라고 할 수 있다. A에서 B나 C, X, Y, Z 등의 클래스를 요청을 하면 IoC 컨테이너에서 이를 넘겨주는데 이때 IoC 컨테이너는 스프링이라고 할 수 있다. IoC는 Inversion of Control 인데, 갑과 을 관계 즉, 개발자와 프레임워크의 관계가 역전되었다는 의미이다. 개발자 입장에서는 객체의 제어권이 컨테이너에 넘어갔다고 할 수 있다. A가 B와 C를 생성하여 라이프사이클을 관리하게 되면 결합이 강해지기 때문에 관리하기가 ..
