SOLID가 무엇인가?

객체지향 설계의 5원칙이라 부릅니다.

SRP

OCP

LSP

ISP

DIP

앞글자를 따 SOLID 라 부릅니다.

"이 밤의 끝을 잡고~" 가 아닙니다.

SRP : the Single Responsibility Principle ( 단일 책임의 원칙 )

  하나의 클래스는 하나의 Method만 가짐으로써 수정에 대한 이유가 여러개가 되어서는 안됩니다.

  가령 글쓰기 기능에 "회원의 정보를 받아오고, 작성된 글 정보에 회원의 이름을 삽입하고, 그뒤 데이터베이스에 Insert를 하고, 글을 쓴 회원에게 일정의 포인트를 지급한다" 라는 로직이 코딩되어 있다면, 이것은 총 4개의 책임이 생기게 됩니다. 

1. 회원의 정보를 가져오는 부분의 수정
2. 작성된 글 정보에 회원의 이름을 넣는 부분의 수정
3. 데이터베이스에 글을 Insert 하는 부분의 수정
4. 일정의 포인트를 지급하는 부분의 수정.

  SRP 원칙에 따른다면 글쓰기 기능은 데이터베이스에 글을 Insert 하는 기능만 존재해야 합니다. 그래야 수정에 대한 책임이 단 하나만 생기는 것이지요.

OCP : the Open Closed Principle ( 개방 폐쇠의 원칙 )

  하나의 클래스는 수정에는 폐쇠되어 있고, 확장에는 개방되어 있어야 합니다.

  다형성과 추상화에 관련된 내용으로써, 기능의 수정 및 추가 가 필요하다면, 직접적인 수정이 되어서는 안되며, 상속을 통한 확장으로 기능 개선이 이루어져야 한다는 원칙입니다.

  변할수 있는 로직과 변할 수 없는 로직을 구분해 변할 수 있는 로직을 추상화 시켜야 합니다.

  가령, 회원이 글을 쓸수 있는 것은 변하지 않습니다. 하지만 어떤 글을 쓸 수 있는지는 계속 변경될 수 있습니다. 글을 쓴다는 추상화와 어떤 글을 쓸것인지에 대한 구체화가 분리되고 구체화는 Interface 의 Implement 로 구현됩니다.

LSP : the Liskov Substitution Priciple ( 리스코프 치환의 원칙 )

  상속을 받고있는 Class 라면 Super Class를 파라미터로 받는 메소드에 Sub Class를 던질 수 있어야 합니다.

  상속을 받는 다는것은 Super Class의 속성과 기능을 그대로 사용할 수 있음을 뜻합니다. 또한 상속을 IS-A 관계로 표현함에 있어서 이 원칙은 너무나도 당연한 원칙일 수 밖에 없습니다. Sub Class is a Super Class 가 된다는 것이지요. 따라서 Super Class를 파라미터로 받는 Method는 Sub Class를 파라미터로 보내도 문제가 없어야 합니다.

ISP : the Interface Segregation Principle ( 인터페이스 분리의 원칙 )

  사용자에게 필요하지 않는 method는 제공하지 않고 필요한 기능만 interface를 통해 제공해야합니다.

  일반회원에게 admin에 관련된 기능을 제공해서는 안되겠죠.

DIP : the Depedency Inversion Principle ( 의존성 역전의 원칙 )

  소스는 절대 interface로만 구현되어야 하며, implemenation class를 알아서도, 알 필요도 없어야 합니다.

  변경에 대한 부담과 기능 추가에 대한 부담이 소스에 직접적으로 가해지지 않도록 철처리 분리시켜야 한다는 원칙으로서 기능 변경 및 확장에 꼭 필요한 원칙입니다. Spring DI는 이 원칙을 사용합니다.

출처: http://developtip.tistory.com/keylog/SOLID