2. 구현과 상속
C++의 미덕 아닌가요?
OOP도 이걸로 발휘 되는 거고!
라고 말은 잘하지만,
여전히 과거의 잔해에서 헤메는 일이 많다
C++로 쓸 수 있는 건 해줘야...
3. C 스타일처럼 작성하는 것만 피하면 될까?
예컨대 맨 앞에서 모든 변수를 선언 한다든가...
그게 아니고!!
예외가 발생되어도 사용되지 않을 변수를
확실하게 제거하자
옆 코드에서 예외 뜨면 encrypted는 쓰나?
std::String encryptPassword(const std::string& password)
{
using namespace std;
string encrypted;
if(password.length() < MinimumPasswordLength){
throw logic_error(“it’s short”);
}
return encrypted;
}
4. 변수를 사용해야 할 때가 오기 전까지
변수의 정의를 늦추는 것이 기본!
하지만... 끝이 아니다!
초기화인자를 넣기 직전까지
정의를 늦출 수 있는지도 확인하라!
5. 그럼 for문은 어떻게 할래?
루프 내부와 외부에서 선언하는 것에 따라
충분히 다른 것 아시죠?
//방법A: 루프 바깥쪽에 정의
Widget w;
for (int i = 0 ; i< n; ++i)
{
w = i;
}
//방법B: 루프 안쪽에 정의
Widget w;
for (int i = 0 ; i< n; ++i)
{
Widget w;
}
• A 방법: 생성자 1번 + 소멸자 1번 + 대입 n번
• B 방법: 생성자 n번 + 소멸자 n번
더 효율적인 것을 골라서 쓰라!
6. 이것도 C 스타일로 자주 쓰시죠?
CASTING
CPP 캐스팅을 씁시다
• static_cast : 기본적인 캐스팅(const 속성 불가)
• dynamic_cast: 포인터가 가리키는 객체 상속 관계 타입 변경
• reinterpret_cast: 하부 수준 캐스팅 연산자(완전 강제)
• const_cast: 객체의 상수성을 없애는 용도로 사용
7. 왜 써야 할까?
1. 코드 가독성 향상
2. 컴파일러가 사용 에러를 진단할 수 있음
하지만,
캐스팅은 비용이라는 것을 잊어서는 곤란하다
런타임에 실행되는 코드가 만들어지는 경우가 왕왕!
8. 또한 캐스팅을 세심하게 하지 않으면
런타임에서 생성/소멸 되는 엄한 객체에
명령을 주는 경우가 발생!
캐스팅시 사본이 임시적으로 만들어지는 경우!
해당 사본에 동작을 수행함
캐스트가 항상 답은 아니라는 것!
＂캐스트 연산자가 당기는 상황이라면 문제가..”
(특히 dynamic_cast는 더 그렇다)
9. 그래도 쓰고 싶은데...
추천1. 파생 클래스 객체에 대한 포인터를 컨테이너에 담아 사용
추천2. 상위 클래스에서 가상 함수로 제공하면 됨
잘 만든 C++코드는 캐스팅이 거의 없다!
10. 참조자, 포인터 및 반복자(iter)의 공통점은?
핸들(handle)이다!
(다른 객체에 손을 댈 수 있게 하는 매개자)
어떤 객체든 내부 요소에 대한 핸들을 반환하면
이미 OOP는 포기되었다고 봐야 한다.
const 멤버도 상태 변경이 될수도...
어마무시한 상황!
11. 반환 타입에 const를 붙여줘 볼까?
읽은 수는 있지만 쓸 수는 없게!
그러나, 이미 사용자가 내부를 보는 설계는 그대로
class GUIObject { … };
const Rectangle
boundingBox(const GUIObject& obj);
GUIObject *pgo;
…
const Point *pUpperLight = &(boundingBox(*pgo).upperLeft());
캡슐화 말고도 문제가 더 있으니...
댕글링(dangling)이 있었다
옆 코드에서는 핸들이 무효 영역을 가리킨다
12. 계속 코드에서 예기치 않은 문제가...
코드가 그렇다면 함수에서는 적어도 예외에서 안전해야 된다!
함수의 예외 안전성은 다음 조건을 충족해야 한다
• 자원이 새도록 만들어선 안 됨
• 자료구조가 더럽혀 지지 않아야 함
좀 더 구체화 해볼까요?
• 기본적인 보장: 함수 동작 중 예외가 나와도 함수 관련 프로그램이 유효하도록!
• 강력한 보장: 함수 동작 중 예외가 나오면 프로그램의 상태를 변경하지 않도록!
SQL 트랜잭션 같은 녀석!
• 예외불가 보장: 예외를 절대로 던지지 않는 보장
13. 가장 잘 사용하는 방법은?
복사 – 후 - 맞바꾸기
함수에서 직접 대상을 건드리지 않고,
따로 작업을 다 한 다음
작업 결과와 대상을 맞바꿔 주는 방법 사용
14. 마법의 가속 툴 inline 함수?!
컴파일 과정에서 컴파일러가
함수 영역에 직접 코드를 박아주는 inline함수
속도가 빨라진다고 남용하는데...
(호출 비용 면제)
등가 교환의 법칙이 만화에만 있는 것이 아님!
목적 코드의 크기가 커짐
인라인 함수로 부풀려진 코드는 성능 저하 원인
(페이징 횟수 증가, 캐시 적중률 하락 등)
15. inline 함수는 컴파일러가 하는 것!
= 당연히 헤더에 집어넣어야 한다
컴파일러가 본문 바꿔치기를 하려면
함수 형태를 알아야 하지요
어디서 많이 들었는데?
템플릿도 유사한 이유로 헤더에 들어야 하지 않던가?
맞는데 둘 사이에는 아무런 관계가 없다.
흔히 같이 쓰는 경우가 많은데,
필요한 경우에만 템플릿을 inline 함수로 선언하라
16. inline 함수 생각보다 좋기만 한 게 아니네...
당연하죠!
전략적으로 사용하면 이득이 있긴 하니 어떻게 쓸까요?
1. 일단 아무것도 인라인 하지 말자
2. 정말 단순한 함수에 한해서 인라인 함수 선언
(명확한 스펙의 함수)
17. 왜 나는 하나의 파일을 변경했는데,
다시 빌드하면 와장창 컴파일이 일어날까?
파일 사이의 컴파일 의존성이 넘치기 때문이죠.
이런 일은 일반적으로 ‘정의’에 의존한
객체 설계가 가져오기 쉽습니다.
‘선언’에 의존하도록 하면 최소화 가능합니다.
18. 좀 더 풀어볼까요?
문제는 헤더파일 제작!
헤더 파일은 실용적으로 의미를 갖는 한계점에서 자체조달 형태로 제작
정의부(impl)까지 영향을 주지 않도록 하자는 것입니다.
• 객체 참조자 및 포인터로 충분한 경우 객체를 직접 사용 금지
• 할 수 있는 한 클래스 정의 대신 선언에 의존 하도록
• 선언부와 정의부에 대해 별도의 헤더를 제공
사실 export 기능이 있는데... 잘 안쓴다
19. 일반적으로 상속하는 키워드는 public 입니다.
(사실은 습관적)
- class 이름 : public 부모 이름 -
이런 식이죠
그런데... 저게 public 고정일 이유가 없었습니다.
당연히 protect, private 등이 있을 수 있죠.
(우리가 안 배웠을 뿐)
20. 왜 우리는 public을 당연한 것처럼 썼을까요?
개념 상으로 설명하기 좋기 때문이죠
부모를 온전히 받아서 처리하는 public이
전체 개념은 쉽게 들어옵니다.
하지만,
public 상속의 의미는 “is –a” 관계입니다.
기본 클래스에 적용되는 모든 것이
파생 클래스에 그대로 적용되어야 함
21. 당연한 것 아냐? 라고 하지만
우리는 이미 대충 공통점을 뽑아서
부모 클래스에 놓는데 익숙하다
has-a 관계와 혼재되어 있기 때문이다
정사각형은 정말 사각형의 자식이 될 수 있는가?
펭귄은 새의 자식이 될 수 있는가?
자식이 될 수는 있지만, public은 아니라는 것!
정확히 구분해서 쓰자!
22. 상속에서 우리가 쉽게 잊는 것이 또 있다
이름의 중요성이다!
이름은 함수 구분용으로 쓰는 것이 아니라
유효범위를 결정한다.
제어 범위가 넘어가는 순간 같은 이름도
다른 이름이 되는 일이 생긴다.
당연히 바람직 하지 않다
23. 만약 기본 클래스에서 오버로드가 발생했는데
자식 클래스에서 이름이 바뀐다면?!
오버로드가 더 이상 동작하지 않는 일이 발생!
따라서 옆 코드와 같이 using을 사용할 것
24. 여기에 public 상속도 두 가지 개념으로 나뉩니다.
인터페이스 상속 과 구현 상속
public으로 상속되어 생성한 자식 클래스는
인터페이스는 물론이며 모든 함수를 그대로 넣습니다
• 순수 가상 함수는 인터페이스를 전달 하고자 함
• 단순 가상 함수는 인터페이스+구현 상속
• 비가상 함수는 인터페이스와 더불어 필수적 구현 전달
25. 이런 구분이 있음에도 정확히 사용하지 않으면...
문제1. 모든 멤버를 비가상 함수로 선언
문제2. 모든 멤버 함수를 가상 함수로 선언
앞서 이야기한 각 함수의 특징을 이해하고
적재 적소에(?!) 사용할 필요가 있다.
26. 가상 함수를 대체할 수 있는 방법은 없나?
가상 함수를 쓰다가 오히려 설계가 더 산으로 가는 기분이…
이럴때 이미 있는 개념을 가져다 써보는 것도 방법!
조금은 고전적이지만,
• 비가상 인터페이스 관용구 사용
공개되지 않은 가상 함수를 비가상 public 멤버 함수로 감싸 호출
• 함수 포인터 데이터 멤버로 대체
• tr1::function 데이터 멤버로 대체
호환되는 시그니처를 가진 다른 개체를 사용
• 다른 쪽 계통에 있는 가상 함수로 대체
27. 항목 36, 37은 기존 개념에 반기를 들고 싶으면...
그래도 하지 말 것
뭔데?!
36: 상속 받은 비가상 함수를 자식에서 재정의 하기
37: 상속 받은 기본 매개변수 값 자식에서 재정의 하기
뭔가 상식인데...
자세한 건 우리 수업시간에 다 했음(상식)
28. 우리가 public 상속만 아는 이유는...
사실 private 상속을 거의 쓰지 않기 때문입니다.
공백 기본 클래스 최적화를 제외하고는
private를 정당화 할 거리가 없음
대부분의 상속은 is-a 관계라는 것도 한 몫
private 상속의 의미는 is-implemented-in-terms-of
공백 기본 클래스로 공간 절약이 가능하기에 의미 있음
29. 한 객체가 두 가지 객체의 기능이 필요하다!
이런 경우 대부분의 선택!
‘다중 상속’
과연 항상 답인가?
항상 이라는 것은 없다!
단일 상속보다 복잡하기에 새로운 모호성 문제 가능성
흔히 다이아몬드 상속이라고 불리는 구조가 나오면
마지막 자식에는 최상위 부모가 두 번 상속!
30. 다중 상속을 잘 쓰는 방법
인터페이스 클래스와 구현 클래스를 나누고
인터페이스 클래스로부터는 public 상속
구현 클래스에서는 private 상속을 받는 것
그래도..
다중 상속은 복잡하니 계속 방법을 찾아봅시다
