C#의 객체 지향 디자인의 7가지 원칙 소개

1: 단일 책임 원칙(SRP)

1. 정의: 객체는 단일 책임만 포함해야 하며 책임은 클래스에 완전히 캡슐화됩니다.

　 또는: 클래스에 관한 한 책임은 하나만 있어야 합니다. 변화의 원인 중 하나.

2. 분석: 클래스(또는 모듈만큼 크거나 메서드만큼 작음)가 부담하는 책임이 많을수록 재사용 가능성이 낮아지고, 클래스가 너무 많은 책임을 맡으면 나누는 것과 같습니다. 이러한 책임이 결합되어 책임 중 하나가 변경되면 다른 책임의 운영에 영향을 미칠 수 있습니다. 클래스의 책임은 주로 데이터 책임과 행동 책임이라는 두 가지 측면을 포함합니다. 데이터 책임은 속성을 통해 반영되고, 행동 책임은 메서드를 통해 반영됩니다. 단일 책임 원칙은 높은 응집력과 낮은 결합도를 달성하기 위한 지침입니다. 이는 많은 코드 리팩토링 기술에서 찾을 수 있습니다. 이는 가장 간단하지만 적용하기 가장 어려운 원칙입니다. 클래스의 다양한 책임을 발견하려면 디자이너에게 강력한 분석 및 디자인 기능과 관련 리팩토링 경험이 필요합니다.

3. 예시:

설명 예시 Java 기반 C/S 시스템의 "로그인 기능"은 다음 로그인 클래스(Login)를 통해 구현됩니다.
이제는 단일 책임 원칙을 사용하여 재구성됩니다.

2: OCP(개방-폐쇄 원칙)

1. 정의: 소프트웨어 엔터티는 확장에는 개방적이고 수정에는 폐쇄적이어야 합니다. 즉, 모듈을 설계할 때 모듈을 수정하지 않고 확장해야 합니다. 즉, 소스 코드를 수정하지 않고도 모듈의 동작을 변경할 수 있습니다.

2. 분석: 열고 닫는 원리는 1988년 Bertrand Meyer가 제안했습니다. 이는 객체 지향 디자인에서 가장 중요한 원리 중 하나입니다. 개방-폐쇄 원칙의 정의에서 소프트웨어 엔터티는 소프트웨어 모듈, 여러 클래스로 구성된 부분 구조 또는 독립 클래스를 나타낼 수 있습니다. 추상화는 개방/폐쇄 원칙의 핵심입니다. 열기 및 닫기 원리는 보다 구체적인 "변형 캡슐화 원리"로 설명할 수도 있습니다. 변이 캡슐화 원리(EVP)에서는 시스템의 가변 요소를 찾아 캡슐화해야 합니다.

3: Liskov 대체 원리(LSP)

1. 정의: S 유형의 모든 객체 o1에 대해 T 유형의 객체 o2가 있는 경우 T로 정의된 모든 프로그램 P는 모든 객체 o1이 o2로 대체됩니다. , 프로그램 P의 동작이 변경되지 않으면 S 유형은 T

유형의 하위 유형입니다. 또는: 기본 클래스(부모 클래스)를 참조하는 모든 위치는 해당 하위 클래스를 투명하게 객체로 사용할 수 있어야 합니다.

2. 분석: 리스코프 대체 원리는 2008년 튜링상 수상자이자 미국 최초의 컴퓨터 과학 박사이자 MIT 교수이자 카네기 멜론 대학의 자넷 윙(Jeannette Wing) 교수가 1994년에 제안했습니다.

리스코프 대체 원칙은 대중적인 방식으로 표현될 수 있습니다. 소프트웨어에서 기본 클래스 개체를 사용할 수 있다면 해당 하위 클래스 개체도 사용할 수 있어야 합니다. 기본 클래스가 하위 클래스로 대체되면 프로그램은 오류나 예외를 생성하지 않습니다. 소프트웨어 엔터티가 하위 클래스를 사용하는 경우에는 기본 클래스를 사용하지 못할 수도 있습니다. Liskov 대체 원칙은 열기 및 닫기 원칙을 구현하는 중요한 방법 중 하나입니다. 하위 클래스 객체는 기본 클래스 객체가 사용되는 모든 곳에서 사용할 수 있으므로 기본 클래스 유형을 사용하여 프로그램에서 객체를 정의한 다음 런타임에 사용하십시오. . 하위 클래스 유형을 결정하고 상위 클래스 객체를 하위 클래스 객체로 바꿉니다.

4: 종속 역전 원칙(DIP)

1. 정의: 상위 수준 모듈은 하위 수준 모듈에 의존해서는 안 되며, 모두 추상화에 의존해야 합니다. 추상화는 세부 사항에 의존해서는 안 되며, 세부 사항은 추상화에 의존해야 합니다

　 또는: 구현이 아닌 인터페이스를 위한 프로그램입니다. (구현이 아닌 인터페이스에 대한 프로그램입니다.)

2. 분석: 종속성 역전 원리는 1996년 Robert C. Martin이 "C++ Reporter"를 위해 작성한 엔지니어링 노트북의 세 번째 열이며 나중에 그의 열에 추가되었습니다. 2002년 2016년 출간된 고전 저서 "애자일 소프트웨어 개발, 원칙, 패턴 및 관행"에서.​

​ 간단히 말해서 종속성 반전의 원칙은 다음을 의미합니다. 코드는 구체적인 클래스가 아닌 추상 클래스에 의존해야 하며, 프로그래밍은 구체적인 클래스를 위한 프로그래밍이 아닌 인터페이스 또는 추상 클래스를 위한 것이어야 합니다. 열기와 닫기 원리를 구현하는 핵심은 추상화이며, 구체적인 구현은 추상화에서 파생됩니다. 열기와 닫기 원리가 객체지향 설계의 목표라면 종속성 역전 원리는 객체지향 설계의 주요 수단입니다.

종속성 반전 원칙을 구현하는 일반적인 방법 중 하나는 코드에서 추상 클래스를 사용하고 구성 파일에 구체적인 클래스를 배치하는 것입니다.

클래스 간 결합

제로 결합 관계

구체적 결합 관계

추상적 결합 관계

종속성 역전 원칙은 클라이언트가 추상적 방식의 결합에 의존하도록 요구합니다. 종속성 역전 원칙의 핵심입니다.

종속성 주입

생성자 주입: 생성자를 통해 인스턴스 변수를 주입합니다.

Setter 주입: Setter 메서드를 통해 인스턴스 변수를 주입합니다.

인터페이스 주입: 인터페이스 메소드를 통해 인스턴스 변수를 주입합니다.

다섯 번째: 인터페이스 분리 원칙(ISP)

1. 정의: 클라이언트는 필요하지 않은 인터페이스에 의존해서는 안 됩니다. 이 정의의 인터페이스는 정의된 메서드를 참조합니다.

　 또는: 인터페이스가 너무 크면 더 작은 인터페이스로 나누어야 합니다. 인터페이스를 사용하는 클라이언트는 관련 방법만 알면 됩니다.

2. 분석: 인터페이스 격리 원칙은 단일 전체 인터페이스를 사용하는 대신 여러 특수 인터페이스를 사용하는 것을 의미합니다. 각 인터페이스는 상대적으로 독립적인 역할을 맡아야 하며, 하지 말아야 할 일을 해서는 안 되며, 해야 할 모든 일을 해야 합니다.

　(1) 인터페이스는 하나의 역할만 나타내며 각 역할에는 고유한 특정 인터페이스가 있습니다. 이 원칙을 "역할 격리 원칙"이라고 할 수 있습니다.

(2) 인터페이스는 클라이언트가 필요로 하는 동작, 즉 필수 메서드만 제공합니다. 클라이언트가 필요로 하지 않는 동작은 숨겨지므로 클라이언트에는 가능한 한 작은 별도의 인터페이스가 제공되어야 합니다. 큰 전체 인터페이스.

​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​ 에​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​ ​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​/​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​/​​​​​​​​​​​​​​​​​​​​ 인터페이스 외부는 단일 책임 원칙을 충족해야 하며, 인터페이스에서 관련 작업 집합을 정의해야 하며, 높은 응집력을 충족한다는 전제 하에 인터페이스의 메서드가 적을수록 좋습니다. 시스템을 설계할 때 맞춤형 서비스를 사용할 수 있습니다. 즉, 클라이언트마다 다른 너비의 인터페이스를 제공하고, 사용자에게 필요한 동작만 제공하고, 사용자에게 필요하지 않은 동작은 숨기는 등의 서비스를 사용할 수 있습니다.

Six: CRP(복합 재사용 원칙), CARP(합성/집합 재사용 원칙)

1. 정의: 복잡한 목적을 달성하기 위해 상속 대신 개체 조합을 사용해 보세요. (재사용 메커니즘은 상속보다 객체 구성을 선호합니다.)

2. 분석: 구성 및 재사용의 원칙은 연관 관계(조합 관계 및 집계 관계 포함)를 통해 일부 기존 객체를 새 객체에 사용하는 것을 의미합니다. 새 개체의 새 개체는 기존 개체의 메서드를 위임하고 호출하여 기존 기능을 재사용하려는 목적을 달성합니다. 즉, 구성/집계 관계를 최대한 많이 사용하고 상속 빈도를 줄이십시오.

객체 지향 설계에서는 두 가지 기본 방법, 즉 구성/집계 관계 또는 상속을 통해 기존 설계 및 구현을 다양한 환경에서 재사용할 수 있습니다.
상속 및 재사용: 구현이 간단하고 확장이 쉽습니다. 시스템의 캡슐화를 파괴합니다. 기본 클래스에서 상속된 구현은 정적이며 런타임에 변경할 수 없으며 제한된 환경에서만 사용할 수 있습니다. ("화이트 박스" 재사용)

구성/집계 재사용: 결합 정도가 상대적으로 낮고 멤버 개체의 작업이 선택적으로 호출되어 런타임에 동적으로 수행될 수 있습니다. ("블랙박스" 재사용)
결합/집계는 시스템을 더 유연하게 만들고, 클래스 간의 결합을 줄일 수 있으며, 한 클래스의 변경 사항이 다른 클래스에 미치는 영향이 상대적으로 적기 때문에 일반적으로 구현을 위해 조합/집계를 사용하는 것이 선호됩니다. 두 번째로 상속을 고려하십시오. 상속을 사용할 때는 Liskov 대체 원칙을 엄격히 따라야 합니다. 상속을 효과적으로 사용하면 문제를 이해하고 복잡성을 줄이는 데 도움이 되며, 상속을 남용하면 시스템 구축 및 유지 관리가 어려워집니다. 시스템이 복잡하기 때문에 상속 재사용은 주의해서 사용해야 합니다.

7: 최소 지식 원칙(LKP)이라고도 알려진 데메테르의 법칙(LoD)

1. 정의:

(1) "낯선 사람"과 대화하지 마세요. 영어로 정의하면 낯선 사람과 대화하지 마세요.

(2) 직접적인 친구하고만 대화하세요. 영어 정의는 다음과 같습니다. 직계 친구하고만 대화하세요.

(3) 각 소프트웨어 유닛은 다른 유닛에 대한 최소한의 지식을 가지며 해당 유닛과 밀접하게 관련된 소프트웨어 유닛으로 제한됩니다. 영어 정의는 다음과 같습니다. 각 단위는 다른 단위에 대해 제한된 지식만 가져야 합니다. 즉, 현재 단위와 "밀접하게" 관련된 단위만 알아야 합니다.

2. 분석: 데메테르의 법칙은 2019년 가을 미국 노스이스턴 대학의 연구에서 나왔습니다. 1987. "데메테르" 연구 프로젝트. 간단히 말해서, 데메테르의 법칙은 소프트웨어 엔터티가 다른 엔터티와 가능한 한 적게 상호 작용해야 함을 의미합니다. 이렇게 하면 하나의 모듈이 수정되면 다른 모듈에 영향을 최소화하고 확장이 상대적으로 쉬워집니다. 이는 소프트웨어 엔터티 간의 통신 폭과 깊이를 제한해야 합니다.

위 내용은 C#의 객체 지향 디자인의 7가지 원칙 소개의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!