#[ ORM ]
- 데이터베이스를 배제하고 비지니스 로직을 짤 수 있다.
- 자바는 OOP고 DB는 관계형이기때문에 구조설계가 중요하다.
- 차근차근 한단계씩 해결하며 고민해나간다.
- 객체를 기반으로 테이블이 자동으로 생성된다(pkey, fkey 등)
- 소스랑 DB랑 싱크를 맞출 수 있다.
- 개발 -> 운영으로 넘어갈 때 변경된 스키마를 하나하나 찾을 필요가 없다.
#[ DDD(Domain Driven Design) - Modeling ]
- 모델링 기법
- 프로젝트 구성원, 기확가, 비지니스 전문가, 개발자 간의 생각이나 목표가 다를 수가 있다.
- 실제로 시스템을 구축하고 보면 각자가 생각한 것과 다른 결과물이 나오기 때문에 많은 비용이 필요하다.
- 이를 예방하기 위해 ddd가 고안되었다.
- 실제 비지니스가 어떤식으로 돌아가는지 빠르고 명확하게 다이어그램 등 모델을 이용해 표현한다.
- 프로젝트 구성원끼리 용어를 통일한다.
- 용어가 정의될 때마다 기록하여 나중에 참여한 구성원도 쉽게 참여 할 수 있도록 한다.
- 전체적인 도메인 모델이 완성되면 세부모델로 나눈다.
- 모델을 크게 나누면 세부적인 흐름을 알기 어려우므로 호용성이 떨어진다.
- 업무의 독립단위 또는 프로젝트팀 단위로 나누어 분배하고, 타 도메인 모델과 연관이 있을 경우 나누어진 모델간 연계성을 파악할 수 있도록 한다.
- 공통으로 사용되는 모듈은 Shared Kernel이라 하고 연관되는 프로젝트팀이 같이 설계하고 변경해서 반영하도록 가이드한다.
#[ 접근제한자 ]
- public : 모든 접근을 허용
- protected : 같은 패키지 폴더 내의 객체와 상속관계의 객체들만 허용
- default : 같은 패키지 폴더 객체만 허용
- private : 현재 객체에서만 허용
클래스 : public, default
생성자 : public, protected, default, private
멤버변수(전역) : public, protected, default, private
멤버메소드(전역) : public, protected, default, private
지역변수 : 접근제한자 불허
#[ Thread vs Process ] 프로세스
- 프로세스는 독립적으로 수행되기 때문에 메모리를 다른 프로세스와 공유하지않는다.
- 서로 다른 프로세스끼리 통신을 하려면 컨텍스트 스위칭이 일어나는데 이게 성능저하를 발생시킨다.
쓰레드
- 쓰레드는 하나의 프로그램에서 여러개의 실행흐름을 가지기 위한 모델
- 프로세스처럼 완벽하게 독립된 구조는 아니고 쓰레드간 메모리를 공유한다.
프로세스 사이에서 공유하는 메모리가 하나도 없기 때문에 컨텍스트 스위칭이 발생하면 캐쉬에 있는 모든 데이터를 모두 리셋하고 다시 캐쉬 정보를 불러와야 한다.
-쓰레드는 캐쉬 정보를 비울 필요가 없기 때문에 프로세스와 쓰레드의 컨텍스트 스위칭 속도의 차이는 이때 발생한다
#[ List vs Array ]
#[ Collection ]
#[ Suvlet Context ]
#[ AOP(Aspected Oriented Programing) ]
- 관점지향 프로그래밍
- 각 메소드에 공통적으로 적용시킬 때 메소드를 수정하는 것이 아닌 공통로직을 적용 시킬 수 있다.
- 간단한 메소드 성능검사
- 트랜잭션 처리
- 조인포인트 : 횡단 관심 모듈의 기능이 삽입되어 동작 할 수 있는 실행가능한 특정위치
- 포인트컷 : 어떤 클래스의 어느 조인 포인트를 사용할 것인지 결정하는 선택 기능
- 어드바이스 : 각 조인포인트에 삽입되어져 동작 할 수 있는 코드
- Before Advice : 메소드 실행 전에 적용되는 Advice - After running advice : 메소드가 정상적으로 실행되고 난 후에 실행 - After throwing advice : 예외를 발생시킬때 적용되는 Advice(catch와 비슷) - Around advice : 메소드 호출 이전, 이후, 예외발생 등 모든 시점에 적용가능한 advice - 인터셉터 : 한개의 invoke를 가지는 어드바이스
- 위빙, 크로스컷팅 :
- 1억개의 List
List면 Collection의 리스트인가요 아니면 링크드리스트? 어레이리스트? 콜렉션 list면 순서는 유지되어야하고 중복값을 지워야하기때문에 중복을 불허하는 Set을 쓰면 될거같은데 순서까지 지켜야하니 LinkedHashSet으로 구현하면 순서와 값이 모두 유지될 것같습니다.
#[ Thread Safe ]
- 메소드가 사용하는 변수들이 전역변수, static변수가 아닌 지역변수형태로 저장되어있어야한다.
- 힙메모리 혹은 파일과 같이 다른 쓰레드에서 접근 가능한 자원을 사용하지 않아야 한다.
#[ 디자인패턴 ]
- 옵저버패턴 : 옵저버 패턴에서는 연예인과 팬을 구현하는 것이다. 연예인 -> 팬 전파
- 스트래티지패턴 : 전략 패턴은 갑작스런 알고리즘의 변화에도 유연하게 대처가능 합니다. 알고리즘을 캡슐화하기 때문입니다. 따라서 언제든지 알고리즘이 변경된다면 프로세스의 큰 틀을 바꾸지 않고도 유연한 프로그래밍을 할 수 있습니다.
- 데코레이터 패턴 : 클래스를 사용하여 기능을 확장하는 방법, 프로그램을 실행중에도 확장할 수 있다.
- 템플릿 메소드 패턴 : 알고리즘의 뼈대를 맞추는 패턴, 전체 레이아웃은 통일시키지만 상속받은 클래스로 하여금 어느정도 유연성을 준다.
- 팩토리 메소드 패턴 : 클래스간의 결합도를 낮추기 위한 것. 직접 객체를 생성해 사용하는 것을 방지하고 서브클래스에 위임함으로써 효율적인 코드 제어를 할 수 있고, 의존성을 제거한다.
- 컴포지트 패턴 : 단일객체든 객체들의 집합이든 같은 방법으로 취급하는 패턴, 다시말해 개별적인 객체와 객체들의 집합간의 처리방법이 차이가 없을 경우 사용, 트리구조로 구현
- 싱글톤 패턴 : 단 하나의 유일한 객체를 만들기 위한 패턴
- 어탭터 패턴 : A엔진을 사용중인데 B엔진이 성능이 더 좋아서 B를 적용해야한다. 이때 별다른 수정 없이 기본로직을 그대로 사용할 수 있는 패턴
#[ 포트폴리오 ] ##비스킷 : sqlite안쓴이유. contentProvider라는 기능을 몰랐고, 일정이 매우 촉박했다.
#[ database ]
insert into table (a, b, c) values('1', '2', '3');
update table set a='1', b='2' where c = '3'
###join : 두개 이상의 테이블간 논리적 관계를 기준으로 결과집합을 만든다.
- inner : 두 테이블간 공통으로 들어가 있는 값을 집합으로 만든다.(on에 맞는 조건으로)
- outer : inner join 결과 + 한쪽에만 내용이 있는것도 결과 집합으로 만든다.(left:왼쪽기준, right:오른쪽기준)
- full outer join : 왼쪽과 오른쪽 조건에 상관없이 양쪽 값을 가져온다.
- cross join : 결과값이 한쪽 테이블의 모든 행과 다른쪽테이블의 모든행을 조인시킨다. 결과는 각 테이블갯수를 곱한만큼 생성되며, ON이 사용 불가능하다.
- self join : 같은 데이터지만 다른 열에 있는 경우 조인해서 사용 가능