객체지향 프로그래밍 Object Oriented Programming
- 현실 세계를 프로그래밍으로 옮겨와 프로그래밍하는 것 : 추상화
- 재사용성 높다 = 신뢰성 확보
- 비용절감
- 유지보수 용이
- 모델링 과정에서 매핑을 통해 요구사항을 명확하게 파악
설계원칙
1. SRP Single Responsibility Principle
단일 책임 원칙
클래스는 단 하난의 책임을 가져야 하며 클래스를 변경하는 이유는 단 하나의 이유여야한다.2. OCP Open-Closed Principle
개방-폐쇄 원칙
확장에는 열려있어야하고 변경에는 닫혀있어야한다3. LSP Liskov Substitution Principle
리스코프 치환 원칙
상위 타입의 객체를 하위 타입의 객체로 치환해도 상위 타입을 사용하는 프로그램은 정상적으로 동작해야된다.4. ISP Interface Segregation Principle
인터페이스 분리 원칙
인터페이스는 그 인터페이스를 사용하느 클라이언트를 기준으로 분리해야 한다5. DIP Dependency Inversion Principle
의존 역전 원칙
고수준 모듈을 저수준 모듈의 구현에 의존해서는 안된다.
RESTful API
REST의 기본 원칙을 성실히 지킨 서비스 디자인 = RESTful 하다
REST
REpresentational State Transfer
디자인 패턴
API 설계의 중심에 자원이 있고 HTTP Method을 통해 자원을 처리하도록 설계
REST 6가지 원칙
- Uniform Interface
- Stateless
- Caching
- Client-Server
- Hierarchical System
RESTful하게 API를 디자인 한다는 것
1. 리소스와 행위를 명시적이고 직관적으로 분리
- 리소스는 URI로 표현되는데 리소스가 가르키는 것을 명사로 표현해야한다.
- 행위는 HTTP Method로 표현
- GET/POST/PUT/PATCH/DELETE을 분명한 목적으로 사용
2. Message는 Header와 Body를 명확하게 분리해서 사용
- Entity에 대한 내용은 body에 담는다
- 애플리케이션 서버가 행동할 판단의 근거가 되는 컨트롤 정보인 PAI 버전 정보, 응답받고자하는 MIME 타입 등은 Header에 담는다
- header와 body는 http header 와 http body로 나눌 수도 있고, http body에 들어가는 json 구조로 분리할 수도 있다.
3. API 버전을 관리
- 환겨은 항상 변하기 때문에 PAI의 signature가 변경될 수도 있음에 유의하자
- 특정 API를 변경할 때는 반드시 하위호환성을 보장해야한다.
4. 서버와 클라이언트가 같은 방식을 사용해서 요청
- 브라우저는 form-data 형식의 submit으로 보내고 서버는 json형태로 보내는 시그이 분리보다는 json으로 보낸든, 둘다 form-data 형식으로 보내는 통일해야한다.
- URI가 플랫폼 중립적이어야 한다.
RESTful 장점
- open API 제공이 쉽다
- 멀티플래폼 지원 및 연동이 용이하다
- 원하는 타입으로 데이터를 주고 받을 수 있다
- 기존 웹 인프라(HTTP)를 그대로 사용할 수 있다.
RESTful 단점
- 사용할 수 있는 메소드가 4가지 밖에없다
- 분산환경에는 부적합하다
- HTTP 통신 모델에 대해서만 지원한다.
TDD
TDD란
- Test Driven Development는 매우 짧은 개발 사이클의 반복에 의존하는 소프트웨어 개발 프로세스이다
- 테스트가 코드작성을 주도하는 개발방식 : 요구되는 새로운 기능에 대한 자동화된 테스트케이스를 작서앟고 해당 테스트를 통과하는 가장 간단한 코드를 작성
1. Add a test
새로운 기능을 추가하기 전 테스트를 먼저 작성한다.2. Run all tests and see if new one fails
새로운 기능을 추가하고 기존의 코드가 잘 동작하는지 확인하는 테스트 코드를 작성3.Refector code
메소드 명, 변수명, 클래스명 : 일관적
확장성 고려
함수형 프로그래밍
특징
1. immutable data
2. first class citizen으로서의 function
immutable vs mutable
immutable
- 변경 불가능함
- 값이 변경될 경우, 새로운 객체를 생성하고 변경된 값을 주입하여 반환
mutable
- 해당 객체의 값이 변경될 경우 값을 변경
first-citizen
함수는 first class citizen(일급객체)로 간주
- 변수나 데이터 구조안에 함수를 담을 수 잇어 함수의 파라미터로 전달할 수 있고, 함수의 반환값으로 사용
- 할당에 사용된 이름과 관계없이 고우한 구별이 가능
- 함수를 리피럴로 바로 정의
Reactive Programmin : 반응형 프로그래밍
= declarative programming : 선언형 프로그래밍
!= imperative programming : 명령형 프로그래밍
- 함수형 프로그래밍 패러다임을 활용하는 것
- 기본적으로 모든 것을 스트림으로 본다
- 스트림이란 값들의 집합으로 볼 수 있으며 제공되는 함수형 메소드를 통해 데이터를 immutable하게 관리한다.
MVC 패턴
- 구성요소 : model, view, control
- 안드로이드와 관계없이 프로그래밍 시 가장 널리 사용되는 구조
- 입력은 모든 control에서 발생하게 되며 관리하게 하는 구조
Model
- 데이터를 가지며 애플리케이션에서 사용되는 데이터와 그 데이터를 처리함
- view 또는 control에 묶이지 않아 재사용가능
View
- 사용자에게 보일 화면을 표현
- 앱 및 UI와의 상호작용에서 컨트롤러와 통신함
Control
-사용자로부터 입력을 받고 이 입력을 모델에 의해 view 정의를 하게됨
- 모델의 데이터 변화에 따라 뷰를 선택
장점
- model과 view의 분리
- model의 비종속성으로 재사용가능
- 구현하기 가장 쉽고 단순함
- 유닛캐스트에서 view는 테스트 할 부분이 없기 때문에 쉽게 model만 테스트가능
- 개발자라면 누구나 쉽게 파악 가능
- 개발기간이 짧아짐 [ 안드로이드에서의 장점 ]
- 그냥 다른 것 생각할 것 없이 안드로이드 액티비티에서 모든 걸 동작하게 처리하면 된다.
단점
- model과 view 사이에 의존성 발생 [ 의존성을 없앨 수 없음 ]
- view의 ui 갱신을 위해 model을 직/간접적으로 참조하므로 앱 자체가 커지고 로직이 복잡해질수록 유지보수가 힘들어집니다,
- 스파게티 코드가 될 가능성이 높음
- 복붙이 많아져 코드분리 조차 되지 않으면 코드가 제대로 꼬인다. => 복잡도 증가
- 설계단계에서 보안가능
- 시간이 지날 수록 코드 비대화
- controllor가 안드로이드 API에 깊게 종속 => 유니캐스트가 어려움
