Java 프로그래머가 객체지향에 익숙해질 수 있도록 10가지 설계 원칙에 대한 자세한 설명

이 글은 자바 프로그래머가 꼭 알아야 할 객체지향 디자인 원칙 10가지를 중심으로 자세히 소개하고 있으니 관심 있는 친구들이 참고하면 좋을 것 같습니다.

객체지향 디자인 원칙은 OOPS 프로그래밍의 핵심인데, 제가 본 대부분의 Java 프로그래머들은 Singleton(단일 케이스), Decorator(데코레이터), Observer(관찰자) 등과 같은 디자인 패턴에 열광하지만 충분히 관심을 기울이지 않습니다. 객체지향 분석과 설계를 학습합니다. "추상화", "캡슐화", "다형성", "상속"과 같은 객체 지향 프로그래밍의 기본 사항을 배우는 것이 중요하지만 간결한 모듈식 디자인을 만들기 위해서는 이러한 디자인 원칙을 이해하는 것도 똑같이 중요합니다. 저는 이러한 OOPS 및 SOLID 디자인 원칙을 모르거나 특정 디자인 원칙의 이점, 심지어 이를 코딩 디자인 원칙에 사용하는 방법조차 모르는 다양한 경험 수준의 Java 프로그래머를 자주 봅니다.

(디자인 원칙) 결론은 항상 코딩이나 디자인을 높은 응집력과 낮은 결합도를 추구하는 것입니다. Apache와 Sun의 오픈 소스 코드는 Java 및 OOPS 디자인 원칙을 학습하는 데 좋은 예입니다. 이는 Java 프로그래밍에서 디자인 원칙이 어떻게 사용되는지 보여줍니다. Java JDK는 BorderFactory 클래스의 팩토리 패턴, Runtime 클래스의 싱글톤 패턴, java.io 클래스의 데코레이터 패턴 등 몇 가지 디자인 원칙을 사용합니다. 그런데 Java 코딩 원리에 정말로 관심이 있다면 Java API를 작성한 Joshua Bloch의 Effective Java를 읽어보세요. 객체 지향 디자인 패턴에 대해 제가 개인적으로 가장 좋아하는 것은 Kathy Sierra의 Head First Design Pattern과 객체 지향 분석 및 디자인을 간단한 용어로 다루는 다른 책입니다. 이 책들은 다양한 객체 지향 및 SOLID 디자인 패턴을 최대한 활용하는 더 나은 코드를 작성하는 데 큰 도움이 됩니다.

디자인 패턴(원칙)을 익히는 가장 좋은 방법은 실제 사례를 통해 그리고 디자인 원칙을 위반할 때 발생하는 불편함을 이해하는 것이지만, 이 글의 목적은 디자인 패턴(원칙)을 접해본 적이 없는 Java 프로그래머를 교육하는 것입니다. 객체지향 설계 원리를 소개하는 단계입니다. 저는 개인적으로 OOPS와 SOLID 디자인 원칙을 명확하게 소개하는 글이 필요하다고 생각합니다. 여기서는 최선을 다하겠지만, 이제 다음 디자인 패턴(원칙)을 찾아볼 준비를 하세요 :)
DRY - 하지 마세요. 반복하세요

저희의 첫 번째 객체 지향 설계 원칙은 DRY입니다. 이름에서 알 수 있듯이 DRY(반복하지 마세요)는 반복되는 코드를 작성하지 않고 재사용 가능한 코드 블록으로 추상화한다는 의미입니다. . 두 개 이상의 동일한 코드 블록이 있는 경우 이를 별도의 메소드로 추상화하는 것을 고려하거나 하드 코딩된 값을 여러 번 사용하는 경우 공개 상수로 만드십시오. 이 객체 지향 설계 원칙의 장점은 유지 관리가 쉽다는 것입니다. 이 원칙을 남용하지 않는 것이 중요합니다. 복제는 코드가 아니라 기능에 관한 것입니다. 즉, 공통 코드를 사용하여 OrderID와 SSN을 확인한다고 해서 동일하거나 앞으로도 동일하게 유지된다는 의미는 아닙니다. 공통 코드를 사용하여 두 가지 다른 기능을 구현하거나 OrderID 형식이 변경되면 이 두 가지 기능을 밀접하게 연결하면 SSN 확인 코드가 손상됩니다. 따라서 이러한 결합에 주의하고 서로 관련이 없는 유사한 코드를 결합하지 마십시오. 변경 사항을 캡슐화합니다. 향후 수정될 코드를 캡슐화합니다. 이 객체 지향 디자인 패턴의 장점은 적절하게 캡슐화된 코드를 쉽게 테스트하고 유지 관리할 수 있다는 것입니다. Java로 프로그래밍하는 경우 다음 원칙을 준수하시기 바랍니다.

변수 및 메소드의 접근 권한

은 기본적으로 private으로 설정되어 있으며, "private"에서 "private"으로 점차적으로 접근 권한이 해제됩니다. 보호됨", "공개되지 않음". Java의 일부 디자인 패턴은 캡슐화를 사용합니다. 팩토리 디자인 패턴은 객체를 생성하는 코드를 캡슐화하고 다음과 같은 유연성을 제공합니다. 새 객체의 후속 생성은 기존 코드에 영향을 주지 않습니다.

열기/닫기 디자인 원칙

OpenClosed 디자인 원칙클래스, 메소드/함수는 확장(새로운 기능)에 개방되고 수정에는 폐쇄되어야 합니다. . 이는 테스트를 통과한 코드를 누군가가 수정하는 것을 방지하는 또 다른 우아한 SOLID 설계 원칙입니다. 이상적으로는 새로운 기능을 추가하면 코드가 테스트되며 이는 온/오프 디자인 원칙의 목표입니다. 그런데 SOLID의 문자 "O"는 개방형/폐쇄형 디자인 원칙을 나타냅니다.

단일 책임 원칙

단일 책임 원칙(SRP)

단일 책임 원칙은 SOLID의 또 다른 디자인 원칙으로, SOLID의 문자 "S"는 이를 나타냅니다. SRP에 따르면 클래스 수정에는 단 하나의 이유가 있어야 합니다. 그렇지 않으면 클래스는 항상 단일 함수를 구현해야 합니다. Java의 클래스가 여러 함수를 구현하는 경우 이러한 함수 간에 결합 관계가 생성됩니다. 함수 중 하나를 수정하면 결합 관계가 끊어진 다음 새로운 문제를 피하기 위해 또 다른 라운드 테스트를 수행할 수 있습니다.

의존성 주입/역전 원리

의존성 주입 또는 반전 원리

의존성 주입 기능이 무엇인지 묻지 마세요. 프레임워크는 어떤 이점을 제공합니까? 종속성 주입 기능은 스프링 프레임워크에서 잘 구현되었습니다. 이 디자인 원칙의 장점은 DI 프레임워크에 의해 주입된 모든 클래스를 모의 객체로 쉽게 테스트할 수 있다는 것입니다. 유지 관리, 개체를 생성하는 코드가 프레임워크 내에서 중앙 집중화되고 클라이언트 코드와 격리되기 때문입니다. 바이트코드 도구, 포인트컷 표현식과 같은 일부 AOP(관점 지향 프로그래밍) 프레임워크 또는 Spring에서 사용되는 프록시를 사용하는 등 종속성 주입을 구현하는 방법에는 여러 가지가 있습니다. 이 SOLID 설계 원칙에 대해 자세히 알아보려면 IOC 및 DI 설계 패턴의 예를 참조하세요. SOLID의 문자 "D"는 이러한 디자인 원칙을 나타냅니다.

상속보다 구성을 선호

상속보다 구성을 선호

가능하다면 상속보다 구성을 선호하세요. 이에 대해 논쟁을 벌이는 분들도 있겠지만 저는 구성이 상속보다 더 유연하다고 생각합니다. 구성을 사용하면 속성을 설정하여 런타임 시 클래스의 동작을 수정할 수 있습니다. 다형성을 사용하면 클래스 간의 구성 관계를 인터페이스 형태로 구현할 수 있으며 구성 관계를 수정할 수 있는 유연성을 제공할 수 있습니다. Effective Java에서도 상속보다 구성을 사용하는 것이 좋습니다.

리스코프 대체 원리

리스코프 대체 원리 LSP

리스코프 대체 원리에 따르면 상위 클래스가 나타나는 위치는 예를 들어, 상위 클래스 메서드나 함수가 하위 클래스 객체로 대체되면 문제가 없습니다. LSP는 단일 책임 원칙 및 인터페이스 격리 원칙과 밀접한 관련이 있습니다. 상위 클래스가 하위 클래스보다 더 많은 기능을 갖고 있다면 이 기능을 지원하지 않고 LSP 설계 원칙을 위반할 수 있습니다. LSP SOLID 설계 원칙을 따르려면 파생 클래스 또는 하위 클래스(상위 클래스에 상대적)가 기능을 축소하기보다는 향상시켜야 합니다. SOLID의 문자 "L"은 LSP 설계 원리를 나타냅니다.

인터페이스 격리 원칙

인터페이스 격리 원칙은 인터페이스의 기능이 필요하지 않으면 이 인터페이스를 구현하지 않는다는 의미입니다. 이는 인터페이스에 여러 함수가 포함되어 있지만 구현 클래스에는 그 중 하나만 필요한 경우에 주로 발생합니다. 인터페이스 디자인은 일단 인터페이스가 게시되면 이를 구현하는 클래스에 영향을 주지 않고 수정할 수 없기 때문에 까다로운 작업입니다. Java에서 이 디자인 원칙의 또 다른 이점은 인터페이스에는 클래스가 인터페이스를 사용하기 전에 인터페이스의 모든 메소드를 구현해야 한다는 특성이 있으므로 단일 기능 인터페이스를 사용한다는 것은 더 적은 메소드를 구현한다는 것을 의미합니다.

프로그래밍은 항상 (구현 객체가 아닌) 인터페이스 중심에 있습니다.

프로그래밍은 항상 (구현 객체가 아닌) 인터페이스 중심에 있으며, 이는 코드 구조를 구성합니다. 유연하며 새로운 인터페이스 구현 객체는 기존 코드 구조와 호환됩니다. 따라서 Java에서는 변수의 데이터 유형, 메소드 반환값, 메소드 매개변수에 대한 인터페이스를 사용하시기 바랍니다. 이는 Effective Java 및 헤드 퍼스트 디자인 패턴과 같은 책의 조언과 마찬가지로 많은 Java 프로그래머의 조언입니다.

대리 원칙

하나의 클래스가 모든 기능을 완료할 것이라고 기대하지 마십시오. 구현을 위해 일부 기능을 프록시 클래스에 적절하게 위임할 수 있습니다. 프록시 원칙의 예는 Java의 equals() 및 hashCode() 메소드입니다. 두 객체의 내용이 동일한지 비교하기 위해 호출자 대신 비교 클래스 자체가 비교 작업을 수행하도록 합니다. 이 설계 원칙의 이점은 코딩 중복이 없으며 클래스 동작을 수정하기 쉽다는 것입니다.

요약

위의 모든 객체 지향 설계 원칙은 유연하고 우아한 코드, 즉 응집력이 높고 결합도가 낮은 코드 구조를 작성하는 데 도움이 될 수 있습니다. 이론은 첫 번째 단계일 뿐이며, 이러한 디자인 원칙을 언제 사용해야 하는지 발견하는 능력을 습득하는 것이 더 중요합니다. 디자인 원칙을 위반했는지 확인하고 코드 유연성에 영향을 미쳤지만 세상에 완벽한 것은 없습니다. 문제를 해결할 때 항상 디자인 패턴과 디자인 원칙을 사용할 수는 없습니다. 유지 관리주기가 긴 프로젝트에 주로 사용됩니다. 대규모 엔터프라이즈 프로젝트.

위 내용은 Java 프로그래머가 객체지향에 익숙해질 수 있도록 10가지 설계 원칙에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!