1. 디자인 패턴
- 디자인 패턴 : 객체 간의 상호 관계에 대한 규약
1) 싱글톤 패턴
- 하나의 클래스에 하나의 인스턴스만 가지는 패턴
- 장점 : 인스턴스 생성 비용이 줄어듦
- 단점 : 의존성은 높아지고 독립적인 테스트가 어려워짐
※ 의존 : 다른 오브젝트의 변경 사항에 대해 다른 오브젝트도 같이 변하는 경우
※ 의존성 주입(DI) : 추상화 계층을 통해 모듈을 쉽게 교체할 수 있도록 만드는 것
- DB 연결 모듈에 많이 사용됨
2) 팩토리 패턴
- 객체를 생성하는 부분을 분리하여 추상화하는 패턴
- 하위 클래스에서 객체 생성 방법을 결정함
3) 전략 패턴
- 전략이라고 부르는 알고리즘을 추상화한 패턴
4) 옵저버 패턴
- 특정 객체에 상태 변화가 생길 때마다 옵저버들에게 변화를 알려주는 패턴
- 옵저버는 특정 객체의 상태 변화에 따라 전달되는 정보를 기반으로 추가 변화 사항이 생기는 객체다. 즉, 특정 객체의 변화에 영향을 받는 객체라고 보면 된다.
- 옵저버 패턴을 사용한 예로는 트위터가 있다. 포스팅을 올리게 되면 자신을 팔로우한 팔로워들에게 알림이 가는 방식이다.
- 프록시 객체를 통해 객체의 속성이나 메소드 변화를 감지함으로써 옵저버 패턴을 구현할 수도 있다.
5) 데코레이터 패턴
- 타깃의 코드와 호출 방법의 변동 없이 부가적인 기능을 추가하는 패턴
- 클라이언트와 타깃의 사이에 데코레이터 역할을 하는 인터페이스들을 두고, 각 인터페이스에 구현체를 조립하는 방식으로 사용한다.
6) 프록시 패턴
- 프록시란 어떠한 대상의 작업을 가로채서 부가적인 작업을 추가로 수행하는 객체로, 프록시 패턴은 프록시를 사용하는 패턴이다.
프록시 서버
- 클라이언트가 네트워크 서비스에 간접적으로 접속할 수 있게 해주는 서버로, 네트워크 서비스의 앞단에서 보안, 검증, 캐싱, 로깅 등의 역할을 한다.
- CORS 에러를 해결할 때도 사용된다. 프론트엔드 서버 대신에 프록시 서버가 다른 백엔드 서버와 통신해주는 것이다.
- 대표적으로 nginx, CloudFlare가 있다.
7) 이터레이터 패턴
- 이터레이터라는 하나의 인터페이스로 컬렉션의 요소을 순회하는 패턴이다.
8) 노출모듈 패턴
- 함수를 정의하자마자 바로 호출하는 즉시 실행 함수를 이용해서 접근 제어자를 구현하는 패턴
9) 빌더 패턴
- 객체를 생성하는 클래스와 표현하는 클래스를 분리하는 패턴
- 필요한 데이터만 설정할 수 있고 유연성과 가독성을 높일 수 있다.
10) MVC 패턴
- Model, View, Controller로 이루어진 패턴
- Model은 비즈니스 로직을 처리하는 곳으로 주로 DB에 해당된다. View는 사용자가 보는 화면에 해당된다. Controller은 하나 이상의 Model과 하나 이상의 View를 이어준다.
- MVP 패턴 : Controller가 Presenter로 교체된 패턴으로, View와 Presenter은 일대일 관계다.
- MVVM 패턴 : Controller가 View Model로 교체된 패턴으로, UI로부터 비즈니스 로직과 프레젠테이션 로직을 분리한다. View와 View Model 사이의 양방향 데이터 바인딩을 제공한다.
2. 프로그래밍 체계
1) 선언형(함수형 프로그래밍)
- 프로그램을 함수들의 집합으로 보는 것
- 함수가 일급 객체인 언어에서 사용할 수 있다.
※ 일급 객체 : 변수, 메서드에 할당될 수 있으며 함수에 의해 반환될 수 있는 객체
2) 명령형
(1) 객체지향 프로그래밍
- 프로그램을 상호 작용하는 객체들의 집합으로 보는 것
- 설계가 어렵고 처리 속도가 느리지만 확장성이 좋다.
- 추상화, 캡슐화, 상속성, 다형성이 특징이다.
- 추상화 : 핵심 개념 또는 기능을 간추려내는 것
- 캡슐화 : 객체의 속성과 메소드를 하나로 묶고 일부를 은닉하는 것
- 상속성 : 하위 클래스가 상위 클래스의 정보를 이어받아 재사용하는 것
- 다형성 : 하나의 메소드나 클래스가 다양한 방법으로 동작하는 것
- 오버로딩과 오버라이딩이 가능하다. 오버로딩은 같은 이름을 가진 메서드를 여러 개 두는 것이고, 오버라이딩은 상위 클래스로부터 상속받은 메소드를 재정의하는 것이다.
- SOILD 원칙을 지켜줘야 한다.
- S(Single Responsibility Principle, 단일 책임 원칙) : 모든 클래스는 각각 하나의 책임을 가져야 함
- O(Open Closed Principle, 개방 폐쇄 원칙) : 확장에는 개방되어야 하고, 수정에는 폐쇄되어야 함
- L(Liskov Substitution Principle, 리스코프 치환 원칙) : 객체는 문제 없이 하위 타입의 인스턴스로 형변환이 가능해야 함
- I(Interface Segregation Principle, 인터페이스 분리 원칙) : 인터페이스는 책임에 따라 분리되는 것이 낫다
- D(Dependency Inversion Principle, 의존 역전 원칙) : 구체화에 의존하지 않고 추상화에 의존해야 한다.
(2) 절차지향 프로그래밍
- 프로그램을 연속적인 계산 과정으로 보는 것
- 실행 속도는 빠르지만 유지보수성이 떨어짐
'IT 상식 > CS' 카테고리의 다른 글
[CS] 자료구조 요약 (0) | 2022.11.26 |
---|---|
[CS] 데이터베이스 요약 (0) | 2022.11.20 |
[CS] 운영체제 요약 (0) | 2022.11.10 |
[CS] 네트워크 요약 (0) | 2022.11.06 |
[CS] 면접 기타 예상 질문 (0) | 2021.06.11 |
댓글