0627 ~ 0703

# 0627 ~ 0703

# 0627 - 객체지향 생활 체조 원칙 9가지

# 1. 한 메서드에 오직 한 단계의 들여쓰기만 한다.

한 메서드에 들여쓰기가 여러 개 존재한다면, 해당 메서드는 여러가지 일을 하고 있다고 봐도 무관하다.
메서드는 맡은 일이 적을수록 재사용성이 높고 디버깅도 용이하다.

# 2. else 키워드를 쓰지 않는다.

조건문은 복제의 원인이 되기도 하며 가독성 또한 좋지 않다.
디자인 패턴의 Strategy 패턴 - 상태 인라인(status inline)의 분기를 막기 위한 다형성(polymorphism) 예제가 있다.
상태에 대한 분기가 몇 군데 걸쳐 중복돼 있을 때 Strategy 패턴은 특히 유용
간단한 경우엔 guard clause(보호 구문) 사용 : if에 return을 쓸 것(early return) - 단, 많이 쓰면 간결함을 해칠 수 있다.

# 3. 모든 원시값과 문자열을 포장(wrap)한다.

원시형 변수로는 컴파일러가 의미적으로 맞는 프로그램 작성을 안내할 수 없다. (예 - 년도에 대한 유효성 검사)
포장한 객체로라면 아주 사소하더라도 컴파일러와 개발자에게 해당 값이 어떤 값이며 왜 쓰는지에 대해 정보를 전달할 수 있다.
또한 시간이나 돈처럼 작은 단위를 포장한 객체의 경우엔, 행위(메서드)를 놓을 곳을 마련해준다.

# 4. 한 줄에 점을 하나만 찍는다.

(스트림 등 체이닝하는 일부를 제외)
어느 코드 한 곳에서 점이 둘 이상 있다면, 해당 부분을 다시 리팩토링 해야 한다.

어쩌면 다른 두 개의 객체를 동시 조작하고 있는 것일 수도 있다.

디미터(Demeter)의 법칙 : "친구하고만 대화하라"
자신 소유의 객체, 자신이 생성한 객체, 그리고 누군가 준(파라미터로) 객체에만 메시지를 보낼 것

그렇지 않을 경우, 다른 객체에 너무 깊숙이 관여하게 된다 : 캡슐화를 어기는 것

메시지를 받는 객체는 자신의 속을 오픈하기보다는, 작업을 해주도록 해야 한다.

# 5. 줄여쓰지 않는다.

과도한 축약은 코드 가독성을 저해한다. 무조건 짧다고 좋은 것은 아니다.
메서드의 이름이 긴 이유 중 하나는, 책임을 너무 많이 갖고 있거나, 적절한 클래스의 아래에 위치하지 않아서 일 수 있다.

# 6. entity를 작게 유지한다.

50줄 이상 되는 클래스 또는 10개 파일 이상의 패키지는 없어야 한다.
[ 클래스 ]

50줄 이상인 경우 보통 클래스가 한 가지 일만 하지 않는다.
50줄 정도면 스크롤을 내리지 않아도 된다.

[ 패키지 ]

하나의 목적을 달성하기 위한 연관된 클래스들의 모임.
작게 유지하면 패키지가 진정한 정체성을 가지게 된다.

# 7. 2개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.

새로운 인스턴스 변수를 가진 클래스는 응집도가 떨어진다. 많은 인스턴스 변수를 가진 클래스로 응집력있는 단일 작업을 설명할 수 있는 경우는 거의 없다.
인스턴스 변수의 분해는 여러 개의 관련 인스턴스 변수의 공통성을 이해하게 하여 자료구조형으로 묶어 일급 컬렉션으로 생성할 수 있게 해준다.
인스턴스 변수들의 집합을 갖고 있는 것에서, 협력 객체(일급 컬렉션/Wrapper 객체)의 계층 구조로 분해하면 더 효율적인 객체 모델이 될 수 있다. 복잡하고 덩치 큰 객체를 이해하는 것은 어렵지만, 분해하면 간단해진다.
분해하는 것이 어렵거나 막막하다면, 객체를 상관 관계가 있는 반(half)씩 나누거나, 인스턴스 변수를 둘 골라서 그로부터 하나의 객체를 만드는 등을 하는 것을 추천한다.

# 8. 일급 컬렉션을 쓴다.

콜렉션(Collection)을 가진 클래스는 콜렉션 외에는 다른 멤버 변수를 가지면 안된다는 원칙이다. 어떤 데이터 세트(Set)를 가지고 있는데 조작이 필요하다면 그 데이터에만 집중된 클래스를 만들어야 한다.

# 9. getter/setter/property를 쓰지 않는다.

이 규칙은 "말은 하되, 묻지는 말라.(Tell, don't ask)"로 대변된다. 객체의 상태를 가져오는 접근자(accessor)를 사용하는 것은 괜찮지만, 객체 바깥에서 그 결과값을 사용해 객체에 대한 결정을 내리는 것은 안된다. 한 객체의 상태에 대한 결정은 어떤 것이든 그 객체 안에서만 이루어져야 한다.

# 0701 - 드라이빙 테이블(DRIVING TABLE)

# 드라이빙 테이블이란?

JOIN시 먼저 액세스 돼서 ACCESS PATH를 주도하는 테이블을 드라이빙 테이블이라고 한다.

즉, 조인시 먼저 액세스되는 쪽은 드라이빙 테이블(DRIVING TABLE, OUTER TABLE)이라고 하며, 나중에 액세스 되는 테이블을 드리븐 테이블(DRIVEN TABLE, INNER TABLE)이라고 한다.

인덱스의 존재 및 우선순위 혹은 FROM절에서의 TABLE 지정 순서에 영향을 받으며 어느 테이블이 먼저 엑세스되느냐에 따라 속도의 차이가 크게 날 수 있으므로 많은 양의 데이터를 다룰 때, 드라이빙 테이블은 매우 즁요하다

조건을 만족하는 5000만 건인 A테이블과
조건을 만족하는 1000건인 B테이블과
조인 시 드라이빙 순서에 따라 속도의 확연한 차이가 있다.
 
5000만 건을 먼저 드라이빙하면
5000만 번을 반복하며 B테이블 탐색하며,
 
1000건인 B가 먼저 드라이빙되면
최대 1000번 A테이블 탐색이 반복이 된다.

즉, 작업 대상이 되는 행(rows)의 수가 적은 테이블부터 액세스 되어야 전체 탐색이 줄어든다.

# 드라이빙 테이블 결정규칙

규칙 기반 옵티마이저(Rule-Based Optimizer, RBO)에서는 연산자, 인덱스의 유무, 조건절의 형태 등 정해진 규칙의 우선순위에 따라 실행계획을 생성한다.

인덱스를 이용한 액세스 방식이 전체 테이블 액세스 방식보다 우선순위가 높음
조인 칼럼에 대한 인덱스가 양쪽 테이블에 모두 존재할 때, 우선순위가 높은 테이블을 선ㅌ택
조인 칼럼에만 인덱스가 존재하는 경우에는 인덱스가 없는 테이블을 먼저 선택하여 조인 수행
만약 조인 테이블의 우선순위가 동일하지 않다면, FROM 절에 나열된 테이블의 역순으로 수행

비용기반 옵티마이저(Cost-Based Optimizer, CBO)는 규칙의 우선순위가 아닌 쿼리를 수행하는데 소요되는 예상 비용을 바탕으로 실행계획을 생성한다. 통계정보, DBMS 설정정보, DBMS 버전 등의 차이로 인해 똑같은 SQL문이라도 서로 다른 실행계획인 생성 될 수 있다

SELECT * 
FROM employees e, dept_emp de
WHERE e.emp_no=de.emp_no;

이 두 테이블의 조인 쿼리에서 emp_no 칼럼과 dept_emp 테이블의 emp_no칼럼에 각각 인덱스가 있을 때와 없을 때의 조인순서를 비교해 보면 아래와 같다.

두 칼럼 모두 각각 인덱스가 있는 경우
옵티마이저의 판단으로 각 테이블의 통계 정보에 있는 레코드 건수에 따라 employees가 드라이빙 테이블이 될 수도 있고, dept_emp 테이블이 드라이빙 테이블이 될 수도 있다.
dept_emp.emp_no 에만 인덱스가 있는 경우
employees 테이블의 반복된 풀 스캔을 막기 위해 employees 테이블을 드라이빙 테이블로 선택하고 인덱스가 있는 dept_emp 테이블을 드리븐 테이블로 조인을 수행하도록 실행 계획을 수립한다.
employees.emp_no에만 인덱스가 있는 경우
dept_emp 테이블이 드리븐 테이블로 선택된다면 employees 테이블의 레코드 건수만큼 dept_emp 테이블을 풀 스캔해야만 "e.emp_no=de.emp_no" 조건에 일치하는 레코드를 찾을 수 있다. 그래서 옵티마이저는 항상 dept_emp 테이블을 드라이빙 테이블로, employees 테이블을 드리븐 테이블로 선택하게 된다.
두 칼럼 모두 인덱스가 없는 경우
어느 테이블을 드라이빙으로 선택하더라도 드리븐 테이블의 풀 스캔 발생하기 떄문에 스캔되는 레코드 수에 따라 옵티마이저가 적절히 드라이빙 테이블을 선택하게 된다. 조인이 수행될때 양쪽 테이블의 칼럼에 모두 인덱스가 없을 때만 드리븐 테이블을 풀스캔한다. 나머지 경우에는 드라이빙 테이블을 풀 테이블 스캔을 사용할 수는 있어도 드리븐 테이블을 풀 테이블 스캔으로 접근하는 실행 계획은 옵티마이저가 거의 만들어내지 않는다.

0606 ~ 0619 0711 ~ 0717