DataSource 설정123456789101112// application.yml// DB를 나누기 위해, 메모리 디비를 두개 띄운다app.datasource.blue: url: jdbc:h2:mem:blue username: sa password: app.datasource.green: url: jdbc:h2:mem:green username:
Dependency inversion principle 상위레벨 모듈이 하위레벨 모듈에 의존하면 안된다. 상위/하위 모듈 모두 추상화에 의존해야 한다. 추상화는 구현체를 의존하면 안된다. 중요한점 OO의 핵심이다. IoC를 통해 상위래밸의 모듈을 하위레벨 모듈로 부터 보호하는 것이다. 이를 통해 OCP를 지키고, 새로운 요구사항을 반영 가능 예제 l
Interface segregation principle 클라이언트는 자신이 사용하는 메서드에만 의존해야 한다. 사용하지 않는 의존성을 갖고 있다면 인터페이스 변경시 재컴파일/빌드/배포가 필요하므로 독립적인 개발/배포 불가능 사용하는 기능만 제공하도록 인터페이스를 분리하여, 사이드이펙트 최소화 클라이언트 입장에서 인터페이스를 분리 흔하디 흔한 스타크래
Liskov substitution principle 상위타입 객체를 사용하는 프로그램은 상위타입 대신 하위타입 객체를 사용해도 클라이언트의 수정 없이 정상적으로 동작해야 한다. LSP 위반 사례 명세에 벗어난 값 리턴 명세에 벗어난 익셉션 발생 명세에 벗어난 기능 수행 instanceof / downcasting을 사용한것은 전형적인 LSP 위반 LS
Open-closed principle 확장에는 열려 있고 변경에는 닫혀 있어야 한다. (변화하는 부분을 추상화하여) 기능에 대한 변경/확장이 쉬워야한다. (확장 : 새로운 타입을 추가) 기능을 사용하는 코드는 고정된 추상(abstract, interface)에 의존하므로 소스코드의 수정이 이뤄지면 안된다. OCP를 위배하는 전형적인 특징 다운 캐스팅
Single responsibility principle 클래스는 하나의 책임만 가지며 클래스는 그 책임을 완전히 캡슐화 해야 한다. 여러 책임을 갖고 있는 DataViewer 클래스1234567891011121314151617181920212223// 개발자가 반드시 정복해야 할 객체 지향과 디자인패턴(106page 예제)class DataViewer
7.Observer 객체 사이에 1:N 의존관계를 맺고있으며, 한 객체의 상태가 변경되면 의존적인 다른 모든 객체들에게 통지하여 상태를 갱신할 수 있는 패턴 구조{: .center-image} 활용 두개의 추상화 개념이 있고 하나가 다른 하나에 대해 종속적일때, 각각을 별도의 객체로 캡슐화하여 재사용할 수 있음 한 객체에 변경으로 인해 다른 객체를 변경해
행동 패턴이란?책임 및 알고리즘을 어떤 객체에 할당하는 것이 좋은지 다룬 패턴 객체간의 교류방법에 대해 정의하여 런타임에 수행하기 어려운 복잡한 제어 구조를 패턴화 한 것 1. Chain of Responsibility 메시지를 보내고 처리하는 객체들 간의 커플링를 없애기 위한 패턴, 각 핸들러는 자신이 처리할 수 있으면 처리하고, 처리할 수 없으면 다
구조 패턴이란?더 큰 구조를 형성하기 위해 어떻게 클래스와 객체를 합성하는지에 관련된 패턴 인터페이스나 구현을 복합하는 것이 아니라 새로운 기능을 실현하기 위해 객체를 합성하는 방법을 제공하여 런타임에 복합 방법이나 대상을 변경할 수 있음 1. Adapter 클래스의 인터페이스를 원하는 형태로 변환하여, 서로 다른 인터페이스를 갖는 클래스들을 함께 동작
생성 패턴이란?인스턴스의 생성/합성 방법을 추상화하여 시스템이 어떤 서브클래스를 사용하지에 대한 정보를 캡슐화 누가, 언제, 무엇을, 어떻게 생성할 것인지 결정하는 데 유연성을 확보할 수 있다 1. Factory Method 객체를 생성하기 위해 인터페이스를 정의하지만, 어떤 인스턴스를 생성할지에 대한 결정은 서브클래스에게 위임 구조 활용 생성할 객체