모든 개발자가 알아야 할 10가지 객체 지향 프로그래밍 원칙

나는 SOLID 원칙에 대해 들어보지 못한 개발자들을 자주 만납니다(우리는 여기에 대해 자세히 이야기했습니다.. — Transl.) 또는 객체 지향 프로그래밍(OOP) 또는 들어본 적이 있지만 실제로 사용하지 마십시오. 이 기사에서는 개발자의 일상 작업에 도움이 되는 OOP 원칙의 이점을 설명합니다. 그 중 일부는 잘 알려져 있고 다른 일부는 그다지 많지 않으므로 이 기사는 초보자와 숙련된 프로그래머 모두에게 유용할 것입니다.

알림: 모든 Habr 독자를 위한 - Habr 프로모션 코드를 사용하여 Skillbox 과정에 등록할 때 10 루블 할인.

Skillbox는 다음을 권장합니다. 교육용 온라인 과정 "자바 개발자".

DRY(반복하지 마세요)

매우 간단한 원칙으로, 그 본질은 이름에서 분명합니다. "반복하지 마십시오." 프로그래머에게 이는 중복 코드를 피해야 할 필요성과 작업에서 추상화를 사용할 수 있는 기회를 의미합니다.

코드에 두 개의 반복 섹션이 있는 경우 하나의 메서드로 결합해야 합니다. 하드코딩된 값이 두 번 이상 사용되는 경우 이를 공용 상수로 변환하는 것이 좋습니다.

이는 코드를 단순화하고 유지 관리를 더 쉽게 하기 위해 필요하며, 이것이 OOP의 주요 목표입니다. 동일한 코드가 OrderId와 SSN 모두에 대한 확인을 통과하지 못하므로 공용체를 과도하게 사용해서는 안 됩니다.

변경사항 캡슐화

대부분의 회사의 소프트웨어 제품은 끊임없이 발전하고 있습니다. 이는 코드를 변경하고 지원해야 함을 의미합니다. 캡슐화를 사용하면 삶을 더 쉽게 만들 수 있습니다. 이를 통해 기존 코드 베이스를 보다 효율적으로 테스트하고 유지 관리할 수 있습니다. 여기에 한 가지 예가 있습니다..

Java로 작성한다면, 기본적으로 개인 메소드 및 변수 할당.

개방/폐쇄 원리

이 원칙은 다음 문장을 읽으면 쉽게 기억할 수 있습니다. "소프트웨어 엔터티(클래스, 모듈, 기능 등)는 확장을 위해 열려야 하지만 수정을 위해 닫혀 있어야 합니다." 실제로 이는 소스 코드를 변경하지 않고도 동작을 변경할 수 있음을 의미합니다.

소스 코드 변경에 코드 수정, 단위 테스트 및 기타 절차가 필요한 경우 이 원칙이 중요합니다. 개방형/폐쇄형 원칙을 따르는 코드는 확장해도 변경되지 않으므로 문제가 훨씬 적습니다.

다음은 이 원칙을 위반하는 코드의 예입니다.

그 안에 있는 내용을 변경해야 하는 경우 원하는 조각과 연결된 코드의 모든 섹션을 변경해야 하므로 시간이 많이 걸립니다.

그런데 개방-폐쇄는 SOLID의 원칙 중 하나입니다.

단일 책임 원칙(SRP)

SOLID 세트의 또 다른 원리입니다. “계급에 변화를 일으키는 원인은 단 하나뿐이다”라고 명시되어 있습니다. 수업에서는 한 가지 문제만 해결합니다. 여러 가지 방법이 있을 수 있지만 각 방법은 공통된 문제를 해결하는 데에만 사용됩니다. 모든 메서드와 속성은 이 기능만 제공해야 합니다.

이 원칙의 가치는 개별 소프트웨어 구성 요소와 코드 간의 결합을 느슨하게 한다는 것입니다. 클래스에 둘 이상의 기능을 추가하면 두 기능 간의 관계가 발생합니다. 따라서 그 중 하나를 변경하면 첫 번째와 연결된 두 번째 것을 망칠 가능성이 높습니다. 이는 모든 문제를 사전에 식별하기 위해 테스트 주기를 늘리는 것을 의미합니다.

종속성 반전 원리(DIP)

위는 AppManager가 EventLogWriter에 의존하고, EventLogWriter가 AppManager와 밀접하게 결합되는 코드 예제입니다. 푸시, SMS, 이메일 등 알림을 표시하는 다른 방법이 필요한 경우 AppManager 클래스를 변경해야 합니다.

DIP를 사용하여 문제를 해결할 수 있습니다. 따라서 AppManager 대신 프레임워크를 사용하여 입력될 EventLogWriter를 요청합니다.

DIP를 사용하면 종속성 모듈을 변경하여 개별 모듈을 다른 모듈로 쉽게 교체할 수 있습니다. 이를 통해 다른 모듈에 영향을 주지 않고 하나의 모듈을 변경할 수 있습니다.

상속 대신 구성

코드를 재사용하는 방법에는 상속과 합성이라는 두 가지 주요 방법이 있으며 둘 다 고유한 장점과 단점이 있습니다. 일반적으로 두 번째 방법이 더 유연하기 때문에 선호됩니다.

컴포지션을 사용하면 해당 속성을 설정하여 런타임 시 클래스의 동작을 변경할 수 있습니다. 인터페이스를 구현할 때 보다 유연한 구현을 제공하는 다형성이 사용됩니다.

Joshua Bloch의 Effective Java에서도 상속보다는 구성을 선택하라고 조언합니다.

Barbara Liskov 대체 원리(LSP)

SOLID 툴킷의 또 다른 원칙입니다. 이는 하위 유형이 상위 유형을 대체할 수 있어야 함을 나타냅니다. 즉, 슈퍼클래스와 함께 작동하는 메서드와 함수는 하위클래스에서도 문제 없이 작동할 수 있어야 합니다.

LSP는 단일 책임 원칙과 공유 책임 원칙 모두와 연관되어 있습니다. 클래스가 하위 클래스보다 더 많은 기능을 제공하는 경우 하위 클래스는 일부 기능을 지원하지 않으므로 이 원칙을 위반하게 됩니다.

다음은 LSP와 모순되는 코드입니다.

Area(Rectangle r) 메소드는 Rectangle의 면적을 계산합니다. 여기서 Square는 Rectangle이 아니기 때문에 Square를 실행한 후 프로그램이 중단됩니다. LSP 원칙에 따르면 기본 클래스에 대한 참조를 사용하는 함수는 추가 지침 없이 파생 클래스의 개체를 사용할 수 있어야 합니다.

하위 유형의 특정 정의인 이 원칙은 "데이터 추상화 및 계층 구조"라는 제목의 1987년 컨퍼런스 기조연설에서 Barbara Liskov가 제안한 것입니다.

인터페이스 분리 원리(ISP)

또 다른 견고한 원칙. 이에 따르면 사용되지 않는 인터페이스는 구현하면 안 된다. 이 원칙을 따르면 운영 논리가 변경될 때 시스템이 유연성을 유지하고 리팩토링에 적합하게 유지되는 데 도움이 됩니다.

대부분의 경우 이러한 상황은 인터페이스에 여러 기능이 동시에 포함되어 있고 클라이언트에 그 중 하나만 필요한 경우에 발생합니다.

인터페이스를 작성하는 것은 어려운 작업이기 때문에 작업이 완료된 후 아무것도 깨지지 않고 변경하는 것은 어려울 것입니다.

Java에서 ISP 원칙의 장점은 모든 메소드가 먼저 구현되어야 하고 그 후에만 클래스에서 사용할 수 있다는 것입니다. 따라서 이 원리를 이용하면 방법의 수를 줄이는 것이 가능하다.

구현이 아닌 인터페이스를 위한 프로그래밍

여기의 모든 것은 이름에서 명확합니다. 이 원칙을 적용하면 새로운 인터페이스 구현과 함께 작동할 수 있는 유연한 코드가 생성됩니다.

변수, 반환 유형 또는 메서드 인수 유형에는 인터페이스 유형을 사용해야 합니다. 예를 들어 SubClass 대신 SuperClass를 사용하는 경우가 있습니다.

즉 :

목록 번호= getNumbers();

그리고 아닙니다 :

ArrayList 번호 = getNumbers();

위에서 논의한 내용의 실제 구현은 다음과 같습니다.

위임 원칙

일반적인 예는 Java의 equals() 및 hashCode() 메소드입니다. 두 개체를 비교해야 하는 경우 이 작업은 클라이언트 클래스 대신 해당 클래스에 위임됩니다.

이 원칙의 장점은 코드 중복이 없고 동작 변경이 비교적 간단하다는 것입니다. 이벤트 위임에도 적용됩니다.

이러한 모든 원칙을 통해 높은 응집력과 낮은 결합도를 통해 더욱 유연하고 아름답고 안정적인 코드를 작성할 수 있습니다. 물론 이론도 좋지만 개발자가 습득한 지식을 실제로 활용하려면 실습이 필요합니다. OOP 원칙을 숙지했다면 다음 단계는 일반적인 소프트웨어 개발 문제를 해결하기 위한 디자인 패턴을 배우는 것일 수 있습니다.

Skillbox는 다음을 권장합니다.

• 실기 코스 "모바일 개발자 PRO".
• 온라인 강좌 적용 "Python의 데이터 분석가".
• XNUMX년 실습 코스 "저는 PRO 웹 개발자입니다".

출처 : habr.com