디자인 패턴 / 프로그래밍 패러다임

디자인 패턴

패턴명	설명	장점	단점
싱글톤 패턴	하나의 클래스에 오직 하나의 인스턴스만 가지는 패턴	하나의 인스턴스를 만들어놓고 인스턴스를 다른 모듈이 공유하며 사용 -> 인스턴스를 생성할 때 드는 비용 감소	메인 모듈이 직접 다른 하위 모듈에 대한 의전송을 주기보다는 중간에 의존성 주입자가 이 부분을 가로채 상위 모듈이 간접적으로 의존성을 주입하는 방식 -> 메인 모듈은 하위 모듈에 대한 의존성이 떨어지게 됨(디커플링이 된다)
팩토리 패턴	객체를 사용하는 코드에서 객체 생성 부분을 떼어내 추상화한 패턴 상위클래스 - 중요한 뼈대 결정 하위 클래스 - 객체 생성에 관한 구체적인 내용 결정
전략 패턴	객체의 행위를 바꾸고 싶은 경우 직접 수정하지 않고 전략이라고 부르는 캡슐화한 알고리즘을 컨텍스트 안에서 바꿔주면서 상호 교체가 가능하게 만드는 패턴
옵저버 패턴	주체가 어떤 객체(subject)의 상태 변화를 관찰하다가 상태 변화가 있을 때마다 메서드 등을 통해 옵저버 목록에 있는 옵저버들에게 변화를 알려주는 디자인 패턴 - 주체 : 객체의 상태 변화를 보고 있는 관찰자 - 옵저버 : 이 객체의 상태 변화에 따라 전달되는 메서드 등을 기반으로 추가 변화 사항이 생기는 개체들
프록시 패턴	대상 객체에 접근하기 전 그 접근에 대한 흐름을 가로채 해당 접 근을 필터링하거나 수정하는 등의 역할을 하는 계층이 있는 디자인 패턴
이터레이터 패턴	이터레이터를 사용하여 컬렉션 요소에 접근하는 디자인 패턴 -> 이터레이터라는 하나의 인터페이스로 순회 가능
노출모듈 패턴	즉시 실행 함수를 통해 public, private 같은 접근 제어자를 만드는 패턴
MVC 패턴	모델 : 애플리케이션의 데이터 (데이터베이스, 상수, 변수) 뷰 : 사용자 인터페이스 요소 (inputbox, checkbox) 컨트롤러 : 하나 이상의 모델과 하나 이상의 뷰를 잇는 다리역할. 이벤트 등 메인 로직 담당. 모델과 뷰의 생명주기 관리. 모델이나 뷰의 변경 통지를 받으면 이를 해석하여 각각의 구성 요소에 해당 내용에 대해 알려줌	개발 프로세스에서 각각의 구성 요소에만 집중해서 개발 할 수 있음. 재사용성과 확장성 용이	애플리케이션이 복잡해질수록 모델과 뷰의 관계가 복잡해짐.
MVP 패턴	MVC 패턴으로부터 파생. C -> P(presenter)로 교체 뷰와 프리젠터는 일대일 관계이기 때문에 MVC 패턴보다 더 강한 결합을 지닌 디자인 패턴
MVVM 패턴	MVC의 C -> 뷰모델(view model)로 바뀐 패턴 뷰모델은 뷰를 더 추상화한 계층. MVC와 다르게 커맨드와 데이터 바인딩을 가진다. 뷰와 뷰모델 사이의 양방향 데이터 바인딩을 지원하며 UI를 별도의 코드 수정 없이 재사용할 수 있고 단위 테스팅하기 쉽다.

 

* 의존성 주입(DI, Dependency Injection)

메인 모듈이 직접 다른 하위 모듈에 대한 의전송을 주기보다는 중간에 의존성 주입자가 이 부분을 가로채 메인 모듈이 간접적으로 의존성을 주입하는 방식 -> 메인 모듈은 하위 모듈에 대한 의존성이 떨어지게 됨(디커플링이 된다)

- 장점 :

모듈을 쉽게 교체할 수 있는 구조가 되어 테스트가 쉽고 마이그레이션도 수월함

- 원칙 :

상위 모듈은 하위 모듈에서 어떠한 것도 가져오지 않아야 한다.

 

* Enum

상수의 집합을 정의할 때 사용되는 타입

 

* 자바의 상속 / 구현

- 상속 : 자시 클래스가 부모 클래스의 메서드 등을 상속받아 사용. 자식 클래스에서 추가 및 확장을 할 수 있는 것을 말한다. 재사용성, 중복성의 초소화가 이루어짐 (abstract class 기반)

- 구현 : 부모 인터페이스를 자식 클래스에서 재정의하여 구현. 상속과 달리 반드시 부모 메서드를 재정의하여 구현해야 한다. (interface 기반)

 

* 프록시 서버

서버와 클라이언트 사이에서 클라이언트가 자신을 통해 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해주는 컴퓨터 시스템이나 응용프로그램

 

프로그래밍 패러다임

- 선언형 - 함수형

- 명령형 - 객체지향형 / 절차지향형

 

1. 선언형과 함수형 프로그래밍

선언형 프로그래밍

무엇을 풀어내는가에 집중하는 패러다임.

함수형 프로그래밍은 선언형 패러다임의 일종.

 

함수형 프로그래밍

작은 순수함수들을 블록처럼 쌓아 로직을 구현하고 고차함수를 통해 재사용성을 높인 프로그래밍 패러다임

 

* 순수함수

출력이 입력에만 의존하는 것을 의미

 

*고차함수

함수가 함수를 값처럼 매개변수로 받아 로직을 생성할 수 있는 것

- 일급객체 : 고차 함수를 쓰기 위해 해당 언어가 일급 객체라는 특징을 가져야 한다.

                   변수나 메서드에 함수를 할당 할 수 있다.

                   함수 안에 함수를 매개변수로 담을 수 있다.

                   함수가 함수를 반환할 수 있다.

 

2. 객체지향 프로그래밍

객체들의 집합으로 프로그램의 상호 작용을 표현

데이터를 객체로 취급하여 객체 내부에 선언된 메서드를 활용하는 방식

설계에 많은 시간이 소요되며 처리 속도가 다른 프로그래밍 패러다임에 비해 상대적으로 느리다.

 

객체지향 프로그래밍의 특징

추상화	복잡한 시스템으로부터 핵심적인 개념 또는 기능을 간추려내는 것
캡슐화	객체의 속성과 메서드를 하나로 묶고 일부를 외부에 감추어 은닉하는 것
상속성	상위 클래스의 특성을 하위 클래스가 이어받아서 재사용하거나 추가, 확장하는 것
다형성	하나의 메서드나 클래스가 다양한 방법으로 동작하는 것 (오버로딩, 오버라이딩)

 

* 오버로딩

같은 이름을 가진 메서드를 여러 개 두는 것. 메서드의 타입, 매개변수 유형, 개수 등으로 여러 개를 둘 수 있다.

 

* 오버라이딩

상위 클래스로부터 상속받은 메서드를 하위 클래스가 재정의 하는 것

 

객체지향 프로그래밍 설계 원칙 - SOLID

단일 책임 원칙 (Single Responsibility Principle)	모든 클래스는 각각 하나의 책임만 가져야 하는 원칙
개방-폐쇄 원칙 (Open Closed Principle)	유지 보수 사항이 생긴다면 코드를 쉽게 확장할 수 있도록 하고 수정할 때는 닫혀 있어야 한다는 원칙 기존의 코드는 잘 변경하지 않으면서 확장은 쉽게 할 수 있어야 한다.
리스코프 치환 원칙 (Liskov Substitution Principle)	프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 하는 것을 의미 클래스는 상속이 되고, 이때 부모 객체에 자식 객체를 넣어도 시스템이 문제없이 돌아가게 만드는 것을 말한다.
인터페이스 분리 원칙 (Interface Segregation Principle)	하나의 일반적인 인터페이스보다 구체적인 여러 개의 인터페이스를 만들어야 하는 원칙
의존 역전 원칙 (Dependency Inversion Principle)	자신보다 변하기 쉬운 것에 의존하던 것을 추상화된 인터페이스나 상위 클래스를 두어 변하기 쉬운 것의 변화에 영향받지 않게 하는 원칙 상위  계층은 하위 계층의 변화에 대한 구현으로부터 독립해야 한다.

 

3. 절차형 프로그래밍

로직이 수행되어야 할 연속적인 계산 과정으로 이루어져 있다.

일이 진행되는 방식으로 그저 코드를 구현하기만 하면 되기 때문에 코드의 가독성이 좋으며 실행 속도가 빠르다.