5. 프록시 클래스라고 능사는 아니다.
프록시 객체를 사용하면 원래의 객체를 사용하는 것과
사뭇 다른 동작 경과를 보게 된다.
공유 가능성 플래그를 통해 주소를 받아와서 비교를 해야할 때
프록시를 사용하게 되면 원래 객체의 주소가 아닌
포인터 주소를 가져오게 된다. -> 주소 연산자도 오버로딩 해야함
operator[]을 이용해서 좌,우항값을 구분하려고 했는데
대입 연산자뿐만이 아니라 각종 연산자를 다 구현해 줘야한다.
원래 객체의 멤버 함수를 호출하려면
프록시에게 모조리 오버로딩 해야함, 암시적 타입변환에도 골치 아픔
6. 프록시 클래스는 어떤 객체를 대신하여 동작하게 하는 장치
-> 어떤 ‘특정한’ 동작 원리 구현에 좋다.
!
하지만 객체 생성, 소멸 문제도 잘 해결해 줘야하고(비용도 들고)
시스템이 복잡해져서 설계, 구현, 파악, 유지보수가 힘들어진다.
!
클래스의 의미구조도 바뀌어 버리는 경우도 있는데…
!
우리가 우리가 모든 동작을 다 활용하는게 아니므로
적절히 잘 사용하면 여러 프로그래밍 작업이 가능해진다.
총정리
7. 전에 배틀쉽을 만들때 CShip객체가 있고
그 아래에 CBattleShip이나 CSubmarine등이 있는데
CShip들이 많이 있는데 이것이 어떤 객체인지 알려면?
!
if문을 잔뜩 써서 typeid로 판단을 할까?
함수를 두 개 이상의 객체(타입)에 대해
가상 함수처럼 동작하도록 만들기
8. 다른 방법
이중 디스패치
각 타입에 맞는 오버로딩을 다 한다.
!
if문보다는 깔끔 하지만
다른 형제 객체들에 대해서 전부 알아야만 한다.
!
수정이 발생하면 모든 클래스가 수정되고 컴파일 되어야 한다.
9. 가상 함수 테이블의 유사구현(emulation)을 통한 이중 디스패치
객체 타입과 함수 포인터를 매칭시켜줘서
각 객체에 맞는 함수들이 실행시키도록 한다.
typeid::name보다 type_info로 쓰는게 더 좋다.
map구조가 있으므로 생성 소멸도 신경 쓰자.
10. 맵을 초기화 할려면?
유사 가상 함수 테이블의 초기화
함수 이름만 바꾸고
매개변수는 같게 해서
바로 맵에 집어 넣을수 있게 한다.
!
그리고 사용할 때에는
DynamicCast를 사용한다.
자식 클래스가 또 상속을 받게 된다면?
-> 다른 방법을 사용하세요
11. 이외의 이야기들
미래 지향적인 프로그래머가 되자
변하지 않는것은 없다.
변화를 받아들이고
변화를 대비하도록 하자
!
ex.언제는 함수추가나 오버로딩 추가
새 클래스가 추가되고 등등
!
언제나 이럴수 있다라는것을
머릿속에 넣어두자.
에자일??
12. 평생 그 프로그램을 유지보수할것이 아니면
다른 사람이 이 덩어리를 맡을 것을 염두하자.
!
어떤 클래스나 함수의 사용을 막고 싶으면 주석이나 문서보다
코드로 다른 방법으로는 못하도록 막아버리자.
!
지금은 사용안하더라도 가능한 모든 클래스에게 대입, 복사 생성도
구현을 해두도록 한다. 힘들면 private로라도…
!
그리고 중요한건 다른 사람이 알아 보기 쉽게 구현하기!
13. -언제든 null이 올수 있다는 점을 명시하자.
-코드 이식성도 중요
-캡슐화로 변경이 필요할 때 조금만 수정하게 하자.
-클래스를 완벽하게 만들자 - 지금 사용되지 않는 부분도 다 구현
-인터페이스를 설계할 때에는 자주 사용하는 기능은 모두 포함하고,
자주 일어나는 실수는 막아 두자
-> 사용하기는 쉽게 잘못 사용하기는 어렵게
-일반화를 할수 있으면 일반화 하자.
미래 지향적 사고를 가지고 만든 프로그램은
코드의 재사용성, 유지보수성, 견고성이 향상
변화하는 환경에 맞추어 변화시키기에도 좋음
단, 미래 지향적 프로그램은 현재 의 제약과 보조를 맞출 때
비로소 제 힘을 발휘
14. 상속 관계의 말단에 있지 않은 (non-leaf) 클래스는
반드시 추상 클래스로 만들자
상속관계가 하나 있는데 대입 연산자를 다 만들었는데
형제끼리 대입하는 경우가 발생 -> 부모의 연산자를 private로
->부모끼리 대입이 되질 않는 문제 발생
-> 아예 부모라는것 자체를 추상 클래스로 만들어 버리자.
!
하지만 그렇다고 모든걸 추상화 하지 말고
정말 필요한 것만 추상화 해서 쓰자
(여러번 사용되는 애들)
그리고 재사용 되는 애들!
!
하지만 수정을 귀찮게 하는 일이므로
정말 어떤것들이 사용될지 설계를 잘하는
경험이 있어야 잘 만들수 있다.
15. 한 프로그램에서 C++와 C를 함께 사용하는 방법을 이해하자.
네임 맹글링(Name Mangling)
함수 이름 뒤섞기…
C에서는 함수 오버로딩을 할 수 없어서 문제가 발생한다.
!
그래서 맹글링을 막기 위해 함수 위에 extern “C”를 붙여
C로 작성된 함수처럼 불려야 된다고 선언을 한다.
!
!
!
!
!
C#툴에서 엄청 쓰다가 지금 쓴맛을…
중괄호로 묶어 여러 함수를 같이 선언할수도 있다.
16. 정적 데이터 초기화(Initialization of Statics)
main이 시작되기 전에 정적 클래스 객체와 전역 객체, 네임스페이스와
파일 범위에 있는 객체의 생성자가 실행된다.
!
반대로 main이 끝나고 소멸자들을 호출하는 정적 데이터 소멸이 있다.
실제로는 컴파일러가
메인 앞과 뒤에 함수를 호출?!
이런 특이한 방식으로 제작되니 main은
C++로 작성하는것이 좋다.
17. -각자가 사용하는 C++와 C 컴파일러가 생성하는
목적 코드가 서로 호환되는지 확인
!
-두 개의 언어에서 동시에 사용되는 함수는 extern"C"로 선언
!
-가능하면 main은 C++로 작성
!
-new로 할당한 메모리는 delete로 해제하고,
malloc으로 할당한 메모리는 free로 해제
!
-두 개의 언어로 작성한 함수 사이에 전달할 수 있는 데이터 타입은
C컴파일러로 컴파일되는 것으로만 한정
C와 호환이 가능한 C++ 구조체는
비가상 멤버 함수까지만 가질 수 있다.
18. C++ 언어의 최신 표준안과 표준 라이브러리에 대해 익숙해지자.
표준 라이브러리의 특성
-표준 라이브러리에 속해 있는 대부분의 것들은 템플릿
!
-라이브러리의 모든 구성요소가 std라는 이름의
네임스페이스에 속해 있다
19. 표준 템플릿 라이브러리(Standard Template Library) 겉핥기
컨테이너(container), 반복자(iterator) 알고리듬(algorithm)
배열안의 일부 범위에 대해서만 find를 할수도 있었다…
20. STL의 핵심은 간결(simple)
그저 일정한 규정에 맞게 만들어진 클래스 템플릿과
함수 템플릿을 모아놓은 것일 뿐(반복다로 begin->end 훑기)
!
STL은 간결하기 때문에 확장하기도 쉽다(extensible)
기존의 STL과 같이 쓸 수 있는 컨테이너와 알고리즘, 반복자를
규정만 지켜서 만들면 직접 추가할 수 있다.(표준은 아니지만…)
Simple exTensible Library??
STL의 철학( 일반성(generality), 확장성(extensibility), 맞춤성
(customizability), 효율성(efficiency), 재사용성(reusability) )
STL공부하면 라이브러리의 설계에 대한 공부에 도움이 됨
![템플릿으로 2차원 배열을 만들고 싶은데
프록시(Proxy) 클래스
data[3][6];이런식으로 사용하고 싶은데
operator[][]은 없음
!
이런걸 만들기 위해서는
operator[]을 사용한
1차원 배열을 두번 묶은듯한
형태로 사용하면 구현 가능](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)