객체 지향 설계 5원칙 - SOLID

• 결합도와 응집도
  • 좋은 소프트웨어 설계를 위해서는 결합도(coupling)는 낮추고 응집도(cohesion)는 높이는 것이 이상적
  • 결합도: 모듈(클래스) 간의 상호 의존 정도로서 결합도가 낮으면 객체의 재사용이나 수정, 유지보수가 용이
  • 응집도: 하나의 모듈 내부에 존재하는 구성 요소들의 기능적 관련성으로, 응집도가 높은 모듈은 하나의 책임에 집중하고 독립성이 높아져 재사용이나 기능의 수정, 유지보수가 용이

SRP - 단일 책임 원칙

• 어떤 클래스를 변경해야 하는 이유는 오직 하나 뿐이어야 함
• 하나의 속성이 여러 의미를 가지면 안됨
• 메서드가 단일 책임 원칙을 지키지 않을 경우 분기 처리를 위한 if문이 나타남

OCP - 개방 폐쇄 원칙

• 소프트웨어 엔티티(클래스, 모듈, 함수 등)는 확장에 대해서는 열려 있어야 하지만 변경에 대해서는 닫혀 있어야 함
• 상위 클래스 또는 인터페이스를 사용하여 자신의 확장에 대해서 열려 있더라도 주변의 변화에 영향 받지 않음
• JVM, JDBC, 스프링 프레임워크

LSP - 리스코프 치환 원칙

• 서브 타입은 언제나 자신의 기반 타입(base type)으로 교체할 수 있어야 함
• 하위 클래스의 인스턴스는 상위형 객체 참조 변수에 대입해 상위 클래스의 인스턴스 역할을 하는 데 문제가 없어야 함

ISP - 인터페이스 분리 원칙

• 클라이언트는 자신이 사용하지 않는 메서드에 의존 관계를 맺으면 안됨
• SRP와 ISP는 같은 문제에 대한 다른 해결책이나, 특별한 경우가 아니면 SRP를 적용하는 것이 더 좋음
• 인터페이스 최소주의: 인터페이스를 통해 메서드를 외부에 제공할 때는 최소한의 메소드만 제공
• 상위 클래스는 풍성하게, 인터페이스는 최소한으로

DIP - 의존 역전 원칙

• 고차원 모듈은 저차원 모듈에 의존하면 안됨, 이 두 모듈 모두 다른 추상화된 것에 의존해야 함
• 추상화된 것은 구체적인 것에 의존하면 안됨
• 자주 변경되는 구체(Concrete) 클래스에 의존하면 안됨
• 변할 가능성이 낮은 상위 클래스, 인터페이스, 추상 클래스에 의존

정리 - 객체 지향 세계와 SOLID

• 관심사의 분리, SoC (Seperation Of Concerns): 관심이 같은 것끼리는 하나의 객체 안으로 또는 친한 객체로 모으고, 관심이 다른 것은 가능한 한 따로 떨어져 서로 영향을 주지 않도록 분리 → SRP, ISP, OCP
• SOLID 원칙을 적용하면 소스 파일의 개수가 많아짐
  • 논리를 더욱 잘 분할하고 잘 표현하므로 이해하기 쉬움
  • 개발 및 유지 관리가 쉬운 소스가 만들어짐