Java의 객체지향 설계의 6가지 원칙은 무엇입니까?

단일 책임 원칙

단일 책임 원칙의 정의는 클래스의 변경 이유가 하나만 있어야 한다는 것입니다. 즉, 클래스는 한 가지에만 책임을 져야 합니다. 클래스가 메소드 M1과 메소드 M2라는 서로 다른 두 가지를 담당하는 경우 M1 메소드가 변경되면 이 클래스의 M1 메소드를 수정해야 하는데 이때 M2 메소드가 작동하지 않을 수 있습니다. 이는 우리가 예상한 바는 아니지만, 이 디자인으로 인해 가능한 일입니다. 그래서 이때 M1 방식과 M2 방식을 두 클래스로 분리해야 합니다. 각 클래스가 자신의 메서드에만 집중하도록 하세요.

단일 책임 원칙의 이점은 다음과 같습니다.

클래스의 복잡성을 줄일 수 있습니다. 각 클래스는 하나의 책임만 담당합니다. 이렇게 하면 논리가 훨씬 단순해지고 클래스의 가독성이 향상되며 시스템의 유지 관리가 향상됩니다. 이 클래스의 의미를 이해해야 합니다. 변경 시 이 클래스에서만 수정이 이루어지기 때문에 변경으로 인한 영향을 최소화할 수 있습니다.

개폐원리

개방-폐쇄 원칙은 단일 책임 원칙과 마찬가지로 매우 기본적이고 일반적으로 상식적인 원칙입니다. 개방-폐쇄 원칙의 정의는 소프트웨어의 객체(클래스, 모듈, 함수 등)가 확장을 위해 열려야 하지만 수정을 위해서는 닫혀 있어야 한다는 것입니다.

요구 사항이 변경되면 코드를 수정해야 합니다. 이때 원본 코드를 수정하는 대신 원본 코드를 확장해야 합니다. 그렇게 하면 더 많은 문제가 발생할 수 있기 때문입니다.

이 원칙은 단일 책임 원칙과 동일하다. 모두가 그렇게 생각하지만 어떻게 해야 할지 명시하지 않는다는 원칙이다.

한 가지 방법으로 열기 및 닫기 원칙을 보장할 수 있습니다. 우리는 추상화를 사용하여 프레임워크를 구축하고 세부 사항을 확장하기 위해 구현합니다. 이러한 방식으로 수정이 발생하면 추상화를 직접 사용하여 수정을 구현하기 위한 구체적인 클래스를 파생시킵니다.

리히터 대체 원리

Liskov 치환 원리는 매우 유용한 개념입니다. 그의 정의

T1 유형의 모든 객체 o1에 대해 T2 유형의 객체 o2가 있어서 모든 객체 o1이 o2로 대체될 때 T1으로 정의된 모든 프로그램 P의 동작이 변경되지 않는 경우 T2 유형은 유형의 하위 유형입니다. T1.

이렇게 말하면 좀 복잡하지만 실제로는 간단한 정의가 있습니다

기본 클래스에 대한 모든 참조는 해당 하위 클래스의 개체를 투명하게 사용할 수 있어야 합니다.

일반인의 관점에서 보면 Liskov 대체 원칙은 다음과 같습니다. 하위 클래스는 상위 클래스의 기능을 확장할 수 있지만 상위 클래스의 원래 기능은 변경할 수 없습니다. 다음과 같은 의미가 포함되어 있습니다.

하위 클래스는 상위 클래스의 추상 메서드를 구현할 수 있지만 상위 클래스의 비추상 메서드를 재정의할 수는 없습니다.

서브클래스는 고유한 메서드를 추가할 수 있습니다.

하위 클래스 메서드가 상위 클래스 메서드를 재정의하는 경우 메서드의 형식 매개 변수는 상위 클래스 메서드의 입력 매개 변수보다 느슨합니다.

하위 클래스의 메서드가 상위 클래스의 추상 메서드를 구현할 때 메서드의 반환 값은 상위 클래스의 반환 값보다 더 엄격합니다.

리스코프 대체 원칙이 이를 요구하는 이유는 상속이 코드를 재사용하는 방법이긴 하지만 어느 정도 캡슐화에 위배되는 단점이 많기 때문이다. 상위 클래스의 속성과 메서드는 하위 클래스에 투명하며 하위 클래스는 마음대로 상위 클래스의 멤버를 수정할 수 있습니다. 또한 요구 사항이 변경되고 하위 클래스가 상위 클래스의 일부 메서드를 재정의하는 경우 다른 하위 클래스가 제대로 작동하지 못하게 됩니다. 그래서 리히터 대체 규칙이 제안되었습니다.

프로그램이 Liskov 대체 원칙을 따르도록 하려면 프로그램이 추상화를 설정하고 추상화를 통해 사양을 설정한 다음 구현을 사용하여 세부 사항을 확장해야 합니다. 예, Liskov 대체 원칙과 시작 및 종료 원칙은 종종 상호의존적입니다.

의존성 역전 원리

종속성 역전 원칙은 상위 모듈이 하위 모듈의 구현 세부 사항에 의존하지 않고 종속 모듈이 반전되도록 하는 특수한 분리 방법을 나타냅니다. 이것도 이해하기 어려운 정의입니다. 간단히 말해서

이라고 할 수 있습니다. 상위 수준 모듈은 하위 수준 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해서는 안 됩니다. 세부 사항은 추상화에 의존해서는 안 됩니다

Java에서 추상화는 인스턴스화할 수 없는 인터페이스 또는 추상 클래스를 나타냅니다. 세부 사항은 인터페이스를 구현하거나 추상 클래스를 상속하는 클래스인 구현 클래스입니다. 인스턴스화할 수 있습니다. 상위 수준 모듈은 호출 측을 참조하고 하위 수준 모듈은 특정 구현 클래스를 나타냅니다. Java에서 종속성 반전 원칙은 모듈 간의 종속성이 추상화를 통해 발생한다는 것을 의미하며 구현 클래스 간에는 직접적인 종속성이 없으며 해당 종속성은 인터페이스를 통해 실현됩니다. 이는 일반적으로 인터페이스 지향 프로그래밍으로 알려져 있습니다.

이 문제를 설명하는 예가 아래에 있습니다. 이 예는 망치를 사용하여 무언가를 수리하는 작업자의 예입니다. 우리의 코드는 다음과 같습니다:

공개 클래스 해머 {

​공개 문자열 함수(){

return "망치를 사용하여 수리하세요";

}

}

공개 클래스 작업자 {

공개 무효 수정(해머 해머){

​System.out.println("작업자" + hammer.function());

}

​public static void main(String[] args) {

새로운 작업자(). fix(new Hammer());

}

}

이것은 매우 간단한 예이지만, 새로운 기능을 추가하려면 작업자가 드라이버를 사용하여 수리하는 것이 어렵습니다. Worker 클래스는 특정 구현 클래스 Hammer에 의존하기 때문입니다. 그래서 우리는 인터페이스 지향 프로그래밍의 아이디어를 사용하여 다음 코드로 변경합니다.

공개 인터페이스 도구 {

​공용 문자열 함수();

}

그런 다음 Worker는 이 인터페이스를 통해 다른 세부 클래스를 사용합니다. 코드는 다음과 같습니다:

공개 클래스 작업자 {

​공개 무효 수정(도구 도구){

​System.out.println("작업자" + tool.function());

}

​public static void main(String[] args) {

새로운 작업자(). fix(new Hammer());

새로운 작업자(). 수정(새 드라이버());

}

}

Hammer 클래스와 Screwdriver 클래스가 이 인터페이스를 구현합니다

공개 클래스 Hammer는 도구를 구현합니다.{

​공용 문자열 함수(){

return "망치를 사용하여 수리하세요";

}

}

​공개 클래스 드라이버가 도구를 구현합니다{

​@오버라이드

​공용 문자열 함수() {

return "드라이버를 사용하여 수리하세요";

}

}

이와 같이 인터페이스 지향 프로그래밍을 통해 우리 코드는 높은 확장성을 가지며, 코드 간의 결합을 줄이고 시스템의 안정성을 향상시킵니다.

인터페이스 격리 원리

인터페이스 격리 원칙의 정의는

클라이언트는 필요하지 않은 인터페이스에 의존해서는 안 됩니다

즉, 클래스 간의 종속 관계는 가장 작은 인터페이스에서 설정되어야 합니다. 이해하기가 더 어려운 것 같습니다. 예를 들어 설명해 보겠습니다. 구체적인 클래스가 Java로 인터페이스를 구현하는 경우 인터페이스의 모든 메소드를 구현해야 한다는 것을 알고 있습니다. 인터페이스 I에 의존하는 클래스 A와 클래스 B가 있는 경우 클래스 B는 클래스 A의 종속성을 구현하고 이 인터페이스 I에는 5개의 메서드가 있습니다. 그러나 클래스 A와 B는 메소드 1, 2, 3에만 의존하고 클래스 C와 D는 인터페이스 I에 의존합니다. 클래스 D는 클래스 C에 대한 종속성을 구현하지만 메소드 1, 4, 5에 의존합니다. 그러면 인터페이스를 구현할 때 클래스 B는 필요하지 않은 메서드 4와 메서드 5를 구현해야 하고, 클래스 D는 필요하지 않은 메서드 2와 메서드 3을 구현해야 합니다. 이것은 단순히 재난 디자인입니다.

따라서 인터페이스를 분할해야 합니다. 즉, 인터페이스를 종속성을 충족하는 가장 작은 인터페이스로 분할해야 합니다. 클래스 B와 클래스 D는 서로 관련이 없는 인터페이스 메서드를 구현할 필요가 없습니다. 예를 들어, 이 예에서는 인터페이스를 3개로 분할할 수 있습니다. 첫 번째 인터페이스는 메서드 1만 포함하고, 두 번째 인터페이스는 메서드 2와 3을 포함하고, 세 번째 인터페이스는 메서드 4와 5를 포함합니다. 이러한 방식으로 우리의 디자인은 인터페이스 격리 원칙을 충족합니다.

위의 디자인 아이디어는 영어의 첫 글자를 따서 SOLID로 구성할 수 있으며, 이 5가지 원칙을 충족하는 프로그램도 SOLID 기준을 충족한다고 합니다.

디밋 원리

데메테르의 원리는 최소 지식의 원리라고도 합니다. 그의 정의

객체는 다른 객체에 대해 최소한의 지식을 유지해야 합니다.

클래스 간의 관계가 가까울수록 결합 정도가 커지므로 한 클래스가 변경되면 다른 클래스에 미치는 영향도 커집니다. 따라서 이는 낮은 결합, 높은 결합이라는 소프트웨어 프로그래밍의 일반적인 원칙이기도 합니다. 응집력. 데메테르의 법칙에 대한 더 간단한 정의가 있습니다

직접적인 친구하고만 대화하세요. 먼저 직접적인 친구가 무엇인지 설명하겠습니다. 각 객체는 다른 객체와 결합 관계를 갖습니다. 두 객체 사이에 결합 관계가 있는 한 두 객체는 ​​친구라고 합니다. 의존성, 연관, 결합, 집합 등과 같은 결합 방법에는 여러 가지가 있습니다. 그 중 멤버 변수, 메소드 매개변수, 메소드 반환 값에 나타나는 클래스를 다이렉트 프렌드라고 부르지만, 지역 변수에 나타나는 클래스는 다이렉트 프렌드가 아닙니다. 즉, 익숙하지 않은 클래스가 클래스 내부에 지역 변수로 나타나지 않는 것이 가장 좋습니다.

여기서는 실제 사례를 사용하여 설명할 수 있습니다. 예를 들어, CD가 필요하면 비디오 가게에 가서 사장님에게 필요한 CD가 있는지 물어보세요. 사장님은 지금 필요한 CD가 없다고 하시면 그냥 와서 가져가시면 됩니다. 가능할 때 하세요. 여기서 우리는 상사가 CD를 어디서, 어떻게 얻었는지 신경 쓸 필요가 없습니다. 상사(직접 친구)와만 소통합니다. 상사가 친구로부터 CD를 받은 조건에 대해서는 신경 쓰지 않습니다. 우리는 그 사람의 의견에 동의하지 않습니다. 상사의 친구(낯선 사람)가 의사소통을 하는 Dimit의 응용 프로그램입니다. 직설적으로 말하면 중간적인 방법이다. 우리는 실제로 CD를 제공한 사람에게 연락하기 위해 상사를 중개자로 활용합니다.

위 내용은 Java의 객체지향 설계의 6가지 원칙은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!