소프트웨어 개발에서는 객체지향 디자인 유연하고 확장 가능하며 유지 관리 및 재사용 가능한 코드를 작성할 때 중요한 역할을 합니다. OOD를 사용하면 많은 이점이 있지만 모든 개발자는 프로그래밍에서 좋은 객체 지향 설계를 위한 SOLID 원칙도 알아야 합니다. SOLID 원칙은 Bob 삼촌이라고도 알려진 Robert C. Martin에 의해 도입되었으며 프로그래밍의 코딩 표준입니다. 이 원칙은 아래에 제시된 다섯 가지 원칙의 약어입니다.

• 단일 책임 원칙(SRP)
• 개방/폐쇄 원칙
• Liskov의 대체 원리(LSP)
• 인터페이스 분리 원칙(ISP)
• 종속성 역전 원리(DIP)

SOLID 원리는 긴밀한 결합을 줄이는 데 도움이 됩니다. 긴밀한 결합은 클래스 그룹이 서로 크게 의존한다는 것을 의미하므로 코드에서 피해야 합니다.

• 긴밀한 결합의 반대는 느슨한 결합이며, 느슨하게 결합된 클래스가 있는 코드는 좋은 코드로 간주됩니다.
• 느슨하게 결합된 클래스는 코드 변경을 최소화하고 코드를 더 재사용 가능하고 유지 관리 가능하며 유연하고 안정적으로 만드는 데 도움이 됩니다. 이제 이러한 원칙을 하나씩 논의해 보겠습니다.

1. 단일 책임 원칙

이 원칙은 클래스를 변경해야 하는 이유는 단 하나여야 합니다. 이는 모든 클래스가 단일 책임, 단일 직업 또는 단일 목적을 가져야 함을 의미합니다. 즉, 클래스는 소프트웨어 시스템 내에서 단 하나의 작업이나 목적만을 가져야 합니다.

맵 자바가 뭐야?

예를 사용하여 단일 책임 원칙을 이해해 보겠습니다.

빵 굽는 일을 담당하는 제빵사를 상상해 보세요. 제빵사의 역할은 빵을 굽는 작업에 집중하여 빵이 고품질이고 적절하게 구워지며 빵집의 기준을 충족하는지 확인하는 것입니다.

• 그러나 제빵사가 재고 관리, 소모품 주문, 고객 응대, 빵집 청소도 담당한다면 이는 SRP를 위반하는 것입니다.
• 이러한 각 작업은 별도의 책임을 나타내며, 이를 결합하면 빵 굽기에 대한 제빵사의 집중력과 효율성이 손상될 수 있습니다.
• SRP를 준수하기 위해 제과점에서는 개인이나 팀마다 다른 역할을 할당할 수 있습니다. 예를 들어, 재고 관리를 담당하는 사람이나 팀, 소모품 주문, 고객 서비스, 빵집 청소를 담당하는 사람이나 팀이 따로 있을 수 있습니다.

2. 개방/폐쇄 원칙

이 원칙은 소프트웨어 엔터티(클래스, 모듈, 기능 등)는 확장을 위해 열려야 하지만 수정을 위해 닫혀 있어야 합니다. 이는 클래스 동작을 수정하지 않고도 확장할 수 있어야 함을 의미합니다.

다음 예를 사용하여 개방/폐쇄 원칙을 이해해 보겠습니다.

다음과 같은 클래스가 있다고 상상해보십시오.PaymentProcessor>온라인 상점에 대한 결제를 처리하는 곳입니다. 처음에는PaymentProcessor>클래스는 신용카드를 사용한 결제 처리만 지원합니다. 그러나 PayPal을 사용한 결제 처리도 지원하도록 기능을 확장하려고 합니다.

cm에서 피트와 인치로

기존 내용을 수정하는 대신PaymentProcessor>PayPal 지원을 추가하기 위해 클래스를 만들려면 다음과 같은 새 클래스를 만들 수 있습니다.PayPalPaymentProcessor>그 확장PaymentProcessor>수업. 이 방법으로,PaymentProcessor>수업은 수정을 위해 닫혀 있지만 개방형 원칙을 준수하여 확장을 위해 열려 있습니다.

3. 리스코프의 대체원리

이 원칙은 1987년 Barbara Liskov에 의해 도입되었으며 이 원칙에 따라 파생 클래스 또는 하위 클래스는 기본 클래스 또는 상위 클래스를 대체할 수 있어야 합니다. . 이 원칙은 부모 클래스의 자식 클래스가 예상치 못한 동작 없이 부모 대신 사용될 수 있도록 보장합니다.

예를 사용하여 Liskov의 대체 원칙을 이해해 보겠습니다.

이 원리의 전형적인 예 중 하나는 4개의 변을 가진 직사각형입니다. 직사각형의 높이는 임의의 값이 될 수 있고 너비는 임의의 값이 될 수 있습니다. 정사각형은 너비와 높이가 같은 직사각형입니다. 따라서 직사각형 클래스의 속성을 정사각형 클래스로 확장할 수 있다고 말할 수 있습니다.

그렇게 하려면 4개의 동일한 변을 갖는 정사각형의 정의에 맞게 하위(정사각형) 클래스를 상위(직사각형) 클래스로 바꿔야 하지만 파생 클래스는 상위 클래스의 동작에 영향을 미치지 않으므로 그렇게 할 경우 Liskov 대체 원칙을 위반하게 됩니다.

항상 Verilog

4. 인터페이스 분리 원칙

이 원칙은 SOLID의 클래스가 아닌 인터페이스에 적용되는 첫 번째 원칙이며 단일 책임 원칙과 유사합니다. 그것은 다음과 같이 말합니다. 클라이언트에게 관련 없는 인터페이스를 구현하도록 강요하지 마세요. . 여기서 주요 목표는 뚱뚱한 인터페이스를 피하고 많은 작은 클라이언트별 인터페이스를 선호하는 데 중점을 두는 것입니다. 하나의 일반 인터페이스보다는 여러 클라이언트 인터페이스를 선호해야 하며 각 인터페이스에는 특정 책임이 있어야 합니다.

예를 사용하여 인터페이스 분리 원칙을 이해해 보겠습니다.

당신이 식당에 들어갔고 당신이 완전 채식주의자라고 가정해 보십시오. 그 식당의 웨이터는 채식주의 항목, 비채식 항목, 음료 및 과자가 포함된 메뉴 카드를 주었습니다.

• 이 경우 고객은 음식에 포함되지 않은 모든 항목이 아닌 채식 항목만 포함된 메뉴 카드를 가지고 있어야 합니다. 여기서 메뉴는 고객 유형에 따라 달라야 합니다.
• 모든 사람을 위한 공통 또는 일반 메뉴 카드는 하나가 아닌 여러 개의 카드로 나눌 수 있습니다. 이 원칙을 사용하면 부작용과 필요한 변경 빈도를 줄이는 데 도움이 됩니다.

5. 의존성 역전 원리

DIP(종속성 역전 원칙)는 다음과 같은 객체 지향 설계의 원칙입니다. 상위 수준 모듈은 하위 수준 모듈에 의존해서는 안 됩니다. 둘 다 추상화에 의존해야 합니다. . 또한 추상화는 세부 사항에 의존해서는 안 됩니다. 세부 사항은 추상화에 따라 달라집니다.

• 간단히 말해서, DIP는 클래스가 구체적인 구현보다는 추상화(예: 인터페이스 또는 추상 클래스)에 의존해야 한다고 제안합니다.
• 이를 통해 더욱 유연하고 분리된 코드가 가능해지며, 코드베이스의 다른 부분에 영향을 주지 않고 구현을 더 쉽게 변경할 수 있습니다.

예를 사용하여 종속성 반전 원리를 이해해 보겠습니다.

셰자드 푸나왈라

소프트웨어 개발 팀에서 개발자는 추상 버전 제어 시스템(예: Git)을 사용하여 코드베이스의 변경 사항을 관리하고 추적합니다. Git이 내부적으로 어떻게 작동하는지에 대한 구체적인 세부 사항에 의존하지 않습니다.

이를 통해 개발자는 버전 제어 구현의 복잡성을 이해할 필요 없이 코드 작성에 집중할 수 있습니다.