- OOP의 4가지 특징
- 추상화 : 공통적인 특징을 하나의 개념으로 다룸
- 캡슐화 : 정보 은닉
- 일반화 관계 : 여러 개체들이 가진 공통 특성을 하나의 개념으로 성립시키는 과정
- 다형성 : 각자의 방식으로 동작하는 능력
- OOP의 5대 원칙
- S : 단일 책임 원칙, 객체는 하나의 책임만 가진다.
- O : 개방 폐쇄 원칙, 기존의 코드를 변경하지 않으면서 기능 추가가 가능하도록 설계한다.
- L : 리스코프 치환 원칙, 일반화 관계, 자식 클래스는 부모 클래스에서 가능한 행위가 수행되어야 한다.
- I : 의존 역전 원칙, 변화하지 않는 부분에 의존하도록 설계
- D : 인터페이스 분리 원칙, 인터페이스를 클라이어트에 특화되도록 분리.
- 객체지향 프로그래밍 특징
- 사람의 사고와 가장 비슷하게 프로그래밍을 하기 위한 기법
- 하나의 클래스가 여러 개의 인스턴스가 되는 재활용성
- 실세사의 물체를 객체로 표현하고, 객체간의 상호작용을 프로그램으로 나타낸다.
- 객체 지향의 핵심은 연관되어 있는 변수와 메서드를 하나의 그룹으로 묶어서 그룹핑하는 것이다.
- CallbyRefernece / CallbyValue
- Call by Reference
- 함수 호출시 인자로 전달되는 변수의 레퍼런스(참조)를 전달한다.
- 따라서 함수 안에서 인자의 값이 변경되면, 인자로 전달된 변수의 값도 변경된다.
- Call by Value
- 함수 호출시 인자로 전달되는 변수의 값을 복사하여 함수의 인자로 전달한다.
- 복사된 인자는 함수 안에서 지역적으로 사요되는 지역 변수의 특성을 지닌다.
- 따라서 함수 안에서 인자의 값이 변경되어도, 외부의 변수의 값은 변경되지 않는다.
- 자바는 항상 Call by Value입니다.
- 기본자료형의 경우 : 변수의 값을 복사해서 전달.
- 참조자료형의 경우 : 해당 변수가 가지는 값이 레퍼런스이므로 인자로 넘길 때 Call by Value에 의해 레퍼런스가 복사되어 전달됩니다. 참조변수 자체의 레퍼런스를 얻을 수 있는 방법을 지원하지 않습니다.
- Call by Reference
- Rest API(Representational State Transfer)/ 자원의 표현에의한 상태 전달
- 웹 애플리케이션 상에 존재하는 모든 리소스에 대해 고유의 URI를 부여합니다.
- HTTP Method(Get, Post, Put, Delete)를 이용해 리소스에 대해 CRUD명령을 적용합니다.
- 응답은 JSON이나 XML 등의 형식으로 나타납니다.
- REST의 구성요소
- 자원 : 모든 자원은 고유의 URI를 가집니다. 서버에 존재하는 데이터의 총칭입니다.
- 행위 : 클라이언트가 HTTP Method를 이용하여 자원을 조작합니다.
- 표현 : 클라이언트가 자원을 조작하면 그에대한 응답을 보내는 것입니다.
- REST의 특징
- 서버-클라이언트의 구조
- 무상태성 : 각각의 요청에 대한 정보를 저장하지 않고 별개의 요청으로 처리합니다.
- 캐시 가능 : 같은 URI에 대한 반복적인 요청을 효율적으로 처리합니다.
- 일관된 인터페이스
- 자체적인 표현 구조
- 계층 구조
- 프레임워크/ 라이브러리
- 라이브러리 : 개발하는데 필요한 것 들을 모아 둔 도구들의 나열
- 프레임워크 : 애플리케이션 개발 시 필수적인 코드, 알고리즘, 데이터베이스 연동 등과 같은 기능들을 위해 뼈대를 제공해주는 것입니다. 이 뼈대 위에 개발자가 코드를 작성하여 완성합니다.
- 차이 : 프레임워크와 라이브러리의 차이는 제어의 역전(IoC)입니다. 프레임워크는 자체적인 흐름을 갖고 코드를 호출하는 반면, 라이브러리는 사용자가 흐름을 제어하며 필요에 의해 라이브러리를 호출하여 사용합니다.
- 오버로딩/ 오버라이딩
- 오버로딩 : 메소드의 이름은 같지만 매개변수의 갯수나 타입이 다른 함수를 정의하는 것.
- 오버라이딩 : 상위 클래스의 메소드를 하위 클래스에서 재정의 하는 것.
- Lombok
- java의 라이브러리로, 반복되는 메소드를 어노테이션을 사용해서 자동으로 작성해주는 라이브러리입니다.
- DDD
- Domain : 유사한 업무의 집합
- Domain Driven Design : 비즈니스 도메인별로 나누어 설계하는 방식
- 핵심 목표 : 모듈간의 의존성 최소화, 응집성 최대화
- OAuth 2.0
- 로그인, 개인정보 관리 책임을 서드파티 애플리케이션에게 위임.
- mvc 패턴
- model : 애필르케이션의 정보를 나타냅니다. view, controller에서는 어떤 정보도 알 수 없어야 합니다.
- view : 사용자가 볼수 있는 화면의 출력을 나타냅니다. model이 갖고 있는 정보를 따로 저장해서는 안됩니다.
- controller : 데이터와 사용자인터페이스 요소들을 잇는 다리역할입니다. model이나 view에 대해 알고 있어야합니다.
- 데이터정규화
- 왜 정규화를 해야 하는가? : 머신러닝 알고리즘은 데이터가 가진 feature들을 비교하여 데이터의 패턴을 찾습니다. 이때, fature의 스케일(중요도)이 심하게 차이가 나는 경우 문제가 됩니다
- 그래서 모든 데이터 포인트가 동일한 정도의 스케일으로 반영되도록 해주는 게 정규화의 목표입니다.
- Min-Max Normalization(최소-최대 정규화)
- 가장 일반적인 방법으로 모든 feature에 대해 각각의 최소값을 0, 최대값을 1로 설정하고 다른 값들은 0과 1사이의 값으로 변환합니다.
- outlier(이상치)에 너무 많은 영향을 받는 단점이 있습니다. 예를들어 100개의 값이 있는데, 그중 99개가 0과 40사이에 있고, 1개만 100이라면 99개의 값이 모두 0 ~ 0.4 사이의 값으로 변환됩니다.
- 이를 보완하기 위해 z-점수 정규화를 고려합니다.
- Z-Score Normalization
- 정규화 값 = (X - 평균) / 표준편차
- 만약 feature의 값이 평균보다 작으면 음수, 평균보다 크면 양수로 나타납니다.
- 음수와 양수의 크기는 feature의 표준편차에 의해 결정됩니다. 그러므로 표준편차가 크면 정규화되는 값이 0에 가까워집니다.
- 이상치를 잘 처리하지만, 정확하게 동일한 척도로 정규화 된 데이터를 생성하지는 않습니다.
- Get / Post
- Get
- 클라이언트에서 서버로 어떠한 리소스로 부터 정보를 요청(read)하기 위해 사용되는 메소드입니다.
- 요청을 전송할 때 URL 끝에 파라미터로 포함되어 전송됩니다.(쿼리 스트링)
- 불필요한 요청을 제한하기 위해 요청이 캐시될 수 있습니다.
- 브라우저 기록에 남습니다.
- 200 HTTP 응답 코드를 여러 형식의 데이터와 함께 반환합니다.
- Post
- 전송해야될 데이터를 HTTP메세지의 Body에 담아서 전송합니다.
- Body에 담기 때문에 데이터 길이에 제한이 없습니다.
- 캐시, 브라우저 기록, 북마크 추가 불가능
- 자원 생성은 2001 HTTP 응답 코드를 반환합니다.
- idempotent하지 않습니다. put, patch, delete에 적당합니다.
- idempotent
- 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질
- get 요청은 서버에게 동일한 요청을 보내면 동일한 응답이 돌아옵니다.
- Post 요청은 동일한 요청을 보내면 응답이 다를 수 있습니다.
- Get
댓글남기기