소프트웨어 개발은 마치 공학과 같습니다. 핵심 부분이 망가지면 모든 것이 실패합니다. 이를 어떻게 방지할 수 있을까요? 물론, 프로그램을 테스트할 수 있지만 그것만으로는 충분하지 않을 수 있습니다. 모든 테스트를 통과한 프로그램이라 하더라도 여전히 다른 문제가 있을 수 있습니다:

설계가 제대로 되지 않았을 경우, 문제점

• 나쁜 설계일 수 있어 아무도 사용하지 않을 수 있습니다.
• 어떤 부분도 확장할 수 없어 새로운 기능을 추가할 수 없을 수 있습니다. 왜냐하면 어떻게 작동하는지 이해하기 어렵기 때문입니다.

SOLID
일관된 디자인 원칙이란 없습니다. 왜냐하면 프로그램이 커짐에 따라 복잡해지기 때문입니다. 프로그램을 다양한 복잡성으로부터 관리하는 데 도움이 되는 다양한 접근 방식에 익숙해져야 합니다. 우리의 목표에 대한 경로를 매끄럽게 만들기 위해 SOLID 디자인 원칙에 의존할 수 있습니다.

SOLID는 각 글자가 다른 디자인 원칙을 나타냅니다:

Single Responsibility Principle (SRP): 단일 책임 원칙
Open-Closed Principle (OCP): 개방 폐쇄 원칙
Liskov Substitution Principle (LSP): 리스코프 치환 원칙
Interface Segregation Principle (ISP): 인터페이스 분리 원칙
Dependency Inversion Principle (DIP): 의존성 역전 원칙

SOLID DESIGN PATTERN

Open-Closed Principle (OCP): 개방 폐쇄 원칙

The Open-Closed Principle - Software entities should be open for extension, but closed for modification

이미지 형식 처리: 어떤 원칙을 적용하고 있나요?
다음 시나리오를 고려해보세요: 여러 이미지 파일 형식 (JPEG, PNG, GIF 등)을 처리하는 소프트웨어 컴포넌트를 개발 중입니다. 방금 배운 디자인 원칙에 따라 앞으로 <새로운 이미지 형식을 지원하기 위해> 전체 컴포넌트를 수정할 필요가 없도록 소프트웨어를 구현하려고 합니다. 이 경우에는 어떤 소프트웨어 구축 원칙을 가장 직접 적용하고 있을까요?

There is an option for each of this three principles:
Don't Repeat Yourself (DRY)
You Ain't Gonna Need It (YAGNI)
Keep It Simple, Stupid (KISS)