SOLID (객체 지향 설계)

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

 

S ( Single responsibility principle )	단일 책임 원칙 한 클래스는 하나의 책임만 가져야 한다. 그리고 그 책임을 완전히 캡슐화해야 한다. 이것은 클래스를 더욱 튼튼하게 만들기 위함이다. 만약 한 클래스가 여러 책임을 가지고 있다면 수정 과정에서 같은 클래스의 일부 출력 코드가 망가질 위험이 대단히 높다. 클래스는 설계도 도면과 마찬가지이다. 자동차 설계도에서 자동차를 만드는 방법만 가지고 있어야하지 완전히 다른 것을 만드는 방법까지 가지고 있을 필요도 없고 가지고 있어서도 안된다.
O ( Open/closed principle )	개방-폐쇄 원칙 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다. 소프트웨어 개체( 클래스, 모듈 함수 등 )는 확장에 대해 열려 있어야 하고, 수정에 있어서는 닫혀 있어야한다. 소프트 웨어 개발을 함에 있어 모듈 중에 하나의 수정을 가할 때 그 모듈을 이용하는 다른 모듈을 줄줄이 수정해야 한다면, 이와 같은 프로그램은 수정하기 어렵다. 시스템의 구조를 올바르게 리팩토링하여 나중에 이와 같은 일이 발생하지 않도록 하는 것을 말한다. 기능을 추가하거나 수정해야 할 때 이미 제대로 동작하고 있던 원래 코드를 변경하지 않아도 기존의 코드에 새로운 코드를 추가함으로써 기능의 추가나 변경이 가능해야 한다.
L ( Liskov substitution principle )	리스코프 치환 원칙 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다. B가 A의 자식일 때, A 타입을 사용하는 부분에서 B로 치환해도 문제없이 동작이 되어야 한다.
I ( Interface segregation principle )	인터페이스 분리 원칙 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다. 클라이언트가 자신이 이용하지 않는 메소드에 의존하지 않아야 한다는 원칙이다. 큰 덩어리의 인터페이스들을 구체적이고 작은 단위들로 분리시킴으로써 클라이언트들이 꼭 필요한 메소드들만 이용할 수 있게 한다. 이 원칙을 통해 시스템의 내부 의존성을 약화시켜 리팩토링, 수정, 재배포를 쉽게 할 수 있다.
D ( Dependency inversion principle )	의존관계 역전 원칙 프로그래머는 추상화에 의존해야지 구체화에 의존하면 안된다. 상위 모듈은 하위 모듈에 의존해서는 안된다. 상위 모듈과 하위 모듈 모두 추상화에 의존해야 한다. 추상화는 세부 사항에 의존해서는 안된다. 세부 사항이 추상화에 의존해야 한다.