[CS 전공지식 노트] 1장. 디자인패턴과 프로그래밍 패러다임

스터디 메인 페이지

 

  이 스터디의 경우 이미 책의 내용이 매우 축약된 내용이므로 책 내용 정리는 크게 의미가 없다고 생각합니다. 따라서 스터디 정리는 추가로 설명한 부분에 대해 작성했습니다.

 

- 16 page (디자인 패턴 설명 시작하는 부분)

  디자인패턴, 패러다임 모두 일종의 도구로 여러 사람의 공통된 문제 해결 방법을 정형화해둔 것. 정답이 없고 적절히 선택해 사용하면 된다.

 

- 17 page (싱글톤 패턴 설명 시작하는 부분)

  "하나의 클래스에 오직 하나의 인스턴스만"이 애매할 수 있는데, 싱글톤 패턴을 적용한 자바 Class에 대해 new를 통한 인스터스화(=객체)가 프로그램 내에서 단 한 번만 일어난다고 이해하면 된다.

 

- 20 page (싱글톤 패턴을 구현한 자바 코드)

  자바 싱글톤 패턴의 변화 (다양한 싱글톤 패턴 구현 방법) 글을 스터디 중 설명했다. 또 설명한 내용을 바탕으로 보면 이 책의  코드는 틀렸다. private 생성자가 없으므로 다른 곳에서 new를 통해 객체 생성이 가능하다. 또한 위 글에서 설명한 '6'의 방법으로 구현된 코드인데, 굳이 synchronized를 넣어 성능만 저하됬다.

 

  스프링의 경우 IoC 컨테이너에서 @Autowired를 통해 객체를 받아올 때 기본적으로 싱글톤으로 볼 수 있다. 그래서 상태를 코드에 넣지 말라는 것이고, 그에 대한 예시를 설명했다. 이하처럼 구현할 경우 두 컨트롤러에 SingletonTest를 주입했다. 이 때 SingletonTest의 num 변수가 static이 아님에도 컨트롤러1에서 수정한 값이 컨트롤러2에도 반영됨을 볼 수 있다. 또한 둘의 주소값을 찍어보면 동일함을 알 수 있다. (각 컨트롤러에 @Autowired가 없는데, 생성자에서 주입하는 방식을 사용한 것이다. @Autowired를 통한 주입은 스프링부트에서 추천되는 방식이 아니다.)

  이걸 새로 생성되게 하려면 SingletonTest 클래스에 @Scope("prototype")을 넣어주면 되긴한데, 보통은 프로토타입으로 변경해야만 하는 상황이라면 설계적으로 뭔가 문제가 있는 경우로 생각된다. 또한 싱글톤은 TDD 시 걸림돌이 된다고 하지만, 스프링은 DI(의존성 주입)을 통해 결합도를 낮춰서 가능하다.

 

- 29 page (전략 패턴 설명 시작되는 부분)

  팩토리 패턴과 전략 패턴이 얼핏 비슷하게 생각될 수 있는데, 팩토리 패턴은 객체 생성에 관여하는 것이고, 전략 패턴은 프로세스 진행에 관여한다.

 

  예를들어 다양한 디바이스들에서 "1001A123123" 와 같은 방식으로 String 형태의 데이터가 들어오고, 이걸 TCP, UDP, REST API 등 다양한 방식을 통해 처리해야 하는 경우가 있다고 해보자. 중간의 대문자가 장치의 종류에 해당한다. 이 경우 처리하는 로직은 'run()' 이라는 함수 하나로 둔 부모 클래스를 만들고, 그 하위에서 상속 혹은 구현을 통해 run() 함수를 TCP, UDP, REST API 등으로 처리하는 로직을 짠다. 데이터가 들어온 경우, 단순히 데이터를 팩토리 패턴을 적용한 팩토리로 보내 처리할 객체를 얻어오고, 각 객체는 전략 패턴을 통해 다양한 방식으로 처리할 수 있다.

 

- 34 page (옵저버 패턴 설명 시작되는 부분)

  옵저버 패턴에 대한 예시 : 안드로이드에서 문자가 올 경우, 카드값 등의 정보라면 가계부를 자동으로 생성해주는 어플이 있다. 이런식으로 문자가 왔을 때 처리해주는 여러 어플들이 존재하는데, 얘네가 전부 백그라운드에 돌고 있으면서 문자가 오는지 감시하는건 매우 비효율적이다. 따라서 안드로이드 시스템에 문자가 왔을 경우 알려달라는 event listener를 옵저버로 등록해두고, 이 책에서 설명하는 주체에 해당하는 안드로이드 시스템이 문자가 올 경우 해당 옵저버들에게 알려준다. 각 옵저버들은 바로 깨어날 수 없으니, 리스너에 해당하는 프록시만 돌면서 자신과 관련된 문자인지 확인하고 관련된 문자라면 추가로 처리하게 된다.

 

- 44 page (프록시 패턴)

  유투브 썸네일 영상을 예시로 들었다. 일반적으로 책에 설명된 프록시 객체 앞 뒤의 인터페이스가 동일할 경우 프록시 패턴이라 하고, 다를 경우 파사드 패턴이라고 한다. 다만 이런식으로 세세하게 나눠진 디자인 패턴들이 많은데 굳이 다 구분할 필요는 없다. 디자인 패턴은 여러 개발자들이 공통적으로 문제를 해결한 방법을 어느정도 정형화해둔 것으로 큰 틀만 알고 아이디어를 얻어 적용시키면 된다고 생각한다.

 

- 45 page (nginx)

   Forward Proxy : 사용자 -> 포워드 프록시 -> 인터넷. 인터넷으로 나갈 때

Reverse Proxy : 인터넷(사용자) -> 리버스 프록시 -> 내부서버. 내부 서버로 들어올 때

 

- 48 page (CORS)

  SOP(Same origin policy) : 동일한 오리진 끼리만 데이터를 송수신할 수 있다. 프론트에서 자체적으로 해결 가능한 경우도 있지만, 일반적으로 서버에서 화이트리스트로 관리해주는 것이 맞다. CrossOrigin 어노테이션 혹은 WebMvcConfigurer를 implements해서 addCorsMappings의 registry.allowedOrigins()에 화이트 리스트를 추가할 수 있다.