예제와 함께 일반적인 디자인 원칙에 대한 자세한 설명

디자인 원칙은 디자인 패턴이 구축되는 기초를 형성합니다. 입증된 디자인 원칙을 따르면 코드가 더욱 유연해지고, 변경에 대한 복원력이 향상되며, 유지 관리가 더욱 용이해집니다.

공통 디자인 원칙

• 단순성 원칙(KISS)
  KISS 원칙의 목표는 코드를 단순하되 너무 단순하지 않게 유지하여 불필요한 복잡성이 발생하지 않도록 하는 것입니다.

• DRY(반복하지 마세요)
  BRY 원칙이지만 그 목적은 공통이지만 부품을 꺼내어 별도의 장소에 배치하여 시스템의 어떤 부분도 중복되지 않도록 하는 것입니다. 물론, 피하고 있는 것은 코드만이 아니라 비즈니스 로직이기도 합니다.

• 말하고 묻지 마세요
  이 원칙은 개체의 상태에 대해 질문한 다음 개체가 수행하기를 원하는 작업을 결정하는 대신 개체에 수행하려는 작업을 알려야 함을 나타냅니다. 이는 책임을 일치시키고 클래스 간의 긴밀한 결합을 방지하는 데 도움이 됩니다.

• 필요하지 않음(YAGNI)
  이 원칙은 필요할 수 있다고 생각되는 다른 기능을 추가하지 않고 애플리케이션에 반드시 있어야 하는 기능만 포함하는 것을 의미합니다.

• 관점 분리(SoC)
  SoC는 소프트웨어를 별개의 기능으로 분해하는 프로세스입니다. 각 기능은 다른 클래스에서 사용할 수 있는 고유한 동작과 데이터를 캡슐화합니다. 일반적으로 우려 사항은 클래스의 기능이나 동작을 나타냅니다. 프로그램을 독립적인 책임으로 나누면 코드 재사용, 유지 관리 가능성 및 테스트 가능성이 크게 향상됩니다.

S.O.L.I.D 디자인 원칙

• 단일 책임 원칙(SRP)
  SRP는 우려 사항 분리 원칙과 매우 일치합니다. 각 객체에는 하나의 책임 초점만 있어야 합니다. 즉, 클래스 변경에 대한 이유는 하나뿐입니다.

• 개방형 원칙(OCP)
  이 원칙은 클래스가 확장을 위해 열려 있고 수정을 위해 닫혀 있어야 클래스의 내부 동작을 변경하지 않고도 클래스에 새로운 기능을 추가할 수 있어야 함을 요구합니다. 그리고 클래스가 파괴되어 불필요한 오류나 버그가 발생하는 것을 방지하세요.

• Liskov 대체 원칙(LSP)
  모든 상위 클래스는 동작을 변경하지 않은 채 하위 클래스로 대체할 수 있어야 합니다. 변경 원칙은 상속된 클래스가 상위 클래스의 동작에 영향을 미치지 않도록 보장하는 OCP 원칙과 일치합니다.

• 인터페이스 분리 원칙(ISP)
  ISP 원칙은 인터페이스 방법을 책임에 따라 여러 그룹으로 나누고 이러한 그룹에 서로 다른 인터페이스를 할당하는 데 중점을 둡니다. 클라이언트가 거대하고 사용되지 않는 인터페이스를 구현하지 않도록 하세요.

• DIP(종속성 반전 원칙)
  DIP 원칙의 목적은 작성하는 클래스를 특정 구현에서 분리하여 이러한 클래스가 추상화 또는 인터페이스에 의존하도록 하는 것입니다. 이는 코드가 특정 구현과 긴밀하게 결합되지 않도록 보장하여 사악한 시스템의 유연성을 높이는 인터페이스 지향 프로그래밍을 장려합니다.

• DI(종속성 주입) 및 SoC(제어 반전) 원칙
  DI, SoC 및 DIP는 밀접하게 연결되어 있습니다. DI는 생성자, 메서드 또는 속성을 통해 하위 수준 또는 하위 클래스를 제공합니다. DI 원칙의 사용과 함께 이러한 하위 클래스는 인터페이스 또는 추상 클래스로 반전될 수 있으므로 높은 테스트 가능성과 쉬운 수정을 갖춘 낮은 결합 시스템을 형성할 수 있습니다.

ASP.NET 디자인 패턴:

위 내용은 예제와 함께 일반적인 디자인 원칙에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!