4. Class Design and Inheritance

클래스 설계와 상속에 대해 알아보자.

32. Be clear what kind of class you’re writing.

자신을 알라. 클래스에는 여러 가지가 있다. 무엇을 쓰는지를 알라.

33. Prefer minimal classes to monolithic classes.

분할 정복하라. 작은 클래스는 쓰기도, 올바르게 하기도, 테스트하기도, 사용하기도 쉽다. 더 다양한 상황에서 쓰기도 쉽다. 간단한 개념을 포함하는 작은 클래스를 많은 복잡한 개념을 구현하려 하는 잡탕 클래스에 비해 선호하라.

34. Prefer composition to inheritance.

상속 세금을 피하라. 상속은 C++에서 우정 다음으로 끈끈한 결속 관계이다. 끈끈한 결속은 선호되지 않으며 가능한 한 피해야 한다. 그러므로, 상속이 진정으로 설계에 이득을 주지 않는다면 컴포지션을 상속에 대해 선호하라.

35. Avoid inheriting from classes that were not designed to be base classes.

어떤 사람들은 자식을 갖기 원하지 않는다. 독립 클래스로 쓰이려는 클래스는 기반 클래스와 다른 청사진을 갖는다. 독립 클래스를 기반으로 삼는 것은 심각한 설계 오류고 피해야 한다. 동작을 추가하려면 멤버 함수 대신 비멤버 함수를 선호하라. 상태를 추가하려면 컴포지션을 상속 대신 선호하라. 구체적 기반 클래스로부터 상속하는 것을 피하라.

36. Prefer providing abstract interfaces.

추상학을 사랑하라. 추상 인터페이스는 구현이나 상태 관리 세부 사항에 신경 쓸 필요 없이 추상화를 잘 집중할 수 있도록 돕는다. 설계 계층이 추상 개념을 모델링하는 추상 인터페이스를 구현하도록 하라.

37. Public inheritance is substitutability. Inherit, not to reuse, but to be reused.

무엇을 알아야 하는가: public 상속은 기반 클래스에 대한 포인터나 참조가 어떤 파생 클래스의 오브젝트를 코드 정확성을 깨지 않고 존재하는 코드를 변경하지 않은 채 참조하도록 한다.

어떤 이유를 알아야 하는가: 기반 클래스 내 코드를 재사용하기 위해 public 상속을 하지 말라. 재사용되기 위해 public 상속을 하라 (기반 오브젝트를 다형적으로 사용하는 존재하는 코드를 쓰기 위해)

38. Practice safe overriding.

책임감 있게 오버라이딩하라. 가상 함수를 오버라이딩할 때는 대입 가능성을 보존하라. 구체적으로, 기반 클래스의 함수의 사전조건과 사후조건을 보존하라. 가상 함수의 기본 매개변수를 바꾸지 말라. 오버라이딩한 함수를 가상 함수로 재선언하라. 기반 클래스의 오버로드를 숨기지 말라.

39. Consider making virtual functions nonpublic, and public functions nonvirtual.

라이브러리나 프레임워크에서 기반 클래스 내 변경에는 많은 비용이 든다. public 함수는 비 virtual로 만들어라. virtual 함수는 private로 만들거나 파생 클래스가 기반 버전을 불러야 할 필요가 있다면 protected로 만들어라.

40. Avoid providing implicit conversions.

모든 변화가 진보는 아니다. 묵시적 형변환은 자주 득보다 실이 많다. 묵시적 형변환을 제공할 때 정의하는 타입으로/으로부터 거듭 생각하라. 명시적 형변환에 의존하는 것을 선호하라 (명시적 생성자와 이름 붙은 변환 함수들을 통해)

41. Make data members private, except in behaviorless aggregates (C-style structs)

이들은 호출자의 일이 아니다. 데이터 멤버는 private로 하라. C-스타일 구조체 타입이 여러 값을 집합하고 행동을 주지 않거나 캡슐화하지 않는 경우에만 모든 데이터 멤버를 public으로 하라. public과 비public 데이터를 섞지 마라. 이는 거의 항상 잘못된 설계이다.

42. Don’t give away your internals.

너무 많이 자원봉사하지 말라. 클래스에 의해 관리되는 내부 데이터에 대한 핸들을 리턴하지 말라. 그래서 당신의 오브젝트가 그것이 소유한다고 생각하는 상태를 클라이언트가 제어 불가능하게 수정하도록 하지 말라.

43. Pimpl judiciously.

언어의 분리 염려를 이겨내라. C++은 private 멤버를 접근 불가능하게 하지만 보이지 않게 하지는 않는다. 이득이 허락할 때에는 private 멤버를 pimpl 이디엄을 이용해 컴파일러 방화벽을 구현하고 정보 은닉을 증가시킴으로써 보이지 않도록 하라.

44. Prefer writing nonmember nonfriend functions.

멤버십 사용료를 피하라. 가능하다면 함수를 비멤버 비프렌드로 하라.

45. Always provide new and delete together.

이는 패키지이다. 모든 클래스 특정 오버로드 void* operator new(parms)는 반드시 대응하는 오버로드 void operator delete(void*, parms)와 짝맞춰져야 한다. (여기서 parms는 첫 째가 반드시 std::size_t인 추가 매개변수 리스트이다. new[], delete[]에 대해서도 마찬가지다.

46. If you provide any class-specific new, provide all of the standard forms (plain, in-place, and nothrow)

좋은 new를 숨기지 마라. 클래스가 operator new의 임의의 오버로드를 정의한다면, 그것은 모든 plain, in-place, 비-예외 발생 operator new를 제공해야 한다. 그렇지 않다면 이들은 숨기져 있는 상태가 되며 클래스의 사용자에 사용 불가능하게 될 것이다.

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Google photo

Google의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

%s에 연결하는 중