底层设计和 SOLID 原则

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

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

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

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

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

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

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

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

객체지향 원칙

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

견고한 원칙

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：依赖倒置原则（DIP）

• 依赖于抽象，而不是具体的类。
• 使用抽象来解耦系统各部分之间的依赖关系。
• 避免使用接口或抽象在代码单元之间直接调用。

示例：在电子商务应用程序中，如果结账流程（高级模块）直接依赖于 PayPal（低级模块）等特定支付网关，则更改支付网关需要修改结账流程。通过引入抽象，例如 PaymentProcessor 接口，结帐流程可以使用任何付款方式，而无需了解 PayPal 或任何其他服务的具体信息。

设计模式

设计模式是针对软件设计中出现的常见问题的经过验证的解决方案。它们是开发人员可以遵循的最佳实践，可以有效、系统地解决特定的设计问题。设计模式不是重新发明轮子，而是提供了解决重复出现问题的标准方法。

设计模式可以分为三种类型：

1. 创建模式：处理对象创建

   • 工厂设计模式
   • 抽象工厂设计模式
   • 构建器设计模式
   • 原型设计模式
   • 单例设计模式

2. 结构模式：处理对象组合和关系

   • 适配器模式
   • 桥梁图案
   • 复合模式
   • 装饰器模式
   • 外观图案
   • 蝇量模式
   • 代理模式

3. 行为模式：处理对象交互和责任

   • 责任链模式
   • 命令模式
   • 解释器模式
   • 调解员帕特
   • 纪念品图案
   • 观察者模式
   • 状态模式
   • 策略模式
   • 模板方法模式
   • 访客模式

现在我们已经通过探索 SOLID 原则奠定了基础，并介绍了设计模式的广阔前景，我们准备好深入研究了！在即将推出的系列中，我将通过实际示例和现实场景来分解每种设计模式。无论您是刚刚开始设计之旅还是希望提高自己的技能，这些模式都将帮助您编写更清晰、更具可扩展性的代码。请继续关注下一篇博客，我们将一步步揭开第一个设计模式！

如果您已经做到了这一步，请不要忘记点赞❤️，并在下面发表评论以提出任何问题或想法。您的反馈对我来说至关重要，我很乐意收到您的来信！

以上是底层设计和 SOLID 原则的详细内容。更多信息请关注PHP中文网其他相关文章！