Home >Web Front-end >JS Tutorial >Low level design and SOLID Principles

Low level design and SOLID Principles

Susan Sarandon
Susan SarandonOriginal
2024-10-02 06:18:01537browse

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

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

이 블로그에서는 로우 레벨 디자인과 관련된 주요 개념, 원칙, 기법을 소개하고 이러한 내용이 더 좋고 유지 관리가 쉬운 코드를 작성하는 데 어떻게 도움이 되는지 보여줄 것입니다.

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

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

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

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

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

객체지향 원칙

Low level design and SOLID Principles
객체 지향 프로그래밍 개념 로우레벨 디자인을 배우기 시작하려면 4가지 요소가 필수입니다. 이 개념은 이미 간략한 체크아웃 블로그에서 다루었습니다

견고한 원칙

Low level design and SOLID Principles

S: 단일 책임 원칙(SRP)

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

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

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

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

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

L: 리스코프 대체 원칙(LSP)

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

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

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

  • 몇 가지 범용 인터페이스가 아닌 여러 개의 특정 인터페이스를 제공하세요.
  • 고객은 자신이 사용하지 않는 방법에 의존해서는 안 됩니다.

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

D: Dependency Inversion Principle (DIP)

  • Depend on abstractions, not concrete classes.
  • Use abstractions to decouple dependencies between parts of the system.
  • Avoid direct calls between code units use interfaces or abstractions.

Example: In an e-commerce application, if the checkout process (high-level module) depends directly on a specific payment gateway like PayPal (low-level module), changing the payment gateway requires modifying the checkout process. By introducing an abstraction, such as a PaymentProcessor interface, the checkout process can work with any payment method without needing to know the specifics of PayPal or any other service.

Design Patterns

Design patterns are proven solutions to common problems that arise in software design. They are best practices that developers can follow to solve specific design issues efficiently and systematically. Instead of reinventing the wheel, design patterns provide a standard approach to solving recurring problems.

Design patterns can be categorized into three types:

  1. Creational Patterns: Deal with object creation

    • Factory design pattern
    • Abstract factory design pattern
    • Builder design pattern
    • Prototype Design pattern
    • Singleton design pattern
  2. Structural Patterns: Deal with object composition and relationships

    • Adapter Pattern
    • Bridge Pattern
    • Composite Pattern
    • Decorator Patter
    • Facade Pattern
    • Flyweight Pattern
    • Proxy Pattern
  3. Behavioral Patterns: Deal with object interaction and responsibility

    • Chain of Responsibility Pattern
    • Command Pattern
    • Interpreter Pattern
    • Mediator Patter
    • Memento Pattern
    • Observer Pattern
    • State Pattern
    • Strategy Pattern
    • Template Method Pattern
    • Visitor Pattern

Now that we've laid the foundation by exploring the SOLID principles and introduced the vast landscape of design patterns, we're ready to dive deeper! In the upcoming series, I'll break down each design pattern with practical examples and real-world scenarios. Whether you're just starting your design journey or looking to sharpen your skills, these patterns will help you write cleaner, more scalable code. Stay tuned for the next blog, where we unravel the first design pattern—step by step!

If you've made it this far, don't forget to hit like ❤️ and drop a comment below with any questions or thoughts. Your feedback means the world to me, and I'd love to hear from you!

The above is the detailed content of Low level design and SOLID Principles. For more information, please follow other related articles on the PHP Chinese website!

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn