Java에서 OO의 개념과 디자인 원리에 대한 간략한 소개(컬렉션)

아래 편집자는 Java의 OO 개념과 디자인 원칙(필독)을 간략하게 설명하는 기사를 가져올 것입니다. 에디터가 꽤 좋다고 생각해서 지금 공유해서 참고용으로 올려보겠습니다. 편집자를 따라가서 살펴보자

1. OO(객체지향)

객체지향(OO)의 디자인 기반: 객체개념, 객체중심, 클래스 및 상속구축 메커니즘은 인터페이스와 다형성을 최대한 활용하여 객관적 세계를 인식, 이해, 특성화하고 해당 소프트웨어 시스템을 설계하고 구축할 수 있는 유연성을 제공합니다. 객체지향 기능: 다양한 객체지향 프로그래밍 언어 ​​ 는 서로 다르지만 모두 객체지향의 기본 기능인

즉 "추상화"를 지원한다고 볼 수 있습니다. , 캡슐화, 상속, 다형성”:

– 추상화, 세부 사항을 먼저 고려하지 마세요
– 캡슐화, 내부 구현 숨기기
– 상속, 기존 코드 재사용
– 다형성, 객체 다시 작성 행동

객체 지향

디자인 패턴: "좋은 객체 지향 디자인"입니다. 소위 "좋은 객체 지향 디자인"은 " 변화에 대응하고 재사용을 개선합니다." 객체지향 디자인 패턴은 소프트웨어 디자인을 기술하므로 프로그래밍 언어와는 독립적입니다. 그러나 객체지향 디자인 패턴의 최종 구현은 여전히 ​​객체지향 프로그래밍 언어를 사용하여 표현되어야 합니다. 객체지향 디자인 패턴은 복사해서 사용할 수 있는 알고리즘 기법과 달리 '객체지향'에 대한 능숙하고 심층적인 이해를 바탕으로 한 경험적 이해입니다.

위에서는 객체지향 패턴과 디자인 패턴 간의 개념과 관계를 폭넓게 설명합니다. 우리는 디자인할 때 OO의 4가지 기본 특성을 충분히 이해하고 활용하여 디자인을 개발합니다. 따라서 디자인하기 전에 모든 사람이 객체지향 기술을 숙지하고 숙달해야 합니다. 여기서는 디자인 패턴에 대해 자세히 소개하지 않겠습니다. 디자인할 때 참조

모델을 제공하고, 객체지향 디자인 패턴을 마스터하기 위한 전제조건은 먼저 "객체지향" 기술을 마스터하는 것입니다.

2. OO(객체지향) 설계 목표

※확장성: 새로운 요구 사항이 있으면 새로운 성능을 쉽게 추가할 수 있지만 기존 성능을 저하시키거나 시스템에 새로운 결함을 가져옵니다.

※수정 유연성: 시스템 일부의 코드를 수정해도 기존 시스템 구조가 파괴되지 않으며 시스템에 영향을 미치지 않습니다. 기타 부분.

※교체성 플러그성: 시스템의 일부 코드는 시스템에 영향을 주지 않고 동일한 인터페이스를 가진 다른 클래스로 대체될 수 있습니다.

3. OO 디자인의 5대 원칙과 그 관계

3.1 OO 디자인 원칙 요약

※단일 책임 원칙:클래스의 변경 이유는 단 하나여야 합니다. 독신은 수업을 위한 좋은 디자인입니다. 혼합되고 불분명한 책임은 코드를 특히 어색하게 만들고, 전체 본문에 영향을 미치고, 미학을 잃고 필연적으로 추악한 시스템 오류의 위험으로 이어집니다.

※개방-폐쇄 원칙: 은 소프트웨어 엔터티(클래스, 모듈, 함수 등)가 확장 가능하지만 수정이 불가능해야 함을 의미합니다. . 개방형과 폐쇄형 원리를 구현하는 핵심 아이디어는 추상화가 상대적으로 안정적이기 때문에 구체적으로 프로그래밍하기보다는 추상적으로 프로그래밍하는 것입니다. 클래스가 고정된 추상화에 의존하도록 하여 수정이 닫히도록 하고 객체 지향 상속 및 다형성 메커니즘을 통해 추상 클래스를 상속하고 해당 메서드를 재정의하여 고유 동작을 변경할 수 있습니다. , 그래서 열려 있습니다. "요구사항은 항상 변한다"고 변하지 않는 소프트웨어는 없기 때문에 요구 사항을 충족하기 위해 변경 사항을 닫는 폐쇄형 및 개방형 원칙을 사용하는 동시에 소프트웨어 내에서 패키징 시스템의 안정성을 유지하고 변경 사항에 영향을 받지 않는 것이 필요합니다. 요구 사항.

※종속성 역전 원칙: 구체성에 의존하지 말고 추상화에 의존하세요. 추상화의 안정성은 시스템의 안정성을 결정합니다. 왜냐하면 추상화는 불변이고 추상화에 대한 의존성은 객체 지향 설계의 본질이자 종속성 역전 원칙의 핵심이기 때문입니다. 추상화에 의존하는 것이 일반적인 원칙이지만 때로는 세부 사항에 의존하는 것이 불가피할 때도 있습니다. 추상화와 구체성 사이의 균형을 고려해야 하며 방법이 고정되어 있지 않습니다. 추상화에 의존한다는 것은 구현이 아니라 인터페이스를 프로그래밍하는 것을 의미합니다.

※리스코프 대체 원칙: 하위 유형은 상위 유형으로 대체될 수 있어야 합니다. Liskov 대체 원칙은 주로 상속을 기반으로 추상화 및 다형성을 구축하는 데 중점을 둡니다. 따라서 Liskov 대체 원칙을 준수해야만 상속 재사용이 안정적으로 보장될 수 있습니다. 구현 방법은 인터페이스 지향 프로그래밍입니다. 공용 부분을 기본 클래스 인터페이스 또는 추상 클래스로 추상화하고, ExtractAbstractClass를 사용하고, 상위 클래스를 재정의하여 하위 클래스에 새 메서드를 구현합니다. 동일한 책임을 지원하는 방법입니다. Liskov 대체 원칙은 시스템의 확장성을 보장하는 동시에 다형성을 기반으로 한 추상화 메커니즘을 구현하여 코드 중복을 줄이고 런타임 중에 유형 차별을 피할 수 있습니다.

※인터페이스 격리 원칙: 하나의 일반 인터페이스보다 고객 관련 인터페이스가 여러 개 있는 것이 좋습니다. 분리에는 두 가지 주요 방법이 있습니다. 1. 위임 분리. 클라이언트의 요청을 위임하는 새로운 유형을 추가하여 클라이언트와 인터페이스의 직접적인 종속성을 분리하지만 시스템 오버헤드가 증가합니다. 2. 다중 상속을 분리하고 인터페이스 다중 상속을 통해 고객 요구를 실현하는 방법이 더 좋습니다.

다음은 이전에 언급되지 않은 두 가지 원칙이며, 디자인 시 고려해야 할 중요한 원칙이기도 합니다.

※데밋의 법칙: 서로 직접 소통하지 않는 클래스 간에는 직접 소통하지 마세요. 두 클래스가 서로 직접 통신할 필요가 없다면 두 클래스는 직접 상호 작용하면 안 됩니다. 클래스가 클래스의 메서드를 호출해야 하는 경우 해당 호출은 제3자를 통해 전달될 수 있습니다. 데메테르의 법칙이 강조하는 첫 번째 전제는 클래스 설계에 있어서 각 클래스는 멤버의 접근권한을 최소화해야 한다는 것이다. 기본 아이디어는 클래스 간의 느슨한 결합을 강조하는 것입니다.

※합성/집계재사용 원칙: 합성/집계를 최대한 사용하고 상속은 사용하지 않도록 하세요. 구성(Com위치)과 집계(Aggregation)는 모두 약한 소유권 관계를 나타냅니다. 구성은 엄격한 부분과 전체 관계를 구현하는 강력한 소유권 관계입니다. 동일한 수명주기. 구성 또는 집계 원칙을 선호하면 각 클래스를 캡슐화하고 단일 작업에 집중하는 데 도움이 됩니다. 이렇게 하면 클래스와 클래스 상속 계층이 작게 유지되고 통제할 수 없는 거대 규모로 성장할 가능성이 줄어듭니다

3.2 OO 디자인 원칙의 관계

1. "개방-폐쇄" 원칙(OCP)을 실현하는 핵심 단계는 추상화입니다. 기본 클래스와 하위 클래스 간의 상속 관계는 추상화를 반영합니다. 따라서 Liskov 대체 원칙은 추상화를 달성하기 위한 특정 단계의 사양입니다. Liskov 대체 원칙을 위반한다는 것은 "개방-폐쇄" 원칙을 위반하는 것을 의미하지만 반드시 그 반대일 필요는 없습니다.

2. '개방-폐쇄' 원칙과 종속역전원리(DIP)는 목표와 수단의 관계입니다. 열림과 닫힘의 원리가 목적이라면, 의존역전의 원리는 '열림과 닫힘'의 원리를 달성하기 위한 수단이다. 최상의 "열기 및 닫기" 원칙을 달성하려면 종속성 반전 원칙을 최대한 준수해야 합니다. 종속성 반전 원칙은 "추상화"에 대한 최상의 사양입니다.

3. 리스코프 대체 원리(LSP)는 의존성 역전 원리의 기초이며, 의존성 역전 원리는 리스코프 대체 원리의 중요한 보충입니다.

4. 인터페이스 분리 원칙(ISP)도 "개방-폐쇄" 원칙을 보장하는 중요한 수단입니다.

5. 단일 책임 원칙(SRP)에 대해서는 개인적으로 책임이 단순할수록 구현하기 쉬운 것이 가장 좋다고 생각합니다. close" 및 Liskov 대체.

4. OO 디자인 원칙과 목표의 관계

1. 확장성: 이전 클래스를 동일한 인터페이스로 대체할 수 있는 새로운 클래스를 허용합니다. 추상 인터페이스를 재사용하는 것입니다. 클라이언트는 구체적인 구현 클래스가 아닌 추상 인터페이스에 의존하므로 이 구체적인 클래스는 클라이언트에 영향을 주지 않고 다른 구체적인 클래스로 대체될 수 있습니다. 다음 원칙은 확장성을 가능하게 합니다.

※개방형/폐쇄형 원칙
※리히터 치환 원칙
※의존성 역전 원칙
※합성/집계 재사용 원칙

2. 수정 유연성: 모듈은 상대적으로 독립적이며 통신이 최소화됩니다. 이런 방식으로 한 모듈을 수정해도 다른 모듈에는 거의 영향을 미치지 않습니다.

다음 원칙에 따라 수정이 가능합니다.

※개방/폐쇄 원칙
※데메테르의 법칙
※인터페이스 격리 원칙

3. 대체성 플러그 가능성: 1개 부품일 때 더 이상 요구 사항을 충족하지 못하는 경우 기존 부품을 빼내고 새 부품을 삽입할 수 있습니다.

교체성을 실현하는 원칙은 다음과 같습니다.

※개방형/폐쇄형 원칙
※리히터 치환 원칙
※의존성 역전 원칙
※합성/집계 재사용 원칙

5 ． OO(객체지향) 디자인 프로세스

1. 스타일을 분석하고 기능을 분류한다.

2. 함수 기반 추상 클래스.

※ 클래스 추상화 - 이 단계에서는 "단일 책임 원칙"을 기반으로 클래스의 구체적인 추상화를 수행할 수 있습니다. 클래스의 기능을 간단하고 명확하게 만드십시오.

※ 캡슐화 변경점 – 캡슐화를 사용하여 객체 사이에 경계층을 생성하면 디자이너는 반대쪽에 바람직하지 않은 영향을 주지 않고 경계층의 한쪽을 수정할 수 있습니다. 레이어 간의 느슨한 결합을 달성합니다.

3. 추상 기본 클래스와 인터페이스 클래스를 디자인합니다.

※ 기본 기본 클래스를 추상화하고 인터페이스를 정의할 때 "인터페이스 분리 원칙"을 준수하여 인터페이스를 추상화해야 합니다.

※ 인터페이스 및 기본 클래스를 디자인할 때 항상 세부 사항에 주의하지 마세요. 구현이 아닌 인터페이스를 위한 프로그래밍을 하세요.

※ 추상 기본 클래스와 파생 클래스 간에는 "리히터 대체 원칙"의 요구 사항을 충족해야 합니다.

4. 클래스 간의 결합 관계를 결정합니다.

4.1 결합도를 판단하는 기준은 무엇인가요?

※ 간단히 말하면 수요의 안정성에 따라 결합 정도가 결정됩니다.

※ 안정성이 높고 변경하기 어려운 요구사항의 경우 다양한 유형을 완벽하게 결합하여 효율성을 향상시킬 수 있으며 더 나은 기술을 사용하여 효율성을 향상시킬 수도 있습니다. 코드를 단순화하세요.

※ 요구 사항이 변경될 가능성이 매우 높은 경우에는 클래스 간의 결합 문제를 충분히 고려해야 하며 결합 정도를 줄이기 위한 다양한 방법을 고안할 수 있지만 요약하면 이에 지나지 않습니다. 증가 추상화 수준은 다양한 클래스를 격리하는 데 사용됩니다. 이 추상화 수준은 추상 클래스, 구체적인 클래스, 인터페이스 또는 클래스 그룹일 수 있습니다. 커플링을 줄이는 아이디어는 "구현을 위한 프로그래밍이 아닌 인터페이스를 위한 프로그래밍.

※ 클래스의 커플링 관계를 결정할 때 "디미터의 법칙"과 "합성"을 고려해보세요. / Aggregation Reuse 원칙".

4.2 종속성 역전을 달성하는 방법은 무엇입니까?

※ 추상적인 방식으로 결합하는 것이 종속성 역전의 핵심입니다. 원칙. 추상 결합 관계에는 항상 추상 클래스에서 상속되는 구체적인 클래스가 포함되며 기본 클래스에 대한 모든 참조가 해당 하위 클래스로 변경될 수 있도록 보장해야 합니다. 따라서 Liskov 대체 원칙은 종속성 반전 원칙입니다.

※ 추상화에 의존: 구체적인 클래스에 의존하지 않는 것이 좋습니다. 즉, 프로그램의 모든 종속성은 추상 클래스나 인터페이스에서 종료되어야 합니다.

(1)

변수 는 구체적인 클래스에 대한 포인터나 참조를 보유해서는 안 됩니다. (2) 어떤 클래스도 구체적인 클래스에서 파생되어서는 안 됩니다. 구체적인 클래스. 기본 클래스에서 구현된 메서드를 재정의하면 안 됩니다.

5. OO 디자인의 5가지 원칙을 사용하여 디자인을 더욱 최적화하세요. ※ 클래스의 추상화 및 기능은 "단일 책임 원칙"을 만족하는지

※ 상속 관계 및 기본 클래스에 대한 참조는 "리스코프 대체 원칙" 및 "의존성 역전"을 만족하는지 원칙"

※ 인터페이스 및 기본 클래스의 경우 "인터페이스 격리 원칙" 충족 여부
※ 일반적으로 "개폐 원칙" 충족 여부


일반적으로 디자인할 때 객체지향 디자인에서는 디자인의 5대 원칙을 충분히 고려하되, 이를 고집해서는 안 됩니다. 맹목적으로 만족을 추구하는 것은 디자인된 시스템의 성능과 자원을 소모하는 결과를 낳을 수도 있습니다. 상황에 따라 디자인 진행 가능합니다.

위 내용은 Java에서 OO의 개념과 디자인 원리에 대한 간략한 소개(컬렉션)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!