책리뷰 (40) 썸네일형 리스트형 헤드퍼스트 디자인패턴 - 싱글턴 패턴 목차 고전적인 싱글턴 패턴 구현법 public class Singleton { private static Singleton uniqueInstance; private Singleton() {} public static Singleton getInstance() { if(uniqueInstance == null) { uniqueInstance = new Singleton(); } return uniqueInstance; } } Singleton클래스의 인스턴스를 저장하는 정적 변수를 선언 후 getInstance()메소드를 통해 인스턴스 생성한다. 싱글턴 패턴의 정의 싱글턴 패턴은 클래스 인스턴스를 하나만 만들고, 그 인스턴스로의 전역 접근을 제공한다. 실제로 하나뿐인 인스턴스를 관리하도록 만들면 된다. .. 헤드퍼스트 디자인패턴 - 팩토리 패턴 목차 NEW 의 문제 인터페이스에 맞춰서 코딩하면 어떤 클래스든 인터페이스만 구현하면 사용할 수 있다. 다형성 덕분에 가능하다. 반대로 구상 클래스를 많이 사용하면 새로운 구상 클래스가 추가될 때마다 코드를 고쳐야 한다. OCP - 변경에 닫혀 있는 코드. 최첨단 피자 코드 만들기 Pizza orderPizza(String type) { Pizza pizza = new Pizza(); pizza.prepare(); pizza.bake(); pizza.cut(); pizza.box(); return pizza; } 피자 종류는 여러가지가 될 수 있다. Pizza orderPizza(String type) { Pizza pizza; if(type.equals("cheese")) { pizza = new Ch.. 헤드퍼스트 디자인패턴 - 데코레이터 패턴 목차 초대형 커피전문점 주문시스템 만들기 다양한 음료를 모두 포괄하는 주문 시스템을 만들려고 한다. 만약 Beverage클래스에 우유, 두유, 모카, 휘핑크림을 추가하려고 할 때 인스턴스 변수를 추가하면 메뉴마다 서브클래스를 만들고 각각 cost()를 구한 후 슈퍼클래스에서 구현한 cost()를 호출해 첨가물 비용을 더한다. 인스턴스 추가로 발생하는 문제점 첨가물 가격이 바뀔때마다 기존 코드를 수정해야함 첨가물 종류가 많아지면 새로운 메서드를 구현해야하고, 슈퍼클래스의 cost()를 고쳐야 한다. 새로운 음료가 출시될 경우 첨가물이 들어가면 안되는 음료가 있을 수도 있다. (필요없는 메서드를 상속받음) 고객이 모카를 두 번 주문 할 경우가 있을 수 있다. ☝🏻 디자인 원칙 클래스는 확장에는 열려있어야 하.. 헤드퍼스트 디자인패턴 - 옵저버 패턴 목차 가상 모니터링 애플리케이션 알아보기 Weather-O-Rama와 계약하면 WeatherData객체로 현재조건, 기상통계, 기상예보 3가지 항목이 제공된다. 디스플레이 장비에 업데이트 하는 부분은 직접 개발 해야 한다. 가상 스테이션 코드 구현 WeatherData -------------------- getTemperature() getHumidity() getPressure() measurementsChanged() Weather클래스에는 가장 최근에 측정된 온도, 습도, 기압 값을 리턴하는 메소드가 있다 WeatherData에서 갱신된 값을 가져올 때마다 measurementsChanged() 메소드가 호출된다. 디스플레이를 구현하려면 3가지 요소를 구현해야한다. 디스플레이 업데이트하도록 mea.. 헤드퍼스트 디자인패턴 - 전략 패턴 목차 전략 패턴 (Strategy Pattern) 이란? 알고리즘군을 정의하고 캡슐화해서 각각의 알고리즘군을 수정해서 쓸 수 있게 해주는 패턴 전략패턴을 사용하면 클라이언트로부터 알고리즘을 분리해서 독립적으로 변경할 수 있음. 오리 시뮬레이션 게임(SimUduck) 오리 시뮬레이션 게임회사에서는 표준 객체지향 기법을 사용해서 Duck이라는 슈퍼클래스를 만든 후 그 클래스를 확장해서 다른 종류의 오리를 만들었다. 오리 시뮬레이션게임 차별화하기 기존 클래스에 오리가 나는 기능을 추가해서 게임을 차별화해야할 경우 ⚠️ 경고! 몇몇 서브 클래스만 날아야하는데, 적합하지 않은 일부 클래스에 나는 행동이 추가됨(ex: 고무 오리들이 날아다님) 상위클래스에 행동을 추가할 경우 코드를 재사용하는 점에서는 상속을 활용한.. 도메인 주도 개발(DDD)시작하기 CQRS 목차 단일 모델의 단점 주문 내역 조회 기능 구현시 여러 애그리거트에서 데이터를 가져와야함 시스템 상태를 변경할 때와 조회할 때 단일 도메인 모델을 사용하면 고민해야할 부분이 생김 조회화면 특성상 즉시로딩이나 지연로딩으로 처리해야함 CQRS Command Query Responsibility Segregation 복잡한 도메인에 적합 CQRS를 사용하면 각 모델에 맞는 구현 기술 선택 가능 ex) 명령 모델 > 도메인 모델(JPA), 조회모델 > DB테이블에서 SQL 쿼리(마이바티스) 조회모델은 응용서비스가 존재하지 않음 컨트롤러에서 바로 DAO를 실행해도 무방함 명령모델은 트랜잭션을 지원하는 RDBMS, 조회모델은 성능이 좋은 메모리기반 NoSQL사용도 가능 서로 다른 데이터 저장소 사용시 데이터 동기.. 도메인 주도 개발(DDD) 시작하기 이벤트 목차 시스템간 강결합 문제 쇼핑몰에서 구매 취소시 환불처리가 필요함 환불기능을 실행하는 주체는 주문 도메인 엔티티가 될 수 있음 보통 결제 시스템은 외부에 존재하기 때문에 외부 서비스가 아닐 경우 트랜잭션 처리가 애매함 주문은 취소상태로 변경 후 환불만 나중에 시도하는 방시긍로 처리할 수 있음 외부 시스템 응답 시간이 길어지면 대기 시간이 길어지기 때문에 성능에 대한 이슈도 있음 위와같이 도메인 객체에 서비스를 전달하면 Order도메인인데 결제 도메인의 환불 로직이 섞이게 됨 환불 기능이 바뀌면 Order도 영향을 받을 수 있음 주문 취소후 환불과 함께 취소 통지를 해야한다면 외부 서비스가 두 개로 증가하고 트랜잭션 처리가 더 복잡해짐 ☝️ 강한 결합을 없앨 수 있는 방법은 이벤트를 사용하는 것이다. 비.. 도메인 주도 개발(DDD) 도메인 모델과 바운디드 컨텍스트 목차 도메인 모델과 경계 처음부터 도메인을 완벽하게 표현하는 단일 모델을 만들기는 어렵다 도메인은 여러 하위도메인으로 구분되기 때문에 한 개의 모델로 여러 하위 도메인을 표현하기 어려움 시스템을 사용하는 사람을 회원 도메인에서는 회원, 주문 도메인에서는 주문자, 배송도메인에서는 보내는 사람이라고 부른다. 각 모델은 명시적으로 구분되는 경계를 이용해 섞이지 않도록 해야함 하위 도메인 모델이 섞이면 모델의 의미가 약해지고 각 도메인 별로 다른 요구사항을 반영하기 어려움 바운디드 컨텍스트 모델은 특정 컨텍스트하에서 완전한 의미를 갖는데, 같은 제품이라도 카탈로그 컨텍스트와 재고 컨텍스트에서 의미가 서로 다르다. 이렇게 구분되는 경계를 갖는 컨텍스트를 바운디드 컨텍스트라고 함 모델의 경계를 결정, 한 개의 바운.. 이전 1 2 3 4 5 다음
