프로그래밍공통/기타상식
Updated:
1. 객체지향 프로그래밍
OOP(Object Oriented Programming)
프로그래밍에서 필요한 데이터를 추상화시켜 상태와 행위를 가진 객체를 만들고 그 객체들 간의 유기적인 상호작용을 통해 로직을 구성하는 프로그래밍 방법
1.1 특징
- 캡슐화
- 데이터와 데이터를 처리하는 함수를 하나로 묶는것
- 정보은닉
- 캡슐화를 통해 접근제어
- 추상화
- 여러 객체의 공통적인 특징을 도출해내는 것
- 상속성
- 이미 정의된 상위클래스의 모든속성과 연산을 하위클래스가 물려 받는 것
- 다형성
- 변수 또는 함수가 상황에 따라 다른결과를 나타냄
1.2 장단점
장점
- 재사용이 용이하고 생산성이 높으며 유지보수가 쉽다.
단점
- 설계에 시간이 오래걸리고 실행속도가 느리다.
2.URI와 URL의 차이
URL(Uniform Resource Locator)
인터넷상 자원의 위치
URI(Uniform Resource Identifier)
인터넷상 자원을 식별하기 위한 문자열의 구성
URI는 URL을 포함하는 상위개념
3. RestFul API(Represemtational state transfer)
3.1 REST의 정의
자원을 이름으로 구분해 자원의 상태를 주고받는 모든것
어떤 자원에 대해 CRUD연산을 수행하기 위해 URI(Resource)로 GET,POST등의
방식을 사용하여 요청을 보내며, 요청을 위한자원은 특정한형태로 표현된다.
3.1.1 자원(Resource) - URI
- 모든자원에는 고유한 ID가 존재하며 server에 존재
- ID는
'./exgroups/:exgroup_id'와 같은 HTTP URI이다. - Client는 URI를 이용해 자원을 지정하고 해당자원의 상태에 대한 조작을 server에 요청
3.1.2 행위(Verb) - Method
HTTP 프로토콜 Method를 사용한다. HTTP프로토콜은 GET,PUT,PATCH,DELETE의 Method를 제공
| GET | Read |
| POST | Create |
| PUT | Update |
| PATCH | Update |
| DELETE | Delete |
3.1.3 표현(Reprsentation of Resource)
데이터를 주고받는 형태로 Json,XML,Text,Rss 등이 있다. 주로 Json과 XML를 사용
REST API의 특징
각 요청이 어떤동작이나 정보를 위한것인지 그 요청의 모습자체로 추론가능한것
REST API 디자인 가이드
- URI는 정보의 자원을 표현해야한다.
- 자원에 대한 행위는 HTTP Method로 표현한다. Method는 URI에 포함하지 않는다.
REST API 설계규칙
- URI는 명사를 사용(동사 사용X)
- 슬래시(/)로 계층관계 표현
- URI 마지막 문자로 슬래시(/) 사용X
- 밑줄(_)을 사용하지 않고 하이픈(-)사용
- URI는 소문자로만 구성한다.
- HTPP 응답 상태코드 사용
3.2 RESTFul API란?
REST의 설계규칙을 잘 지켜서 설계된 API
3.3 HTTP 상태코드
4. TDD(Test Driven Development)
작은 단위의 테스트케이스를 작성하고 그에 맞는 코드를 작성하여 테스트를 통과한 후에 상황에 맞게 리팩토링하는 개발 방식
4.1 레드 그린 사이클
Red : 어떠한 기능을 검증하는 테스트가 실패하는 코드를 작성하고, 실제로 실패하는지를 확인한다.
Green : 어떠한 기능을 검증하는 테스트가 통과하는 코드를 작성하고, 실제로 성공하는지 확인한다.
Refator : 성공과 실패 테스트를 모두 검증했다면, 작성한 코드를 깨끗하고 가독성있게 고친다.
4.2 테스트코드를 작성하는 이유
- 기능의 추가, 변경, 사제로 인한 영향을 쉽게 파악가능
- 예상하지 못한 오류에 대한 피드백을 위해서
- 좋은 설계로 작성되게끔 코드를 유도
- 기능정의 문서의 역할
- 실수를 줄여준다.
5. DDD(Domain-Driven Design)
실제 세계에서 사건이 발생하는 집합인 Domain을 중심으로 설계하는 방법. 각각의 도메인들이 상호작용하며 설계하는것. 같은객체가 용도에 따라 역할이 바뀔 수 있다.
MSA(Micro Service Arctecture)를적용하여 1개의 시스템을 독립적으로 배포 가능한 각각의 서비스로 분할하고, 각각의 서비스는 API를 통해 데이터를 주고받으며 1개의 큰 서비스를 구성
6. MVC(Model-View-Controller) 패턴
MVC란 Model-View-Controller의 약자로 애플리케이션을 세 가지 역할로 구분한 개발 방법론이다. 사용자가 Controller를 조작하면
Controller는 Model을 통해 데이터를 가져오고 그 데이터를 바탕으로 View를 통해 시각적 표현을 제어하여 사용자에게 전달한다.
사용자 인터페이스로부터 비즈니스 로직을 분리하여 애플리케이션의 시작적 요소나 그 이면에서 실행되는 비즈니스 로직을 서로 영향 없이 쉽게 고칠 수 있는 애플리케이션을 만들 수 있게 한다.
6.1 Model, View, Controller
6.1.1 Model
Model은 Data와 애플리케이션이 무엇을 할 것인지를 정의하는 부분으로 내부 비즈니스 로직을 처리하기 위한 역할을 한다.
즉, 모델은 컨트롤러가 호출을 하면 DB와 연동하여 사용자의 입출력 데이터를 다루는 일과 같은 데이터와 연관된 비즈니스 로직을 처리하는 역할을 한다.
Model의 규칙
- 사용자가 편집하기를 원하는 모든 데이터를 가지고 있어야 한다.
- View나 Controller에 대헤서 어떤 정보도 알지 말아야 한다.
- 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야만 한다.
6.1.2 View
View는 사용자에게 보여주는 화면(UI)이 해당된다.
사용자와 상호작용을 하며 컨트롤러로부터 받은 모델의 결과값을 사용자에게 화면으로 출력하는 일을 한다.
MVC에서는 여러개의 View가 존재할 수 있다. Model에서 받은 데이터는 별도로 저장하지 않는다.
View의 규칙
- Model이 가지고 있는 정보를 따로 저장하면 안된다.
- Model이나 Controller와 같이 다른 구성요소들을 몰라야 한다.
- 변경이 일어나면 변경 통지에 대한 처리방법을 구현해야 한다.
- Model과 View는 서로의 존재를 몰라야 한다.
6.1.3 Controller
Controller는 Model과 View 사이를 이어주는 인터페이스 역할을 한다. 즉, Model이 데이터를 어떻게 처리할지 알려주는 역할이다.
사용자로부터 View에 요청이 있으면 Controller는 해당 업무를 수행하는 Model을 호출하고 Model이 업무를 모두 수행하면 다시 결과를 View에 전달하는 역할을 한다.
Controller의 규칙
- Model이나 View에 대해서 알고 있어야 한다.
- Model이나 View의 변경을 모니터링 해야 한다.
6.2 MVC의 장점
- 기능별로 코드를 분리하여 하나의 파일에 코드가 모이는 것을 방지하여 가독성과 코드의 재사용이 증가한다.
- 각 구성요소들을 독립시켜 협업을 할 때 맡은 부분의 개발에만 집중할 수 있어 개발의 효율성을 높여준다. <- 분업을 가능하게 해준다
- 개발 후에도 유지보수성과 확장성이 보장된다.
7. 비즈니스 로직
데이터가 어떻게 생성되고 저장되고 수정되는지를 정의한 것
회원이 작성한 아이디 값 저장하기 -> 회원정보가 있는 데이터베이스 연결 ->
데이터베이스에 회원이 작성한 아이디 값이 있는지 Select ->
회원의 아이디가 이미 있는지 없는지 여부를 데이터화 하여 저장 ->
데이터베이스 연결 끊기 -> View영역에게 가공된 데이터 전달
8. 메모리 구조
코드 영역 : 프로그램의 코드가 저장
데이터 영역 : 전역변수와 정적변수가 저장
힙 영역 : 프로그래머가 직접 관리할 수 있는 곳, 동적할당을 하는곳
스택 영역 : 함수의 호출과 함께 할당되며 지역변수와 매개변수가 저장되는 곳
9. 함수 호출방식
- Call by value
- 인자로 받은 값을 복사하여 처리하는 방법
- Call by reference
- 인자로 받은값의 주소를 참조하여 직접 값에 영향을 주는 방식
Leave a comment