SOLID 와 소프트웨어 디자인 패턴

SOLID (객체지향 설계 원칙)

---

 SOLID 원칙은 다음과 같은 다섯 가지 원칙의 앞글자를 따서 이름이 지어졌다.

 

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

 

 이 원칙들은 객체지향 설계를 할 때, 좀 더 유연하고 유지보수하기 쉬운 코드를 작성하기 위해 고안된 원칙들이다. 각각의 원칙은 아래와 같이 설명된다.

 

1. 단일 책임 원칙(SRP) - 객체는 단 하나의 책임만 가져야 한다.
2. 개방-폐쇄 원칙(OCP) - 확장에는 열려 있으나 수정에는 닫혀 있어야 한다.
3. 리스코프 치환 원칙(LSP) - 자식 클래스는 언제나 부모 클래스를 대체할 수 있다.
4. 인터페이스 분리 원칙(ISP) - 클라이언트는 자신이 이용하지 않는 메서드에 의존 관계를 맺으면 안 된다.
5. 의존 역전 원칙(DIP) - 추상화에 의존해야지, 구체화에 의존하면 안 된다.

 

 이 원칙들은 객체지향 설계의 기본 원칙이며, 이를 지키면서 코드를 작성하면 유지보수성이 좋아지고 유연성이 증가하여 변화에 대응하기 쉬운 코드를 작성할 수 있다. 

 

 소프트웨어 디자인 패턴을 설명하기 전에 SOLID 원칙에 대해 설명한 이유는 SOLID 원칙을 지키기 위한 방법중 하나가 바로 소프트웨어 디자인 패턴을 사용하는 것이기 때문이다.

 

 

소프트웨어 디자인 패턴이란?

---

소프트웨어 디자인 패턴(software design pattern)은 소프트웨어 공학의 소프트웨어 디자인에서 특정 문맥에서 공통적으로 발생하는 문제에 대해 재사용 가능한 해결책이다. 소스나 기계 코드로 바로 전환될수 있는 완성된 디자인은 아니며, 다른 상황에 맞게 사용될 수 있는 문제들을 해결하는데에 쓰이는 서술이나 템플릿이다. 디자인 패턴은 프로그래머가 어플리케이션이나 시스템을 디자인할 때 공통된 문제들을 해결하는데에 쓰이는 형식화 된 가장 좋은 관행이다. 간단히 말하면

"효율적인 코드를 만들기 위한 방법론" 이라고 생각하면 된다. 우리는 좋은 개발자가 되기 위해 소프트웨어 디자인 패턴에 대해 이해를 해야 할 것이다.

 

 

소프트웨어 디자인 패턴의 종류

---

소프트웨어 디자인 패턴
GoF 패턴	생성 패턴	Sigleton Pattern, Factory method Pattern, Prototype Pattern
	구조 패턴	Proxy Pattern
	행위 패턴	Strategy Pattern, Observer Pattern, Command Pattern
아키텍처 패턴	MVC, MVP, MVVM

 우리가 디자인 패턴을 검색할 때 인터넷에는 디자인 패턴을 설명하는 글이 많다. 하지만 어떤 글에서는 GoF 패턴을 설명하고 어떤 글에서는 아키텍처 패턴을 설명한다. 여기서 우리는 혼란스러워하게 되는데 결론은 GoF 패턴과 아키텍처 패턴은 둘 다 소프트웨어 디자인 패턴 아래 존재하고 아키텍처 패턴이 GoF보다 조금 더 포괄적인 디자인 패턴을 말한다. 아키텍처 패턴은 한 소프트웨어의 뼈대와 기반을 담당하고, GoF 패턴은 각각의 기능을 담당한다고 볼 수 있다.

 

우리는 좋은 소프트웨어를 만들기 위해 소프트웨어 디자인을 해야 한다. 그래서 우리는 많이 사용되는 소프트웨어 디자인 패턴들에 대한 이해를 가지고 우리의 소프트웨어에 어떤 패턴을 적용해야 하는지 선택해야 할 것이다.

 

 

 

SOLID에 따른 디자인 패턴 사용

---

단일 책임 원칙

 단일 책임 원칙을 지키기 위해서는 한 클래스가 하나의 기능만 수행하도록 만들어야 한다. 이를 위해 Facade 패턴이나 Proxy 패턴을 사용하여 클래스의 책임을 분리할 수 있다.

 

개방-폐쇄 원칙

 개방 폐쇄 원칙을 지키기 위해서는 코드 수정 없이 새로운 기능을 추가할 수 있도록 설계해야 한다. 이를 위해 Strategy 패턴이나 Template Method 패턴 등을사용하여 새로운 기능을 추가하거나 변경할 수 있도록 유연성을 높일 수 있다.

 

리스코프 치환 원칙

 리스코프 치환 원칙을 지키기 위해서는 자식 클래스가 부모 클래스와 호환성을 유지해야 한다. 이를 위해 Template Method 패턴이나 Decorator 패턴 등을 사용하여 자식 클래스의 행동을 제어하거나 확장할 수 있다.

 

인터페이스 분리 원칙

 인터페이스 분리 원칙을 지키기 위해서는 클라이언트가 필요로 하지 않는 메서드를 포함하지 않는 인터페이스를 설계해야 한다. 말이 좀 어려운데 자신이 사용하지 않는 메서드에 대한 의존관계를 맺으며 안된다는 것이다. 이를 위해 Adapter 패턴이나 Bridge 패턴 등을사용해 인터페이스의 책임을 분리할 수 있다.

 

의존 역전 원칙

 의존 역전 원칙을 지키기 위해서는 추상화에 의존해야 한다. 이를 위해 Abstract Factory 패턴이나 Dependency Injection 패턴 등을 사용하여 구체 클래스에 대해 의존성을 낮추고, 추상화된 인터페이스나 클래스에 의존하도록 만들 수 있다.

 

 

 

 

  

 

 

Reference

소프트웨어 디자인 패턴 - 위키백과, 우리 모두의 백과사전

 

아키텍처 패턴과 디자인 패턴의 차이점