[스터디3] 디자인 패턴 - 09. 디자인 패턴과 프로그래밍 패러다임

목차

 

 

5장까지 끝냈으니, 1장 디자인 패턴 부분을 학습하면서 이 책을 마무리하려고 합니다.

1장 디자인 패턴과 프로그래밍 패러다임

• 라이브러리: 공통으로 사용될 수 있는 특정한 기능들을 모듈화한 것. 파일명 등에 대한 규칙이 없음.
• 프레임워크: 공통으로 사용될 수 있는 특정한 기능들을 모듈화한 것. 폴더명, 파일명 등에 대한 규칙이 있음.

1.1 디자인 패턴

• 디자인 패턴: 프로그램을 설계할 때 발생했던 문제점들을 객체 간의 상호 관계 등을 이용하며 해결할 수 있도록 하나의 규약 형태로 만들어 놓은 것

1.1.1 싱글톤 패턴

• 싱글톤 패턴(singleton pattern): 하나의 클래스에 오직 하나의 인스턴스만 가지는 패턴

장점	인스턴스를 다른 모듈들이 공유하며 사용하기 때문에 인스턴스를 생성할 때 드는 비용이 줄어듦.
단점	의존성이 높아짐. 각 테스트마다 독립적인 인스턴스르 만들기 어려움.

1.1.2 팩토리 패턴

• 팩토리 패턴(factory pattern): 객체를 사용하는 코드에서 객체 생성 부분을 떼어내 추상화한 패턴. 상속 관계에 있는 두 클래스에서 상위 클래스가 중요한 뼈대를 결정하고, 하위 클래스에서 객체 생성에 관한 구체적인 내용을 결정함.

장점	상위 클래스에서 인스턴스 생성 방식에 대해 알 필요가 없기 때문에 유연성이 높음. 객체 생성 로직이 분리되어 있으므로 유지 보수성이 증가함.
단점	의존성이 높아짐. 설계가 복잡해질 수 있음.

• 상속(extends): 자식 클래스가 부모 클래스의 메서드 등을 상속받아 사용하며 자식 클래스에서 추가 및 확장을 할 수 있는 것. 일반 클래스, abstract 클래스를 기반으로 구현함.
• 구현(implements): 부모 인터페이스를 자식 클래스에서 재정의하여 구현하는 것. 인터페이스를 기반으로 구현함.

1.1.3 전략 패턴

• 전략 패턴(strategy pattern): 정적 패턴(policy pattern)이라고도 함. 객체의 행위를 바꾸고 싶은 경우 직접 수정하지 않고, 전략이라고 부르는 캡슐화한 알고리즘을 컨텍스트 안에서 바꿔주면서 상호 교체가 가능하게 만드는 패턴.
• 컨텍스트: 개발자가 어떠한 작업을 완료하는 데 필요한 모든 관련 정보 

1.1.4 옵저버 패턴

• 옵저버 패턴(observer pattern): 주체가 어떤 객체(subject)의 상태 변화를 관찰하다가 상태 변화가 있을 때마다 메서드 등을 통해 옵저버 목록에 있는 옵저버들에게 변화를 알려주는 패턴
• 주체는 관찰자이고, 옵저버들이란 객체의 상태 변화에 따라 변화가 생기는 객체들을 의미함.

1.1.5 프록시 패턴과 프록시 서버

• 프록시 패턴(proxy pattern): 대상 객체에 접근하기 전, 그 접근에 대한 흐름을 가로채 해당 접근을 필터링하거나 수정하는 등의 역할을 하는 계층이 있는 패턴
• 프록시 서버(proxy server): 서버와 클라이언트 사이에서 클라이언트가 자신을 통해 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해주는 컴퓨터 시스템이나 응용 프로그램. 예) nginx, CloudFlare
• CORS(Cross-Origin Resource Sharing): 서버가 웹 브라우저에서 리소스를 로드할 때 다른 오리진을 통해 로드하지 못하게 하는 HTTP 헤더 기반 메터니즘.

1.1.6 이터레이터 패턴

• 이터레이터 패턴(iterator pattern): 이터레이터를 사용하여 컬렉션의 요소들에 접근하는 패턴

1.1.7 노출모듈 패턴

• 노출모듈 패턴(revealing module pattern): 즉시 실행 함수를 통해 private, public 같은 접근 제어자를 만드는 패턴

1.1.8 MVC 패턴

• MVC 패턴: 모델(Model), 뷰(View), 컨트롤러(Controller)로 이루어진 패턴

장점	재사용성과 확장성이 용이함.
단점	애플리케이션이 복잡해질수록 모델과 뷰의 관계가 복잡해짐.

• 모델: 애플리케이션의 데이터인 데이터베이스, 상수, 변수 등
• 뷰: inputbox, checkbox, textarea 등 사용자 인터페이스 요소. 모델을 기반으로 사용자가 볼 수 있는 화면.
• 컨트롤러: 하나 이상의 모델과 하나 이상의 뷰를 잇는 다리 역할을 함. 이벤트 등 메인 로직을 담당함. 모델과 뷰의 생명주기를 관리함.

1.1.9 MVP 패턴

• MVP 패턴: MVC에서 C에 해당하는 컨트롤러가 프레젠터(presenter)로 교체된 패턴
• 뷰와 프레젠터는 일대일 관계임.

1.1.10 MVVM 패턴

• MVVM 패턴: MVC에서 C에 해당하는 컨트롤러가 뷰모델(view model)로 바뀐 패턴
• 뷰모델: 뷰를 더 추상화한 계층

1.2 프로그래밍 패러다임

• 프로그래밍 패러다임(programming paradigm): 프로그래머에게 프로그래밍의 관점을 갖게 해주는 역할을 하는 개발 방법론

1.2.1 선언형과 함수형 프로그래밍

• 선언형 프로그래밍(declarative programming): 무엇을 풀어내는가에 집중하는 패러다임. "프로그램은 함수로 이루어진 것이다"라는 명제가 담겨 있음.
• 함수형 프로그래밍(functional programming): 선언형 패러다임의 일종

1.2.2 객체지향 프로그래밍

• 객체지향 프로그래밍(OOP: Object0Oriented Programming): 객체들의 집합으로 프로그램의 상호작용을 표현하며 데이터를 객체로 취급하여 객체 내부에 선언된 메서드를 활용하는 방식
• 객체지향 프로그래밍의 특징
  • 추상화(abstraction): 복잡한 시스템으로부터 핵심적인 개념 또는 기능을 간추려내는 것
  • 캡슐화(encapsulation): 객체의 속성과 메서드를 하나로 묶고 일부를 외부에 감추어 은닉하는 것
  • 상속성(inheritance): 상위 클래스의 특성을 하위 클래스가 이어받아서 재사용하거나 추가, 확장하는 것
  • 다형성(polymorphism): 하나의 메서드나 클래스가 다양한 방법으로 동작하는 것. 예) 오버로딩(overriding), 오버라이딩(overloading)
• SOLID 원칙
  • 단일 책임 원칙(SRP: Single Responsibility Principle): 모든 클래스는 각각 하나의 책임만 가져야 하는 원칙
  • 개방-폐쇄 원칙(OCP: Open Closed Principle): 유지 보수 사항이 생긴다면 코드를 쉽게 확장할 수 있도록 하고 수정할 떄는 닫혀 있어야 하는 원칙
  • 리스코프 치환 원칙(LSP: Liskov Substitution Principle): 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 하는 것
  • 인터페이스 분리 원칙(ISP: Interface Segregation Principle): 하나의 일반적인 인터페이스보다 구체적인 여러 개의 인터페이스를 만들어야 하는 원칙
  • 의존 역전 원칙(DIP: Dependency Inversion Principle): 자신보다 변하기 쉬운 것에 의존하던 것을 추상화된 인터페이스나 상위 클래스를 두어 변하기 쉬운 것의 변화에 영향받지 않게 하는 원칙

1.2.3 절차형 프로그래밍

• 절차형 프로그래밍: 로직이 수행되어야 할 연속적인 계산 과정으로 이루어짐.

1.2.4 패러다임의 혼합

• 어떤 패러다임을 사용하는 것이 가장 좋은지 정답은 없음.

 

'면접을 위한 CS 전공지식 노트' 책 스터디는 이렇게 끝났습니다. 책에서는 생략된 내용을 찾아보기도 하면서 배웠던 내용을 복습할 수 있어 유익한 시간이었습니다.

 

이 글은 『 면접을 위한 CS 전공지식 노트 』 책을 학습한 내용을 정리한 것입니다.