[Design Pattern] 객체 지향 설계 5원칙 - SOLID

 

컴퓨터 프로그래밍에서 SOLID 란 로버트 마틴이 2000년대 초반에 명명한 객체 지향 프로그래밍 및 설계의 다섯 가지 기본 원칙을 마이클 페더스가 두문자어 기억술로 소개한 것이다. 프로그래머가 시간이 지나도 유지 보수와 확장이 쉬운 시스템을 만들고자 할 때 이 원칙들을 함께 적용할 수 있다.

 

SOLID 원칙들은 소프트웨어 작업에서 프로그래머가 소스 코드가 읽기 쉽고 확장하기 쉽게 될 때까지 소프트웨어 소스 코드를 리팩터링 하여 코드 냄새를 제거하기 위해 적용할 수 있는 지침이다.

 

이 원칙들은 애자일 소프트웨어 개발과 적응적 소프트웨어 개발의 전반적 전략의 일부이다.

 

 

[참조] 

https://namu.wiki/w/%EA%B0%9D%EC%B2%B4%20%EC%A7%80%ED%96%A5%20%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D/%EC%9B%90%EC%B9%99

객체 지향 프로그래밍/원칙 - 나무위키

 

1. 단일 책임 원칙(Single Responsibility Principle, SRP)

• 객체는 오직 하나의 책임을 가져야 한다. 다시 말해 객체는 오직 하나의 변경의 이유만을 가져야 한다는 원칙이다.
• 한 가지의 객체가 여러 책임을 가지고 수행할 경우 OOP 본연의 의미가 퇴색될 뿐만 아니라 필연적으로 결합도가 높아지기 때문에 객체지향적으로 설계를 할 때는 응집도를 높게, 결합도는 낮게 설계하는 것이 좋다.

 

2. 개방-폐쇄 원칙(Open-Closed Principle, OCP)

• 객체는 확장에 대해서는 개방적이고 수정에 대해서는 폐쇄적이어야 한다는 원칙이다.
• 설계된 객체는 각각이 확장은 가능하되(Open) 변경할 필요는 없어야 한다(Closed)는 의미를 가진 이름 그대로의 원칙이다. 한번 설계가 되고 단위 테스트가 완료된 객체는 향 후 외부에 변경사항이 발생하더라도 객체 자체는 변경되지 않아야 한다는 의미로 가장 쉽게 이해할 수 있는 예는 GOF의 디자인 패턴 중 전략 패턴(Strategy Pattern)이다.

 

3. 리스코프 치환 원칙(Liskov Substitution Principle, LSP)

• 자식 클래스는 언제나 자신의 부모 클래스를 대체할 수 있다는 원칙이다.
• 부모 클래스가 들어갈 자리에 자식 클래스를 넣어도 계획대로 잘 작동해야 한다는 것으로 부모 클래스의 인스턴스가 사용된 자리에 자식 클래스의 인스턴스를 집어넣어도 코드의 맥락이 변하지 않아야 한다는 것이다.
• LSP의 만족 여부는 간단한 사고 실험으로 알아볼 수 있는데, "자식 클래스 is a kind of 부모 클래스"의 참/거짓 여부를 알아보는 방법이 있다. 예를 들어 부모 클래스가 동물이고 자식 클래스가 돼지인 경우, "돼지 is a kind of 동물" 관계가 성립함을 알 수 있다. 반면 부모 클래스가 사람이고 자식 클래스가 직장인인 경우, "직장인 is a kind of 사람" 관계는 성립하지 않음을 알 수 있다. 이는 직장인은 사람의 역할(Role) 중 하나이지 사람의 종류(Kind)가 아니기 때문이다.

 

4. 인터페이스 분리 원칙(Interface Segregation Principle, ISP)

• 인터페이스 분리 원칙은 객체 자신이 사용하지 않을 인터페이스는 구현하면 안 된다는 것이다.
• OCP 와는 엄연히 다른 원칙이지만 ISP를 잘 지키면 OCP 도 잘 지키게 될 확률이 비약적으로 증가한다.

 

5. 의존성 역전 원칙(Dependency Inversion Principle, DIP)

• 추상성이 높고 안정적인 고수준의 클래스는 구체적이고 불안정한 저수준의 클래스에 의존해서는 안된다는 원칙으로서 일반적으로 객체지향의 인터페이스를 통해서 이 원칙을 준수할 수 있게 된다.
• 절차 지향 프로그래밍의 경우, 일반적으로 main 스레드와 같은 총괄 주체가 작업에 필요한 함수들을 호출하게 된다. 즉, 보다 추상적인 객체가 구체적인 객체를 호출함으로써 추상적인 객체가 구체적인 객체에 의존하게 되는 형태가 되는 것이다. 반면 Java에서는 구체적인 객체가 추상적인 객체를 상속함으로써 구체적인 객체가 추상적인 객체에 의존하게 되는데 이로 인해 잦은 변화가 요구되는 구체적 객체의 변화에 전체적인 맥락이 영향을 덜 받을 수 있게 된다.

 

 

 

나무위키의 개념적인 내용을 보면서 작성하고 있지만 실제로 잘 적용할 수 있을지 의문이 생겨서 열심히 구글링을 한 결과 개념적인 내용을 쉽게 설명을 해놓으신 분을 찾을 수 있었다. 감사합니다.

 

 

[추천]

https://victorydntmd.tistory.com/291

[디자인패턴] SOLID 원칙