728x90
- 디자인패턴이란
- 프로그램을 설계할 때 발생했던 문제점들을 객체 간의 상호 관계 등을 이용하여 해결할 수 있도록 하나의 '규약' 형태로 만들어 놓은 것
- 싱글톤 패턴
- 하나의 클래스가 오직 하나의 인스턴스만 가지는 패턴
- 하나의 인스턴스를 다른 모듈들이 공유하기 때문에 인스턴스 생성 비용이 줄어듦
- 하지만, 의존성이 높아짐
- 단위테스트 시 테스트가 서로 독립적이어야 하지만 하나의 인스턴스를 공유하는 싱글톤 패턴의 경우 '독릭접인' 인스턴스 생성이 어려움
- 팩토리 패턴
- 객체를 사용하는 코드에서 객체 생성 부분을 떼어내 추상화한 패턴
- 상속 계에 있는 두 클래스에서 상위 클래스가 중요한 뼈대를 결정하고, 하위 클래스에서 객체 생성에 관한 구체적인 내용을 결정하는 패턴
- 전략 패턴(정책 패턴)
- 객체의 행위를 바꾸고 싶은 경우 '직접' 수정하지 않고 전략이라고 부르는 '캡슐화한 알고리즘'을 컨텍스트 안에서 바꿔주면서 상호 교체가 가능하게 만드는 패턴
- 옵저버 패턴
- 주체가 어떤 객체의 상태 변화를 관찰하다가 상태 변화가 있을 때마다 메서드 등을 통해 옵저버 목록에 있는 옵저버들에게 변화를 알려주는 디자인 패턴
- 주체
- 객체의 상태 변화를 보고 있는 관찰자
- 옵저버
- 객체의 상태 변화에 따라 전달되는 메서드 등을 기반으로 '추가 변화 사항'이 생기는 객체
- 프록시 패턴
- 대상 객체에 접근하기 전 그 접근에 대한 흐름을 가로체 대상 객체 앞단의 인터페이스 역할을 하는 디자인 패턴
- 프록시 서버
- 서버와 클라이언트 사이에서 클라이언트가 자신을 통해 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해주는 컴퓨터 시스템 또는 응용 프로그램
- 이터레이터 패턴
- 이터레이터를 사용하여 컬렉션의 요소들에 접근하는 디자인 패턴
- 노출모듈 패턴
- 즉시 실행 함수를 통해 private, public 같은 접근 제어자를 만드는 패턴
- MVC 패턴
- Model-View-Controller 로 이루어진 디자인 패턴
- 모델
- 어플리케이션의 데이터인 데이터베이스, 상수, 변수 등을 뜻함
- 뷰에서 데이터를 생성하거나 수정하면 컨트롤러를 통해 모델을 생성하거나 갱신함
- 뷰
- 사용자 인터페이스 요소, 모델을 기반으로 사용자가 볼 수 있는 화면
- 화면에 표시하는 정보만 가지고 있어야 함
- 변경이 일어나면 컨트롤러에 정보 전달해야 함
- 컨트롤러
- 하나 이상의 모델과 하나 이상의 뷰를 잇는 다리 역할을 하며 이벤트 등 메인로직을 담당
- 모델과 뷰의 생명주기 관리
- MVP 패턴
- MVC 패턴으로부터 파생된 패턴으로 Model-View-Presenter 로 이루어진 디자인 패턴
- 뷰와 프레젠터는 일대일 관계이기에 MVC 패턴보다 더 강한 결합을 지닌 디자인 패턴
- MVVM 패턴
- MVC의 C에 해당하는 컨트롤러가 View Model로 바뀐 패턴
- 뷰모델은 뷰를 더 추상화한 계층
- 프로그래밍 패러다임
- 프로그래밍의 관점을 갖게 해주는 역할을 하는 개발 방법론
- 크게 선언형, 명령형으로 나뉘어짐
- 선언형은 함수형이라는 하위 집합을 가지며 명령형은 객체지향, 절차지향으로 나뉘어짐
- 선언형 프로그래밍
- '무엇을' 풀어내는가에 집중하는 패러다임이며, "프로그램은 함수로 이루어진 것이다."라는 명제가 담겨있는 패러다임
- 함수형 프로그래밍
- 선언형 패러다임의 일종
- '순수함수'들을 블록처럼 쌓아 로직을 구현하고 '고차 함수'를 통해 재사용성을 높인 프로그래밍 패러다임
- 순수함수
- 출력이 입력에만 의존하는 것을 의미
- 입력외의 전역 변수 등이 출력에 영향을 주면 순수 함수가 아님
- 고차 함수
- 함수가 함수를 값처럼 매개변수로 받아 로직을 생성할 수 있는 것
- 사용하기 위해선 언어가 일급 객체라는 특징을 가져야 함
- 변수나 메서드에 함수를 할당할 수 있습니다.
- 함수 안에 함수를 매개변수로 담을 수 있습니다.
- 함수가 함수를 반활할 수 있습니다.
- 객체지향 프로그래밍
- 객체들의 집합으로 프로그램의 상호 자굥ㅇ을 표현하며 데이터를 객체로 취급하여 객체 내부에 선언된 메서드를 활용하는 방식
- 추상화
- 복잡한 시스템으로부터 핵심적인 개념 또는 기능을 간추려내는 것
- 캡술화
- 객체의 속성과 메서드를 하나로 묶고 일부를 외부에 감추어 은닉하는 것
- 상속성
- 상위 클래스의 특성을 하위 클래스가 이어받아서 재사용하거나 추가, 확장하는 것
- 다형성
- 하나의 메서드나 클래스가 다양한 방법으로 동작하는것
- 오버로딩, 오버라이딩 등
- SOLID
- Single Responsibility Principle (단일 책임 원칙)
- 모든 클래스는 각각 하나의 책임만 가져야 한다
- Open Closed Principle (개방-폐쇄 원칙)
- 유지 보수 사항이 생긴다면 코드를 쉽게 확장할 수 있도록 하고 수정할 때는 닫혀 있어야 한다.
- Liskov Substitution Principle (리스코프 치환 원칙)
- 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
- 부모객체 위치에 자식 객체를 넣어도 시스템이 정상적으로 돌아가게 만드는 것을 의미
- Interface Segregation Principle (인터페이스 분리 원칙)
- 하나의 일반적인 인터페이스보다 구체적인 여러 개의 인터페이스를 만들어야 한다.
- Dependency Inversion Principle (의존 역전 원칙)
- 자신보다 변하기 쉬운 것에 의존하던 것을 추상화된 인터페이스나 상위 클래스를 두어 변하기 쉬운 것의 변화에 영향을 받지 않게 한다.
- 상위 계층은 하위계층의 변화에 대한 구현으로부터 독립해야한다.
- Single Responsibility Principle (단일 책임 원칙)
- 절차형 프로그래밍
- 로직이 수행되어야 할 연속적인 계산 과정으로 이루어져 있음
- 일이 진행되는 방식으로 코드를 구현하기만 하면 되기 때문에 가독성이 좋으며 실행 속도가 빠름
- 모듈화하기가 어렵고 유지 보수성이 떨어짐
'독후감 > 면접을 위한 CS 전공지식 노트' 카테고리의 다른 글
면접을 위한 CS 전공지식 노트 (5) - 자료 구조 (0) | 2025.05.28 |
---|---|
면접을 위한 CS 전공지식 노트 (4) - 데이터베이스 (0) | 2025.05.13 |
면접을 위한 CS 전공지식 노트 (3) - 운영체제 (1) | 2025.05.09 |
면접을 위한 CS 전공지식 노트 (2) - 네트워크 (0) | 2025.05.09 |