이러한 원칙을 엄격하게 준수할 필요는 없으며 이를 위반해도 종교적 처벌을 받지 않습니다. 하지만 이 원칙 중 하나라도 어기면 경고음이 울린다고 생각해야 합니다. ----- Arthur J.Riel
(1) 모든 데이터는 해당 클래스 내에 숨겨야 합니다.
(2) 클래스의 사용자는 클래스의 공유 인터페이스에 의존해야 하지만, 클래스는 사용자에게 의존할 수 없습니다.
(3) 클래스 프로토콜의 메시지를 최소화합니다.
(4) 모든 클래스가 이해하는 가장 기본적인 공용 인터페이스를 구현합니다[예: 복사 작업(전체 복사 및 얕은 복사), 동일성 판단, 올바른 출력 내용, ASCII 설명 구문 분석 등].
(5) 구현 세부 사항(예: 공유 코드를 배치하는 비공개 함수)을 클래스의 공개 인터페이스에 넣지 마세요.
클래스의 두 메서드에 공통 코드가 있는 경우 해당 공통 코드를 방지하는 전용 함수를 만들 수 있습니다.
(6) 사용자가 사용할 수 없거나 관심이 없는 것으로 클래스의 공개 인터페이스를 방해하지 마십시오.
(7) 클래스 사이에는 결합이 없거나 파생된 결합 관계만 있어야 합니다. 즉, 한 클래스는 다른 클래스와 아무 관련이 없거나 다른 클래스의 공용 인터페이스에서만 작업을 사용합니다.
(8) 클래스는 하나의 핵심 추상화만을 나타내야 합니다.
동일한 유형의 속성이 변경되면 패키지의 모든 클래스를 공동으로 닫아야 합니다. 변경 사항이 패키지에 영향을 미치는 경우 패키지의 모든 클래스에 영향을 주지만 다른 패키지에는 영향을 미치지 않습니다.
(9) 관련 데이터 및 동작을 중앙 집중화합니다.
디자이너는 get과 같은 작업을 통해 다른 개체에서 데이터를 얻는 개체에 대해 알고 있어야 합니다. 이러한 유형의 행동은 이러한 경험적 원칙이 위반되었음을 의미합니다.
(10) 관련없는 정보는 다른 카테고리에 넣습니다(즉, 서로 소통하지 않는 행위).
(11) 모델링하는 추상 개념이 객체가 수행하는 역할이 아닌 클래스인지 확인하세요
.
(12) 시스템 기능을 수평 방향으로 최대한 균일하게 분배합니다. 즉, 설계에 따라 최상위 클래스는 작업을 균일하게 공유해야 합니다.
(13) 시스템에 전능한 클래스/객체를 생성하지 마십시오. 이름에 Driver, Manager, System 및 Susystem이 포함된 클래스에는 특히 주의하세요.
인터페이스를 구현하기보다는 인터페이스를 계획하세요.
(14) 공용 인터페이스에서 많은 수의 액세스 방법을 정의하는 클래스에 주의하십시오. 액세스 방법이 많다는 것은 관련 데이터와 행동이 중앙에 저장되지 않는다는 것을 의미합니다.
(15) 서로 소통하지 않는 동작이 너무 많은 클래스에는 주의하세요.
이 문제의 또 다른 징후는 애플리케이션 클래스의 공개 인터페이스에 많은 get 및 set 함수를 생성하는 것입니다.
(16) 사용자 인터페이스와 상호작용하는 객체지향 모델로 구성된 애플리케이션에서 모델은 인터페이스에 의존해서는 안 되지만, 인터페이스는 모델에 의존해야 한다.
(17) 최대한 현실 세계에 맞춰 모델링한다(우리는 시스템 기능 분배 원칙을 준수하고, 다목적 클래스 원칙을 피하고, 관련 데이터와 행위를 중앙에 배치하기 위해 이 원칙을 위반하는 경우가 많다).
(18) 디자인에서 불필요한 클래스를 제거하십시오.
일반적으로 우리는 이 클래스를 속성으로 다운그레이드합니다.
(19) 시스템 외부의 클래스를 제거합니다.
시스템 외부 클래스의 특징은 추상적인 용어로 시스템 도메인에만 메시지를 보내고 시스템 도메인에 있는 다른 클래스의 메시지는 받아들이지 않는다는 것입니다.
(20) 작업을 클래스로 전환하지 마십시오. 이름이 동사이거나 동사에서 파생된 클래스, 특히 하나의 의미 있는 동작만 있는 클래스에 질문하세요. 의미 있는 동작을 이미 존재하거나 아직 발견되지 않은 클래스로 이동해야 하는지 고려하세요.
(21) 우리는 애플리케이션 분석 모델을 생성할 때 프록시 클래스를 자주 도입합니다. 설계 단계에서 우리는 많은 에이전트가 쓸모가 없어 제거되어야 한다는 사실을 종종 발견합니다.
(22) 학급의 협력자 수를 최소화하십시오.
한 클래스에서 사용하는 다른 클래스의 수는 최소한으로 유지해야 합니다.
(23) 학급과 협력자 간에 전달되는 메시지 수를 최소화합니다.
(24) 학급과 협력자 간의 협업 양을 최소화합니다. 즉, 학급과 협력자 간에 전달되는 다양한 메시지의 수를 줄입니다.
(25) 클래스의 팬아웃(fan-out)을 최소화한다. 즉, 클래스에서 정의한 메시지 수와 전송된 메시지 수의 곱을 줄인다.
(26) 클래스에 다른 클래스의 객체가 포함되어 있으면 포함 클래스는 포함된 객체에 메시지를 보내야 합니다. 즉, 포함 관계는 항상 사용 관계를 의미합니다.
(27) 클래스에 정의된 대부분의 메소드는 대부분의 데이터 멤버를 대부분 사용해야 합니다.
(28) 클래스에 포함된 객체의 수는 개발자의 단기 기억 용량을 초과해서는 안 됩니다. 이 숫자는 종종 6입니다.
클래스에 6개 이상의 데이터 멤버가 포함된 경우 논리적으로 관련된 데이터 멤버를 그룹으로 나눈 다음 새 포함 클래스를 사용하여 이 멤버 그룹을 포함할 수 있습니다.
(29) 좁고 깊은 상속 시스템에서 시스템 기능을 수직적으로 분산시키자.
(30) 의미론적 제약을 구현할 때는 클래스 정의에 따라 구현하는 것이 가장 좋습니다. 이는 종종 클래스 오버플로로 이어지며, 이 경우 제약 조건은 클래스의 동작에서 구현되어야 하지만 일반적으로 생성자에서 반드시 구현될 필요는 없습니다.
(31) 클래스 생성자에서 의미론적 제약을 구현할 때, 생성자의 도메인에서 허용하는 가장 깊은 포함 수준에 제약 테스트를 배치합니다.
(32) 제약 조건이 의존하는 의미 정보가 자주 변경되는 경우 중앙 집중화된 타사 개체에 넣는 것이 가장 좋습니다.
(33) 제약 조건이 의존하는 의미 정보가 거의 변경되지 않으면 제약 조건과 관련된 클래스 간에 가장 잘 배포됩니다.
(34) 클래스는 자신이 무엇을 담고 있는지 알아야 하지만, 누가 그것을 담고 있는지는 알 수 없습니다.
(35) 리터럴 범위를 공유하는(즉, 동일한 클래스에 포함된) 객체는 서로 사용 관계를 가져서는 안 됩니다.
(36) 상속은 전문화 계층을 모델링하는 데에만 사용되어야 합니다.
(37) 파생 클래스는 기본 클래스에 대해 알아야 하며, 기본 클래스는 파생 클래스에 대한 어떤 정보도 알면 안 됩니다.
(38) 기본 클래스의 모든 데이터는 비공개여야 하며 보호된 데이터를 사용하지 마세요.
클래스 디자이너는 클래스 사용자에게 필요하지 않은 것을 공용 인터페이스에 넣어서는 안 됩니다.
(39) 이론적으로 상속 계층 구조는 더 깊을수록 좋습니다.
(40) 실제로 상속 계층의 깊이는 일반인의 단기 기억 용량을 초과해서는 안 됩니다. 널리 사용되는 깊이 값은 6입니다.
(41) 모든 추상 클래스는 기본 클래스여야 합니다.
(42) 모든 기본 클래스는 추상 클래스여야 합니다.
(43) 상속 계층 구조에서 데이터, 동작 및/또는 인터페이스 공통성을 최대한 높게 배치합니다.
(44) 두 개 이상의 클래스가 공통 데이터를 공유하는 경우(그러나 공통 동작은 없음), 공통 데이터는 이 데이터를 공유하는 각 클래스에 포함된 클래스에 배치되어야 합니다.
(45) 두 개 이상의 클래스가 공통 데이터와 동작(즉, 메서드)을 갖는 경우, 이러한 각 클래스는 이러한 데이터와 메서드를 나타내는 공통 기본 클래스에서 상속되어야 합니다.
(46) 두 개 이상의 클래스가 공통 인터페이스(메소드가 아닌 메시지 참조)를 공유하는 경우 다형적으로 사용해야 하는 경우에만 공통 기본 클래스에서 상속해야 합니다.
(47) 객체 유형 표시에 대한 사례별 분석은 일반적으로 잘못되었습니다. 대부분의 경우 디자이너는 다형성을 사용해야 합니다.
(48) 속성 값 표시에 대한 사례별 분석이 잘못된 경우가 많습니다. 클래스는 상속 계층 구조로 분리되어야 하며 각 속성 값은 파생 클래스로 변환되어야 합니다.
(49) 상속 관계를 통해 클래스의 동적 의미를 모델링하지 마십시오. 정적 의미 관계를 사용하여 동적 의미를 모델링하려고 하면 런타임 시 유형이 전환됩니다.
(50) 클래스 객체를 파생 클래스로 바꾸지 마십시오. 인스턴스가 하나만 있는 파생 클래스에는 주의하세요.
(51) 런타임에 새 클래스를 생성해야 한다고 생각한다면 한발 물러서서 객체를 생성하고 있다는 사실을 인식하세요. 이제 이러한 개체를 클래스로 일반화합니다.
(52) 기본 클래스의 메서드를 재정의하기 위해 파생 클래스의 빈 메서드(즉, 아무것도 하지 않는 메서드)를 사용하는 것은 불법이어야 합니다.
(53) 선택적 포함과 상속의 필요성을 혼동하지 마십시오. 선택적 포함을 상속으로 모델링하면 클래스가 급증하게 됩니다.
(54) 상속 계층을 생성할 때 재사용 가능한 구성 요소보다는 재사용 가능한 프레임워크를 생성하도록 노력하십시오.
(55) 디자인에 다중 상속을 사용했다면 실수를 했다고 가정하세요. 실수를 하지 않았다면 그것을 증명하려고 노력해야 합니다.
(56) 객체 지향 설계에서 상속이 사용될 때마다 스스로에게 두 가지 질문을 하십시오. (1) 파생 클래스가 상속받은 클래스의 특별한 유형입니까? (2) 기본 클래스가 파생 클래스의 일부입니까?
(57) 객체지향 설계에서 다중 상속을 발견했다면, 기본 클래스가 실제로 다른 기본 클래스의 파생 클래스가 아닌지 확인하세요.
(58) 객체지향 설계에서 포함과 연관 중 하나를 선택해야 한다면 포함을 선택하세요.
(59) 클래스 객체의 기록을 위해 전역 데이터나 전역 함수를 사용하지 마세요. 클래스 변수나 클래스 메서드를 사용해야 합니다.
(60) 객체 지향 설계자는 물리적 설계 원칙이 논리적 설계를 훼손하도록 해서는 안 됩니다. 그러나 논리적 설계에 대한 결정을 내릴 때 물리적 설계 기준을 사용하는 경우가 많습니다.
(61) 객체의 상태를 수정하기 위해 공개 인터페이스를 우회하지 마십시오.