SOLID

SOLID

로버트.C.마틴은 긴 세월 동안 수 많은 시행착오와 Best Practice 속에서 객체 지향 설계의 정수라 할 수 있는 5원칙이 집대성 되었는데 그것이 SOLID다.

객체지향 프로그램을 잘 개발하고 설계하기 위한 5원칙 SOLID에 대해서 알아보자.

 

단일 책임 원칙(SRP, Single Responsibillity Principle):

• 어떤 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 한다.

• 너무 책임이 너무 많을 경우, 변화가 생겼을 때 다른 연관 클래스에 영향을 줌

• EX) 남자 클래스가 여자친구, 부모, 상사, 친구 클래스와 상호작용할 수 있게 구현되어 있을 때,
  여자친구와의 연관성을 끊을 경우 그 변화의 영향도가 관련된 모든 클래스에게 뻣친다.

• SOC(Seperate of Concern, 관심사 분리): 관심사가 분리되지 않으면 변화가 생겼을 때 연관 클래스에 영향을 줌

• SoC(Seperation of Concerns, 관심사 분리)
  관심이 같은 것끼리는 하나의 객체 안으로 또는 친한 객체로 모으고, 관심이 다른 것은 가능한 한 따로 떨어져 서로 영향을 주지 않도록 분리하라는 것이다.

• 토비: "변화의 시기와 떄와 이유가 다르다면 분리가 필요하다"

• 클래스를 나눠서 여러 개 클래스를 나눔

• 부동산 클래스: 아파트, 주택 사용하는 필드가 달라짐.

 

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

• 자신의 확장에는 개방돼 있고, 주변의 변화에 대해서는 폐쇄돼 있어야 한다.
• 소프트웨어 엔티티(클래스, 모듈, 함수) 는 확장에 대해서는 개방돼야 하지만 변경에 대해서는 폐쇄되야 한다.
• 사람 → 자동차 (마티즈, 소나타)
• 넘버 - 더블, 플로트, 롤, 빅 디시멀, 빅 인티져
• 인풋 스트림 - 확장 클래스 종류가 정말 많음.

 

리스코프 치환 원칙(LSP, Liskov substitution principle)

• 서브 타입은 언제나 자신의 기반 타입으로 교체할 수 있어야 한다.
• 상속
  • 객체 지향에서의 상속은 조직도가 계층도가 아닌 분류도가 돼야 한다.
  • 객체 지향의 상속 조건
    • 하휘 클래스 is kind of 상위 클래스: 하위 분류는 상위 분류의 한 종류다.
      • ex) 동물 - 펭귄
    • 구현 클래스 is able to interface: 구현 분류는 인터페이스 할 수 있어야 한다.
      • ex) 펭귄은 날 수 있어야 한다.

 

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

• 클라이언트는 자신이 사용하지 않는 메서드에 의존관계를 맺으면 안된다.
• 기존 클래스가 여러 책임을 가지고 있어 분리할 수 없을 때 인터페이스를 만들어 그 책임을 분리하는 원칙.
• ex) 남자란 클래스가 남자친구, 아들, 사원, 친구의 역할을 모두 수행하지만, 이 클래스를 개별 클래스로 쪼갤 수 없을 때 인터페이스로 분리하는 것을 말한다.
• 이와 같이 분리된 작은 단위들을 역할 인터페이스라고도 부른다.
• ISP와 SRP는 하나의 문제를 해결하는 두 가지의 서로 다른 방법이라고 볼 수 있다.
• 할 수 있다면, SRP가 더 좋음.
• 풍성한 하위 클래스 보단 풍성한 상위 클래스로 개발!

 

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

• 자신보다 변하기 쉬운 것에 의존하지 마라.
• 고차원 모듈은 저차원 모듈에 의존하면 안 된다. 이 두 모듈 모두 다른 추상화된 것에 의존해야 한다.
• 추상화된 것은 구체적인 것에 의존하면 안 된다. 구체적인 것이 추상화된 것에 의존해야 한다.
• 자주 변경되는 구체 (concrete)클래스에 의존하지 마라.
• 상위 클래스일수록, 인터페이스 일수록, 추상 클래스일 수록 변하지 않을 가능성이 높기에
  하위 클래스나 구체 클래스가 아닌 상위 클래스, 인터페이스, 추상 클래스를 통해 의존하라는 것이 바로 의존 역전 원칙이다.
• DI(Dependency Injection) 는 DIP을 실현하는 방법.
• ex) 자동차와 타이어

 

결론

SOLID 원칙을 적용하면 소스 파일의 개수는 더 많아지는 경향이 있다. 하지만 이렇게 많아진 파일들이 논링를 더욱 잘 분할하고, 잘 표현하기에 이해하기 쉽고, 개발하기 쉬우며, 유지와 관리, 보수하기 쉬운 소스가 만들어진다. SOLID 원칙을 적용함으로써 얻는 혜택에 비하면 늘어나는 소스 파일 개수에 대한 부담은 충분히 감수하고도 남을 만한다.

 

참고 자료

• https://www.youtube.com/watch?v=nrlHZBAXjv8