블로그 이미지
이태원에서 사는 다섯식구의 무직 가장. 흰둥에미

카테고리

분류 전체보기 (184)
Itaewon (2)
ryu's?? (1)
20121210이전 (20)
20130827이전 (147)
soo'study (13)
Total39,468
Today11
Yesterday4

항목 18 - 21

20130827이전/EC++ / 2012.12.21 23:32

설계 및 선언


항목 18. 인터페이스 설계는 제대로 쓰기엔 쉽게, 엉터리로 쓰기엔 어렵게 하자.

            Date d(Month(3), Day(30), Year(1995));  --> 숫자를 직접 인자로 받는다면, 순서가 헷갈릴 수 있음.

            레퍼런스 반환 함수의 반환 타입에 const를 붙여 if (a * b = c) 등의 오타로 인한 버그 방지.

            When in doubt, do as the ints do.

            인터페이스 사이의 일관성 잡아주기.

            팩토리 함수가 스마트 포인터를 반환하여 사용자가 객체 소멸이나, 직접 스마트 포인터를 생성치 않게 한다.

            특히, tr1::shared_ptr의 경우 교차 dll 문제를 해결해 준다.(객체 생성과 삭제를 다른 dll에서 할 때의 문제)


항목 19. 클래스 설계는 타입 설계와 똑같이 취급하자.

            좋은 타입은 일단 문법이 자연스럽고, 의미구조가 직관적이며, 효율적인 구현이 한가지 이상 가능해야 함.

            (1) 새로 정의한 타입의 객체 생성 및 소멸은 어떻게 이루어져야 하는가?

            (2) 객체 초기화는 객체 대입과 어떻게 달라야 하는가?

            (3) 새로운 타입으로 만든 객체가 값에 의해 전달되는 경우에 어떤 의미를 줄 것인가?

            (4) 새로운 타입이 가질 수 있는 적법한 값에 대한 제약은 무엇으로 잡을 것인가?

            (5) 기존의 클래스 상속 계통망에 맞출 것인가?

            (6) 어떤 종류의 타입 변환을 허용할 것인가?

            (7) 어떤 연산자와 함수를 두어야 의미가 있을까?

            (8) 표준 함수들 중 어떤 것을 허용하지 말 것인가?

            (9) 새로운 타입의 멤버에 대한 접근권한을 어느 쪽에 줄 것인가?

            (10) '선언되지 않은 인터페이스'로 무엇을 둘 것인가?

            (11) 새로 만드는 타입이 얼마나 일반적인가?

            (12) 정말로 꼭 필요한 타입인가?


항목 20. '값에 의한 전달'보다는 '상수객체 참조자에 의한 전달'방식을 택하는 편이 대개 낫다.

             사본을 만들어 내지 않는다.

             복사 손실 문제(slicing problem)가 없어짐

            (파생 클래스 객체가 기본 클래스 객체로서 전달될 때, 복사시 기본 클래스의 복사 생성자만 호출됨.)

            기본 제공 타입은 '값에 의한 전달'을 해도 그럭저럭 괜찮다.


항목 21. 함수에서 객체를 반환해야 할 경우, 참조자를 반환하려고 들지 말자.

            inline const A operator*(const A& lhs, const A& rhs) { return A(lhs...., rhs.....); }

            RVO(Return Value Optimization) - 반환 값 최적화

'20130827이전 > EC++' 카테고리의 다른 글

항목 26 - 28  (0) 2012.12.22
항목 22 - 25  (0) 2012.12.22
항목 18 - 21  (0) 2012.12.21
항목 13 - 17  (1) 2012.12.21
항목 9 - 12  (0) 2012.12.21
항목 5 - 8  (0) 2012.12.18
Posted by 흰둥에미

최근에 달린 댓글

최근에 받은 트랙백

글 보관함