Easy Understanding

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

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

옵저버 패턴을 들어가면서 스타크래프트의 옵저버나 언급해야겠다고 생각했는데, 다들 하는 생각이 비슷비슷한 것 같다. 이미 많이들 사용하고 있어서 생각을 접었다. 게다가 난 이 패턴에 옵저버라는 단어가 들어간 순간부터 이해에 방해가 되어 왔다. 대충 개념만 보면 쉬운데 이 옵저버라는 단어 때문에 더 헷갈리는 느낌이다. - 필요 개념: 상속 - 활용도: 부담없이 사용해볼만 함 - 난이도: 간단 - 패턴이 필요한 상황: 일대다 상황 일대다 상황이라 함은, 1개의 원인과 그로 인해 n개의 동작이 수행되어야 하는 상황이다. 예를 들면 다음과 같은 상황이다. - 모니터링 시스템에서 특정 지표가 넘어가면(1) 메시지/메일/카톡 등의 채널로 알림이 발송(n)된다. - 어떤 API를 통해서 요청이 들어왔을 때(1), 동시..

앞으로 패턴들에 대해서 어떻게 백엔드의 관점에서 사용할 것이며, 얼마나 유용할지 평가를 해보려고 한다. 애초에 패턴들을 실용적인 관점에서 검토하지 않으면 의미가 없다는 생각이다. 이 공부가 나의 실무 코드에 도움이 되어야하니 그런 점들을 위해서 정리해두려고 한다. 그러나 딱 내 학습 수준에 맞는 평가가 나올 것 같아서 그 점은 참고해야 한다. 추가로 디자인 패턴의 개념에 대한 기초 설명은 패스하려고 한다. 전략 패턴 - 필요 개념: 컴포지션 - 활용도: 부담없이 사용해볼만 함 - 난이도: 간단 - 패턴이 필요한 상황: 상속 상황에서 내부 코드의 빈번한 중복 보통 이 패턴에 가장 많이 나오는 예제는 Duck에 대한 예제이다. quack, fly 메서드가 나오고 여러 오리종류가 나오는 그 예제다. 헤드퍼스트..

헤드퍼스트 디자인 패턴에서는 다음과 같은 13가지 패턴을 다루고 있다. 1. 전략 패턴 2. 옵저버 패턴 3. 데코레이터 패턴 4. 팩토리 패턴(팩토리 메서드, 추상 팩토리) 5. 싱글턴 패턴 6. 커맨드 패턴 7. 어댑터 패턴 8. 파사드 패턴 9. 템플릿 메서드 패턴 10. 반복자 패턴 11. 컴포지트 패턴 12. 상태 패턴 13. 프록시 패턴 디자인 패턴은 이외에도 다양하며, 다음의 링크에서 대부분의 패턴들을 확인할 수가 있다. 해당 링크가 가장 잘 정리되어 있는 것 같아서 종종 참고하고는 한다. https://refactoring.guru/design-patterns/catalog The Catalog of Design Patterns refactoring.guru 디자인 패턴은 크게 다음과 같이..

디자인패턴에는 유명한 책이 몇개 되지 않는데, 그나마 그 중에 유명한 책이 이 헤드퍼스트 디자인패턴이라는 책이다. 원래 이 책은 2005년에 발매되었었고 이런 표지였다. 괜찮다고 들리는 책이 그나마 이 책과 'GoF의 디자인 패턴' 책인데, 다 너무 오래되어서 보기가 힘들긴 했다. 하지만 최근에 이 책이 개정되어서 바로 구매해서 읽어보았다. 개정판이 나오는 책이라는 것 자체가 좋은 소장가치를 가질거라고 판단해서 고민없이 사버렸다. 이 책에서 강조하는 게 '재치 넘치는 설명'과 '틀에 박히지 않은 구성' 인데 전적으로 인정한다. 무슨 이런 책이 있나 싶을 정도로 구성이 독특하다. 굳이 닮은 것을 따지자면 초등학교 저학년 교과서를 보는 느낌이다. 책이 너무 착하고 친절하다. 내가 생각하는 책이란 친절해야한다..

원래 회고를 할 생각이 없었지만 주말에 스터디를 위해 까페에 오면서 갑자기 이런 생각이 들었다. '지금 내 3개월이 과연 나중에 연말이 되어서는 기억이나 날까?' 기억이 날때 최대한 기록을 남겨놔야겠다는 생각이 들어 분기별로 한 번은 작성하는게 어떨까하여 블로그를 켰다. 제목을 정하면서 드디어 나도 '주니어' 개발자라는 타이틀을 붙일 수 있다는 데에서 살짝 감동했다. 개발자로서 제대로 직업을 가진 적이 없었으니, 취준생으로서의 나를 주니어라고 부르기는 사실 쉽지 않았다. 그런데 지금은 저렇게 당당하게 붙일 수 있다는 것 자체가 뭐 감격스럽고 그렇다. 신입 프로젝트 신입 교육은 12월 ~ 1월 첫주까지 진행했고 사내 블로그에도 잘 정리되어 있어서 링크를 걸어둔다. (https://kakaoentertain..

DDD 학습을 하다보면 전략적 패턴(도메인을 도출하고 정의하는 과정)에는 어느 정도 일관된 결론이 있는 것을 확인할 수 있다. 각종 DDD 책이나 블로그 들에서 해당 과정은 타협할 수 없는 과정으로 여겨지고 있고, 실제로 어떤 문서를 읽어도 내용들이 크게 다르지는 않다. 하지만 전술적 패턴(실제로 코드를 작성하고 아키텍처를 결정하는 과정)에 대해서는 딱히 일관성이 없다. 왜냐하면 DDD에서는 코드를 작성하는 방법에 대해서 정답이 없다고 애초에 선언되었기 때문이다. 실제 DDD 예제 코드들을 깃헙에서 확인해보니, 정말 제각각의 다양한 형식의 코드 스타일들이 존재했다. 반 버논의 iDDD 책에서 제공하는 DDD에 대한 방법론은 많은 인사이트를 제공해주었지만, 실제로 고민해보고 코딩해보는 과정이 필요하다고 생..