LLD(낮은 수준 설계)는 높은 수준 설계와 실제 구현 사이의 격차를 해소하는 소프트웨어 개발의 중요한 단계입니다. 높은 수준의 디자인은 아키텍처 청사진에 중점을 두는 반면 LLD는 전체 시스템 요구 사항을 충족하기 위해 각 구성 요소, 클래스 또는 기능을 구현하는 방법을 다룹니다.

간단히 말하면 LLD에는 클래스, 메서드, 인터페이스 및 이들 간의 상호 작용을 설계하여 코드가 효율적이고 유지 관리 및 확장 가능하도록 보장합니다. 이는 소프트웨어 엔지니어에게 필수적인 기술이며, 특히 견고하고 재사용 가능하며 시간이 지남에 따라 쉽게 수정할 수 있어야 하는 시스템을 구축할 때 더욱 그렇습니다.

이 블로그에서는 하위 수준 설계와 관련된 주요 개념, 원칙 및 기술을 소개하고 이러한 내용이 더 좋고 유지 관리하기 쉬운 코드를 작성하는 데 어떻게 도움이 될 수 있는지 보여줍니다.

우리 마음 속에 떠오르는 첫 번째 질문은 다음과 같습니다.

로우레벨 디자인이 왜 중요한가요?

1. 유지관리성: 신중하게 설계된 디자인을 통해 코드를 더 쉽게 유지 관리, 확장 및 디버그할 수 있습니다. 잘못된 설계는 기술적 부채로 이어져 향후 변경 비용이 많이 듭니다.
2. 확장성: 좋은 LLD는 성능 측면과 시스템 발전에 따른 새로운 기능 지원 측면에서 코드 확장성을 보장합니다.
3. 재사용성: 잘 설계된 구성 요소는 시스템의 여러 부분이나 완전히 다른 프로젝트에서 재사용할 수 있습니다.
4. 명확성: 잘 정의된 설계를 통해 엔지니어는 시스템의 다양한 부분이 어떻게 조화를 이루는지 이해할 수 있어 협업이 더 쉬워집니다.

LLD 개념과 실제 코드 사이의 격차를 해소하기 위해 다음 단계를 통해 하위 수준 다이어그램을 설계하는 프로세스를 세분화해 보겠습니다.

1단계:객체 지향 원칙
2단계: 견고한 원칙
3단계:디자인 패턴

객체지향 원칙

객체 지향 프로그래밍 개념 로우레벨 디자인을 배우기 시작하려면 4가지 요소가 필수입니다. 나는 이미 간단한 체크아웃 블로그에서 이 개념을 다뤘습니다.

견고한 원칙

S: 단일 책임 원칙(SRP)

• 각 코드 단위에는 하나의 책임만 있어야 합니다.
• 단위는 클래스, 모듈, 함수 또는 구성 요소일 수 있습니다.
• 코드를 모듈식으로 유지하고 긴밀한 결합을 줄입니다.

예: 사용자 인증과 로깅을 모두 처리하는 클래스를 상상해 보세요. 로깅 작동 방식을 변경해야 하는 경우 인증 클래스도 수정하게 됩니다. 이는 SRP를 위반합니다. 대신, 두 개의 별도 클래스가 있어야 합니다. 하나는 사용자 인증용이고 다른 하나는 로깅용이므로 각 클래스는 단일 책임을 갖습니다.

O: 개방형/폐쇄형 원칙(OCP)

• 코드 단위는 확장을 위해 열려 있어야 하고 수정을 위해 닫혀 있어야 합니다.
• 기존 코드를 수정하지 않고 새 코드를 추가하여 기능을 확장합니다.
• React 프론트엔드와 같은 구성요소 기반 시스템에 유용합니다.

예: 신용 카드를 통해 결제를 처리하는 결제 처리 시스템을 생각해 보세요. 기존 코드를 수정하는 대신 PayPal에 대한 지원을 추가해야 하는 경우 PayPal 결제를 위한 새 클래스를 추가하여 확장해야 합니다. 이를 통해 기존 시스템을 안정적으로 유지하면서 새로운 기능을 추가할 수 있습니다.

L: Liskov 대체 원칙(LSP)

• 하위 클래스는 기본 클래스를 대체할 수 있어야 합니다.
• 기본 클래스의 기능은 모든 하위 클래스에서 사용할 수 있어야 합니다.
• 하위 클래스가 기본 클래스 기능을 사용할 수 없는 경우 기본 클래스에 있어서는 안 됩니다.

예: fly() 메서드가 있는 Bird 클래스가 있고 날 수 없는 하위 클래스 Penguin을 만드는 경우 이는 LSP를 위반합니다. Penguin 클래스는 예상되는 동작을 변경하므로 fly()를 상속해서는 안 됩니다. 대신, 날 수 있는 새와 날 수 없는 새를 다르게 처리하도록 Bird 클래스를 리팩터링해야 합니다.

I: 인터페이스 분리 원칙(ISP)

• 몇 가지 범용 인터페이스가 아닌 여러 특정 인터페이스를 제공합니다.
• 클라이언트는 자신이 사용하지 않는 방법에 의존해서는 안 됩니다.

예: fly(), swim() 및 walk() 메소드가 있는 Animal 인터페이스가 있다고 가정합니다. Animal을 구현하는 클래스 Dog는 필요하지 않은 fly()를 정의해야 합니다. ISP를 준수하려면 Animal 인터페이스를 Flyable, Swimmable 및 Walkable과 같은 더 작은 인터페이스로 분할하여 클래스에 관련 없는 메서드를 강제하는 것을 방지해야 합니다

D: 종속성 역전 원칙(DIP)

• 구체적인 클래스가 아닌 추상화에 의존합니다.
• 추상화를 사용하여 시스템 부분 간의 종속성을 분리합니다.
• 인터페이스나 추상화를 사용하는 코드 단위 간의 직접 호출을 피하세요.

예: 전자 상거래 애플리케이션에서 결제 프로세스(상위 수준 모듈)가 PayPal(하위 수준 모듈)과 같은 특정 결제 게이트웨이에 직접적으로 의존하는 경우 결제 게이트웨이를 변경하려면 결제 프로세스를 수정해야 합니다. PaymentProcessor 인터페이스와 같은 추상화를 도입함으로써 결제 프로세스는 PayPal이나 다른 서비스의 세부 사항을 알 필요 없이 모든 결제 방법으로 작동할 수 있습니다.

디자인 패턴

디자인 패턴은 소프트웨어 디자인에서 발생하는 일반적인 문제에 대한 입증된 솔루션입니다. 이는 개발자가 특정 설계 문제를 효율적이고 체계적으로 해결하기 위해 따를 수 있는 모범 사례입니다. 디자인 패턴은 바퀴를 재발명하는 대신 반복되는 문제를 해결하기 위한 표준 접근 방식을 제공합니다.

디자인 패턴은 세 가지 유형으로 분류할 수 있습니다.

1. 창조 패턴: 객체 생성 처리

   • 공장 설계 패턴
   • 추상적인 공장 디자인 패턴
   • 빌더 디자인 패턴
   • 프로토타입 디자인 패턴
   • 싱글턴 디자인 패턴

2. 구조적 패턴: 객체 구성 및 관계 처리

   • 어댑터 패턴
   • 브릿지 패턴
   • 복합 패턴
   • 데코레이터 패턴
   • 외관 패턴
   • 플라이웨이트 패턴
   • 프록시 패턴

3. 행동 패턴: 대상 상호작용 및 책임 다루기

   • 책임 사슬 패턴
   • 명령 패턴
   • 통역사 패턴
   • 중재자 패턴
   • 메멘토 패턴
   • 관찰자 패턴
   • 상태 패턴
   • 전략 패턴
   • 템플릿 메소드 패턴
   • 방문자 패턴

이제 SOLID 원칙을 탐구하여 기반을 마련하고 디자인 패턴의 광범위한 환경을 소개했으므로 더 깊이 알아볼 준비가 되었습니다! 다가오는 시리즈에서는 실제 사례와 실제 시나리오를 통해 각 디자인 패턴을 분석하겠습니다. 이제 막 디자인 여정을 시작하거나 기술을 연마하려는 경우 이러한 패턴은 더욱 깔끔하고 확장 가능한 코드를 작성하는 데 도움이 됩니다. 첫 번째 디자인 패턴을 단계별로 풀어내는 다음 블로그를 계속 지켜봐 주시기 바랍니다!

여기까지 오셨다면 좋아요를 누르고 질문이나 생각이 있으시면 아래에 댓글을 남겨주세요. 귀하의 피드백은 저에게 큰 의미가 있으며 귀하의 의견을 듣고 싶습니다!