PHP의 객체지향 원칙 소개

소프트웨어를 매우 유연하고 유지 관리하기 쉽게 만드는 것은 매우 어렵습니다. 유연한 소프트웨어는 구조가 복잡하고 유지 관리가 어렵습니다. 이익과 손실이 있으며, 손실이 손실보다 크도록 이 둘을 어떻게 처리하느냐가 관건입니다. 소프트웨어의 설계 및 개발은 다음 6가지 원칙을 따라야 합니다.
1. OCP
전체 이름: "개방 폐쇄 원칙" 개방 폐쇄 원칙
설명: 확장에는 개방, 수정에는 폐쇄.
장점: OCP 원칙에 따라 설계된 시스템은 프로그램의 다양한 부분 간의 결합을 줄이고 적응성, 유연성 및 안정성이 비교적 좋습니다. 기존 소프트웨어 시스템에 새로운 기능을 추가해야 할 때 시스템의 기반이 되는 추상화 계층을 수정할 필요가 없습니다. 추가해야 하는 기능을 구현하려면 원래 기반에 새로운 모듈만 추가하면 됩니다. . 추가된 새 모듈은 원래 모듈에 전혀 영향을 미치지 않거나 거의 영향을 미치지 않으므로 원래 모듈을 다시 테스트할 필요가 없습니다.
"개방-폐쇄" 원칙을 구현하는 방법
객체 지향 설계에서 변경이 허용되지 않는 것은 시스템의 추상화 계층이지만 확장이 허용되는 것은 시스템의 구현 계층입니다. 즉, 구현 계층에서 가능한 한 많은 동작을 구현할 수 있도록 하는 일회성 추상화 설계 계층을 정의합니다.
문제 해결의 열쇠는 객체지향 디자인의 첫 번째 핵심 본질인 추상화에 있습니다.
무언가를 추상화한다는 것은 본질적으로 그 본질을 요약하는 것입니다. 추상화를 통해 우리는 가장 중요한 것을 파악하고 더 높은 수준에서 생각할 수 있습니다. 이렇게 하면 사고의 복잡성이 줄어들고 동시에 너무 많은 것을 생각할 필요가 없습니다. 즉, 우리는 사물의 본질을 캡슐화하고 세부 사항을 볼 수 없습니다.
객체 지향 프로그래밍에서는 추상 클래스와 인터페이스를 통해 구체적인 클래스의 특성이 상대적으로 안정적이고 변경될 필요가 없는 추상화 계층으로 규정되어 "수정에 폐쇄적"이라는 요구 사항을 충족합니다. 추상 클래스에서 파생된 구체적인 클래스는 시스템 동작을 변경하여 "확장에 대한 개방성"을 충족할 수 있습니다.
엔티티를 확장할 때 소프트웨어의 소스 코드나 바이너리 코드를 변경할 필요가 없습니다. 핵심은 추상화입니다.

2. LSP
전체 이름: "Liskov 대체 원칙" Liskov 대체 원칙
설명: 하위 유형은 기본 유형을 대체할 수 있어야 합니다. 소프트웨어 엔터티가 기본 클래스를 사용하는 경우 기본 클래스가 기본 클래스를 상속하는 하위 클래스로 대체되면 프로그램의 동작은 변경되지 않습니다. 소프트웨어 엔터티는 기본 클래스 개체와 하위 클래스 개체 간의 차이점을 인식하지 못합니다.
장점: 클라이언트가 인식하지 못한 채 동일한 상위 클래스 아래 하위 클래스의 교환을 쉽게 실현할 수 있습니다.

3. DIP
전체 이름: "종속성 반전 원칙" 종속성 반전 원칙
설명: 추상화에 의존하고 구체적인 것에 의존하지 마세요. 클라이언트는 추상 결합에 의존합니다.
추상화는 세부 사항에 의존해서는 안 됩니다. 세부 사항은 추상화에 의존해야 합니다.
프로그래밍은 구현을 위한 것이 아니라 인터페이스를 위한 것입니다.
장점: 전통적인 절차적 프로그래밍에서 생성된 종속성을 사용하면 전략이 세부 사항에 따라 달라지는데, 이는 전략이 세부 사항의 변경에 영향을 받기 때문에 좋지 않습니다. 종속성 역전 원리는 세부 사항과 전략을 추상화에 종속시키고, 추상화의 안정성이 시스템의 안정성을 결정합니다.
종속성 반전을 달성하는 방법은 무엇입니까?
추상적인 방식의 결합은 종속성 역전 원칙의 핵심입니다. 추상 결합 관계에는 항상 추상 클래스에서 상속되는 구체적인 클래스가 포함되며, 기본 클래스에 대한 모든 참조가 해당 하위 클래스로 변경될 수 있도록 보장해야 합니다. 따라서 Liskov 대체 원칙은 종속성 반전 원칙의 기초입니다.
추상 수준의 결합은 유연하지만 추가적인 복잡성을 가져옵니다. 구체적인 클래스 변경 가능성이 매우 작은 경우 추상 결합의 이점은 매우 제한됩니다. 더 나은.
계층 구조: 잘 구조화된 모든 객체 지향 아키텍처에는 명확한 계층 정의가 있으며, 각 계층은 잘 정의되고 제어된 인터페이스를 통해 외부에 응집력 있는 서비스 세트를 제공합니다.
추상화에 의존: 구체적인 클래스에 의존하지 않는 것이 좋습니다. 즉, 프로그램의 모든 종속성은 추상 클래스나 인터페이스에서 종료되어야 합니다. 다음을 수행해 보세요.
1. 어떤 변수도 특정 클래스에 대한 포인터나 참조를 보유해서는 안 됩니다.
2. 어떤 클래스도 구체적인 클래스에서 파생되어서는 안 됩니다.
3. 어떤 메서드도 기본 클래스에서 구현된 메서드를 재정의해서는 안 됩니다.

4. ISP
전체 이름: "인터페이스 분리 원리" 인터페이스 분리 원리
설명: 하나의 전체 인터페이스를 사용하는 것보다 여러 개의 전용 기능 인터페이스를 사용하는 것이 항상 좋습니다. 클라이언트 클래스의 관점에서 보면 한 클래스의 다른 클래스에 대한 종속성은 최소 인터페이스를 기반으로 해야 합니다. 지나치게 부풀린 인터페이스는 인터페이스를 오염시키며 클라이언트가 사용하지 않는 방법에 의존하도록 강요해서는 안 됩니다.
장점: 소프트웨어 시스템 기능이 확장되면 수정 압력이 다른 개체로 전달되지 않습니다.
인터페이스 격리 원칙을 구현하는 방법
사용자는 자신이 사용하지 않는 방법에 의존하도록 강요받아서는 안 됩니다.
1. 위임을 사용하여 인터페이스를 분리하세요.
2. 다중 상속을 사용하여 인터페이스를 분리합니다.

5. CARP 또는 CRP
전체 이름: "Composite/Aggregate 재사용 원칙" 또는 "복합 재사용 원칙"복합 재사용 원칙
설명: 새 객체의 일부 기능에는 이미 생성된 다른 개체에서 구현되었으므로 직접 다시 만드는 대신 다른 개체에서 제공하는 기능을 사용하고 새 개체의 일부로 만드십시오. 새 개체는 이러한 개체에 위임하여 기존 기능을 재사용합니다.
간단히 말하면 구성/집계를 사용하고 상속은 사용하지 않으려고 노력하세요.
장점:
1) 새 개체가 구성 요소 개체에 액세스하는 유일한 방법은 구성 요소 개체의 인터페이스를 통하는 것입니다.
2) 이러한 종류의 재사용은 구성 요소 개체의 내부 세부 정보가 새 개체에 보이지 않기 때문에 블랙박스 재사용입니다.
3) 이런 재사용은 포장을 지원합니다.
4) 이러한 종류의 재사용에는 종속성이 덜 필요합니다.
5) 각각의 새로운 수업은 작업에 집중할 수 있습니다.
6) 이러한 종류의 재사용은 런타임 중에 동적으로 수행될 수 있으며, 새 객체는 구성 요소 객체와 동일한 유형의 객체를 동적으로 참조할 수 있습니다.
7) 재사용 방식으로 거의 모든 환경에 적용 가능합니다.
단점:
즉, 시스템에서 관리해야 할 개체가 더 많아집니다.

6. LOD 또는 LKP
전체 이름: "데메테르의 법칙" 데메테르 원리 또는 "최소 지식 원리" 최소 지식 원리
설명: 개체는 가능한 한 적은 방식으로 서로 관련되어야 합니다. 관계.
디밋의 법칙 구현 방법
디밋의 법칙의 주요 목적은 정보의 과부하를 제어하는 ​​것입니다. 이를 시스템 설계에 적용할 때 다음 사항에 주의해야 합니다.
1) 클래스 분할 측면에서 약한 결합이 이루어져야 합니다. 종류를 만들어냈습니다. 클래스 간의 결합이 약할수록 클래스를 재사용하기가 더 쉽습니다.
2) 클래스 구조 설계 측면에서 각 클래스는 구성원의 접근 권한을 최소화해야 합니다. 클래스는 자신의 속성을 공개해서는 안 되지만, 외부 세계가 속성에 간접적으로 접근할 수 있도록 값을 얻고 할당하는 메서드를 제공해야 합니다.
3) 클래스 디자인에서는 가능하면 클래스는 불변 클래스로 디자인되어야 합니다.
4) 다른 객체에 대한 참조 측면에서 클래스의 다른 객체에 대한 참조는 최소화되어야 합니다.


단일 책임 원칙도 있습니다:

SRP 소개(SRP--단일 책임 원칙): 클래스에 관한 한, 클래스는 한 가지 일에만 집중해야 하며, 한 가지 이유만 가져야 합니다. 그 변화 . 소위 책임은 기능으로 이해될 수 있습니다. 즉, 설계된 기능은 두 개 이상의 기능이 아닌 하나의 기능만 가져야 함을 의미합니다. 이는 참조 변경의 이유로도 이해될 수 있습니다. 이 클래스를 수정해야 하는 두 가지 변경 사항이 있는 경우 이 클래스를 철회하는 것을 고려해야 합니다. 책임은 변화의 축이기 때문에 요구사항이 변경되면 해당 변경은 클래스 책임의 변경을 반영합니다. SRP 사용 시 주의할 점: 1. 합리적인 클래스에는 변경 이유가 하나만 있어야 합니다. 즉, 단일 책임이 있어야 합니다.
2. 변경 징후 없이 SRP 또는 기타 원칙을 적용하는 것은 현명하지 않습니다. 실제로 변경하려면 SRP와 같은 원칙을 적용하여 코드를 리팩토링해야 합니다.
4. 테스트 중심 개발을 사용하면 디자인 냄새가 나기 전에 불합리한 코드를 분리해야 합니다.
5. 취약성이 매우 강해지면 Facade 또는 Proxy 모드를 사용하여 코드를 리팩토링해야 합니다. SRP 이점: 요구 사항 변경으로 인한 결합을 제거하고 코드 경직성을 줄입니다.



이러한 원칙을 엄격히 준수할 필요는 없으며, 이를 위반해도 종교적 처벌은 없습니다. 하지만 이 원칙 중 하나라도 어기면 경고음이 울린다고 생각해야 합니다. ----Arthur J.Riel
(1) 모든 데이터는 해당 데이터가 위치한 클래스 내부에 숨겨야 합니다.
(2) 클래스 사용자는 클래스의 공유 인터페이스에 의존해야 하지만, 클래스는 사용자에게 의존할 수 없습니다. p15
(3) 클래스 프로토콜의 메시지를 최소화하세요.
(4) 모든 클래스가 이해하는 가장 기본적인 공개 인터페이스를 구현합니다[예: 복사 작업(전체 복사 및 얕은 복사), 동등 판단, 올바른 출력 내용, ASCII 설명 구문 분석 등]. p16
(5) 구현 세부 사항(예: 공유 코드를 배치하는 비공개 함수)을 클래스의 공개 인터페이스에 넣지 마세요.
클래스의 두 메서드에 공통 코드가 있는 경우 이러한 공통 코드를 방지하는 전용 함수를 만들 수 있습니다.
(6) 사용자가 사용할 수 없거나 관심이 없는 것으로 클래스의 공개 인터페이스를 방해하지 마십시오. p17
(7) 클래스 간 결합이 없거나 파생된 결합 관계만 있어야 합니다. 즉, 한 클래스는 다른 클래스와 아무 관련이 없거나 다른 클래스의 공용 인터페이스에서만 작업을 사용합니다. p18
(8) 클래스는 하나의 핵심 추상화만 나타내야 합니다.
동일한 유형의 속성이 변경되면 패키지의 모든 클래스를 공동으로 닫아야 합니다. 변경 사항이 패키지에 영향을 미치는 경우 패키지의 모든 클래스에 영향을 미치지만 다른 패키지에는 영향을 미치지 않습니다.
(9) 관련 데이터 및 동작을 중앙 집중화합니다.
디자이너는 get과 같은 연산을 통해 다른 객체로부터 데이터를 얻는 객체에 주의해야 합니다. 이러한 유형의 행동은 이러한 경험적 원칙이 위반되었음을 의미합니다.
(10) 관련없는 정보를 다른 수업에 담는다(즉, 서로 소통하지 않는 행동). p19
안정적인 종속성을 향해 나아가세요.
(11) 모델링하는 추상 개념이 객체가 수행하는 역할이 아니라 클래스인지 확인하세요. p23
(12) 시스템 기능을 수평 방향으로 최대한 균일하게 배포합니다. 즉, 설계에 따라 최상위 클래스는 작업을 균일하게 공유해야 합니다.
(13) 시스템에 전능한 클래스/객체를 만들지 마십시오. 이름에 Driver, Manager, System 및 Susystem이 포함된 클래스에는 특히 주의하세요.
인터페이스를 구현하기보다는 인터페이스를 계획하세요.
(14) 공개 인터페이스에서 많은 액세스 방법을 정의하는 클래스에 주의하세요. 액세스 방법이 많다는 것은 관련 데이터와 행동이 중앙에 저장되지 않는다는 것을 의미합니다.
(15) 서로 소통되지 않는 동작이 너무 많이 포함된 수업에는 주의하세요.
이 문제의 또 다른 징후는 애플리케이션 클래스의 공개 인터페이스에서 많은 get 및 set 함수를 생성한다는 것입니다.
(16) 사용자 인터페이스와 상호 작용하는 객체 지향 모델로 구성된 애플리케이션에서 모델은 인터페이스에 종속되어서는 안 되지만, 인터페이스는 모델에 종속되어야 합니다.
(17) 최대한 현실 세계에 맞춰 모델링합니다(시스템 기능 분산 원칙을 준수하고, 다목적 클래스 원칙을 피하고, 관련 데이터 및 동작을 중앙에 배치하기 위해 이 원칙을 위반하는 경우가 많습니다).
(18) 디자인에서 불필요한 클래스를 제거하세요.
일반적으로 이 클래스를 속성으로 다운그레이드하겠습니다.
(19) 시스템 외부의 클래스를 제거합니다.
시스템 외부 클래스의 특징은 추상적인 용어로 시스템 도메인에만 메시지를 보내고 시스템 도메인에 있는 다른 클래스의 메시지는 허용하지 않는다는 것입니다.
(20)작업을 클래스로 전환하지 마세요. 이름이 동사이거나 동사에서 파생된 클래스, 특히 하나의 의미 있는 동작만 있는 클래스에 질문하세요. 의미 있는 동작을 이미 존재하거나 아직 발견되지 않은 클래스로 이동해야 하는지 고려하세요.
(21) 우리는 애플리케이션 분석 모델을 생성할 때 프록시 클래스를 자주 도입합니다. 설계 단계에서 우리는 많은 에이전트가 쓸모가 없어 제거되어야 한다는 사실을 종종 발견합니다.
(22) 수업의 공동작업자 수를 최소화하세요.
한 수업에서 사용하는 다른 수업의 수는 가능한 한 적어야 합니다.
(23) 수업과 공동작업자 간에 전달되는 메시지 수를 최소화합니다.
(24) 학급과 공동 작업자 간의 공동 작업 양을 최소화합니다. 즉, 학급과 공동 작업자 간에 전달되는 다양한 메시지 수를 줄입니다.
(25) 클래스의 팬아웃을 최소화합니다. 즉, 클래스에서 정의한 메시지 수와 전송된 메시지 수의 곱을 줄입니다.
(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) 객체의 상태를 수정하기 위해 공개 인터페이스를 우회하지 마세요.

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