Easy Understanding

- 필요 개념: 상속, 컴포지션 - 활용도:사용할일이 많지는 않지만, 읽을 일이 많은 개념 - 난이도: 구조 자체는 심플하지만, 관련 기술이 복잡하다. - 패턴이 필요한 상황: 접근 제어, 메서드 기능 추가 다양하게 활용 가능 프록시의 구현 방법은 데코레이터 패턴과 비슷한 면이 많다. interface A { void doSomething(); } class AImpl implements A { public void doSomething(){ ... } } 이런 간단한 인터페이스와 클래스가 있다고 하자. 이 doSomething() 바깥에서 특수한 처리를 하고 싶다면 (누가 요청했는지 확인해서 막는다든지, 로깅을 하고 싶다든지 정말 다양한 이유로) 이렇게 처리하면 된다. class AProxy imp..

이번엔 3가지 패턴을 한 번에 정리한다. 생각보다 간단하고 활용성이 클 것 같지 않아서 정리하다보니 내용이 짧아졌고 그래서 합치게 되었다. 반복자 패턴 - 필요 개념: 컬렉션 - 활용도:필요하다면.. - 난이도: 간단 - 패턴이 필요한 상황: 컬렉션을 통합적으로 사용할 필요가 있을 때 모든 언어에는 여러 컬렉션이 존재한다. 자바의 경우는 다음과 같은 것이 대표적이다. List list; String[] arr; Map map; Set set; 그런데 여러 컬렉션들을 사용할 때 클라이언트에서는 이걸 같은 코드로 사용하고 싶을 때가 있다. 다양한 인터페이스 구현체들을 사용할 때 세부 구현체를 몰라도 되는 것처럼, 컬렉션도 비슷하게 처리할 수 있으면 좋은데, 그 대표적인 명세가 바로 Iterator 이다...

- 필요 개념: 간단한 상속, 추상 클래스 - 활용도:가끔 - 난이도: 간단 - 패턴이 필요한 상황: 코드의 큰 틀만 잡아주고,세부 구현은 클라이언트에게 맡기고 싶을 때 코드를 작성하다보면 항상 특정 Use-Case라는 것이 존재하고, 비즈니스에서는 이게 꽤나 복잡하게 엮일 수가 있다.다음은 하나의 흐름의 예시이며, 이런 코드야 비일비재한 코드다. 1. 데이터베이스에서 불러오기 2. 데이터 가공 처리 3. 데이터 로깅 4. 데이터 변환 5. 다시 저장 6. 이벤트 발행 7. 이런 일련의 작업들을 트랜잭션 처리 그런데 만약 이런 로직들에 대해서 여러 구현체에서 같은 flow를 따라야 한다고 해보자. 비디오나 소설, 웹툰 등의 서비스를 제공하는 곳에서는 분명 종류는 다르지만 공통의 Flow로 무엇인가를 ..

파사드 패턴 - 필요 개념: 상속이나 컴포지션과는 상관 없긴 함 - 활용도:가끔 - 난이도: 간단 - 패턴이 필요한 상황: 클라이언트 코드가 너무 길고 복잡해질 때 바로 스프링의 예시로 들어가보자. 스프링에서 컨트롤러를 작성할 때 여러 구현 철학들이 있지만 난 이런 식의 구현을 별로 좋아하지 않는다. 그래서 좀 정리를 해보고자 한다. @RestController @RequiredArgsConstructor public class AggregationController { private final UserService userService; private final PaymentService paymentService; private final OrderService orderService; priva..

어댑터 패턴 - 필요 개념: 컴포지션 - 활용도:가끔 - 난이도: 구현 자체는 간단함 - 패턴이 필요한 상황: 현재 개발한 코드와 비슷한 기능을 가진 다른 코드를 연동해야 할 때 어댑터 패턴은 그냥 사용하고 싶다고 사용할 수 있는 패턴은 아니다. 그 전제조건은 코드 자체가 오래되고 다양한 사람들이 개발하면서 쌓여온 소스코드여야 한다. 애초에 이 패턴은 이런 상황에 사용하는 것이다. - 새로운 api를 개발하는데 비슷한 이전 코드가 존재하기는 한다. 그런데 뭔가 매개변수도 다르고 구조도 다르다. - 여러 사람이 개발을 하는데 어쩌다보니 각자의 코드가 각자의 인터페이스를 갖고 있고 이게 도저히 수정할 수가 없는 구조다. 어댑터 패턴을 적용하는 것보다 더 좋은 것은 어댑터 패턴을 이용하지 않는 것이다. 인터..

싱글턴 패턴 - 필요 개념: 멀티스레딩 - 활용도:빈번함 - 난이도: 쉬움 - 패턴이 필요한 상황: 어플리케이션 내에 하나의 객체만 필요할 때 사용 일반적으로 스프링 프레임워크를 사용한다면 싱글턴 패턴을 직접 구현할 일은 없다. 게다가 웹에서는 대부분의 객체가 Request 라는 생명주기를 가지고 생성되곤 한다. 즉 하나의 요청에 하나의 객체가 생성이 되고, 동시에 여러 개가 생길 수가 있는 것이다. 그러나 모든 코드에서 한 객체를 동시에 봐야하는 경우가 있는데 이럴 때 사용해야 하는 것이 싱글턴 패턴이다. 싱글턴 객체가 내부에 프로퍼티 등의 상태를 가지고 있지 않다면 딱히 문제는 없지만, 상태를 가진 객체라면 멀티스레딩에서 동시성 문제가 반드시 발생하게 된다. 이것 때문에 싱글턴 패턴의 가이드에서는 ..

- 필요 개념: 상속 - 활용도: 일반적으로 유용 - 난이도: 쉬움 - 패턴이 필요한 상황: 객체를 생성해야하는 모든 상황 1. 정적 팩토리 메서드 이건 우리가 평소에 자주 쓰는 팩토리 패턴이다. 굉장히 보편적으로 사용되며 상속을 지원하는 클래스의 경우 자식 클래스도 반환해주기도 한다. public class UserFactory{ public static User create(String type){ if(type.equals("adult"){ return new AdultUser(...); } else { return new YoungUser(...); } } } 2. 팩토리 메서드 패턴 위의 패턴에서 상속이 복잡해서 if else를 이용한 분기처리가 많아진다면 여기로 와야 한다. 어느 도메인에서나 ..

- 필요 개념: 상속, 컴포지션 둘 다 - 활용도: 가끔 쓸모있을 수준 - 난이도: 관점에 따라서는 다소 복잡함 - 패턴이 필요한 상황: 메서드에 다양한 기능(적어도 세네가지 이상)을 추가하고 싶을 때 데코레이터 패턴은 개념은 쉬운데 구현이 좀 복잡하다. 처음에는 이게 뭔 소린가하면서 넘어갔는데, 두세번 정도 읽다보니 깨달음이 온 패턴이다. 일단 세부 구현 방법보다는 그 쓸모가 어디에 있을지를 알아보자. 헤드퍼스트에서는 커피에 올리는 토핑으로 설명을 한다. 여러 개의 토핑을 다양한 조합으로 올렸을 때 가격을 어떻게 계산할 것이냐? 라는 가벼운 예시를 든다. 아 그런데 역시나 패턴을 이해하는 데에는 도움이 되지만 실질적으로 어디에 쓸거냐에 대한 인사이트는 그닥.. 데코레이터 패턴은 패턴 이름 그대로 꾸며주..