이 글은 주로 합성, 집합, 재사용의 원리를 소개하는 내용인데, 편집자는 꽤 좋다고 생각해서 지금부터 공유하고 참고하겠습니다. 편집자를 따라가서 살펴보자
구성, 집합 및 재사용 원칙
구성 및 재사용 원칙을 CARP(구성/집계 재사용 원칙)라고도 하며 그 정의는 다음과 같습니다.
복합 재사용 원칙(CRP): 재사용을 위해 상속 대신 개체 조합을 사용해 보세요.
합성 및 재사용의 원칙은 연관 관계(조합 관계 및 집계 관계 포함)를 통해 새 개체의 일부 기존 개체를 사용하여 새 개체의 일부로 만드는 것입니다. 위임 방법을 통해 기존 개체를 호출합니다. 기능을 재사용하는 목적. 간단히 말해서: 재사용 시 조합/집계 관계(연관 관계)를 사용하고 상속을 덜 사용하도록 노력하세요.
객체 지향 설계에서는 구성/집계 관계 또는 상속을 통해 두 가지 방법으로 다양한 환경에서 기존 설계 및 구현을 재사용할 수 있지만 먼저 구성/집계, 구성/집계 사용을 고려해야 합니다. 시스템이 더 유연해지고 클래스 간의 결합이 줄어듭니다. 상속은 다음으로 고려되어야 합니다. 상속을 사용하는 경우에는 Liskov 대체 원칙을 엄격하게 따라야 합니다. 문제를 이해하고 복잡성을 줄이는 데 도움이 되는 반면, 상속을 남용하면 시스템 구축 및 유지 관리의 어려움과 시스템의 복잡성이 증가하므로 상속 재사용은 주의해서 사용해야 합니다.
상속을 통한 재사용의 주요 문제점은 상속 재사용이 시스템의 캡슐화를 파괴한다는 것입니다. 왜냐하면 상속은 기본 클래스의 구현 세부사항을 서브클래스에 노출시키기 때문입니다. 왜냐하면 기본 클래스의 내부 세부사항은 일반적으로 서브클래스에서 볼 수 있기 때문입니다. 따라서 이러한 종류의 재사용을 "화이트 박스" 재사용이라고도 합니다. 기본 클래스가 변경되면 하위 클래스의 구현도 변경되어야 하며 기본 클래스에서 상속된 구현은 정적이므로 런타임 변경 시 변경할 수 없습니다. , 유연성이 충분하지 않으며 상속은 제한된 상황(예: 상속되지 않는 것으로 선언되지 않은 클래스)에서만 사용할 수 있습니다.
Extension
상속에 대한 심층적인 이해를 위해서는 "Software Architecture Design"이라는 책의 저자인 Mr. Wen Yu의 글을 참조하세요. 상속" .
조합 또는 집계 관계는 기존 개체(구성원 개체라고도 함)를 새 개체에 통합하여 새 개체의 일부로 만들 수 있으므로 새 개체는 기존 개체의 기능을 호출할 수 있습니다. 구성원 객체는 새 객체에 표시되지 않으므로 이러한 종류의 재사용을 "블랙박스" 재사용이라고도 합니다. 상속 관계에 비해 결합 정도가 상대적으로 낮고 구성원 객체의 변경 사항이 새 객체에 거의 영향을 미치지 않습니다. 멤버 개체의 작업은 실제 필요에 따라 새 개체에서 선택적으로 호출될 수 있습니다. 합성 재사용은 런타임에 동적으로 수행될 수 있으며 새 개체는 멤버 개체와 동일한 유형의 다른 개체를 동적으로 참조할 수 있습니다.
일반적으로 두 클래스 간의 관계가 "Has-A"인 경우 합성 또는 집합을 사용해야 하고 관계가 "Is-A"인 경우 상속 을 사용할 수 있습니다. "Is-A"는 엄격한 분류학적 정의입니다. 즉, 한 클래스가 다른 클래스의 "일종"이라는 의미입니다. "Has-A"는 다릅니다. 이는 특정 역할에 특정 책임이 있음을 의미합니다.
다음은 합성과 재사용의 원리에 대한 이해를 깊게 하기 위한 간단한 예입니다.
CRM 시스템의 초기 설계에서 Sunny Software Company의 개발자들은 고객 수가 많지 않으며 시스템은 데이터베이스 작업과 관련된 데이터베이스로 MySQL을 사용했습니다. CustomerDAO 클래스와 같은 클래스는 데이터베이스에 연결해야 합니다. getConnection() 메서드 이후 데이터베이스에 연결하기 위한 메서드가 캡슐화됩니다. DBUtil 클래스를 재사용해야 하기 때문에 디자이너는 CustomerDAO를 DBUtil 클래스의 하위 클래스로 사용합니다. 초기 디자인 구조 그림 1에 표시된 대로:
그림 1 초기 디자인 계획 구조 다이어그램
고객 수에 따라 시스템은 Oracle 데이터베이스로 업그레이드하기로 결정했으므로 Oracle 데이터베이스에 연결하려면 새로운 OracleDBUtil 클래스를 추가해야 합니다. 따라서 초기 설계 계획에서는 CustomerDAO와 DBUtil 간에 상속 관계가 있습니다. 데이터베이스 연결 방법을 변경하려면 CustomerDAO 클래스의 소스 코드를 수정하고 CustomerDAO를 OracleDBUtil의 하위 클래스로 사용해야 합니다. 이는 열기 및 닫기 원칙에 위배됩니다. [물론 DBUtil 클래스의 소스 코드를 수정할 수도 있는데, 이는 열기 및 닫기 원칙에도 위배됩니다. ]
이제 합성과 재사용의 원리를 이용해 재구성됩니다.
합성 재사용의 원칙에 따라 재사용을 구현할 때 더 많은 연관을 사용하고 더 적은 상속을 사용해야 합니다. 따라서 이 예에서는 연관 재사용을 사용하여 상속 재사용을 대체할 수 있습니다. 재구성된 구조는 그림 2에 나와 있습니다.
그림 2 재구성된 구조 다이어그램
그림 2에서는 CustomerDAO와 DBUtil의 관계가 상속에서 연관으로 변경됩니다. 종속성 주입은 DBUtil 개체를 CustomerDAO에 주입하는 데 사용됩니다. DBUtil의 기능을 확장해야 하는 경우 하위 클래스 OracleDBUtil을 통해 Oracle 데이터베이스에 연결하는 등 해당 하위 클래스를 통해 확장할 수 있습니다. CustomerDAO는 Liskov 대체 원칙에 따라 DBUtil용으로 프로그래밍되었으므로 DBUtil 하위 클래스의 개체는 DBUtil 개체를 덮어쓸 수 있으며 하위 클래스에서 확장된 메서드를 사용하려면 하위 클래스 개체를 CustomerDAO에 삽입하기만 하면 됩니다. 예를 들어, OracleDBUtil 개체를 CustomerDAO에 주입하면 Oracle 데이터베이스 연결을 실현할 수 있으며 원본 코드를 수정할 필요가 없으며 새로운 데이터베이스 연결 방법을 유연하게 추가할 수 있습니다.
위 내용은 Java의 구성, 집계 및 재사용 원칙에 대한 자세한 그래픽 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!