더 좋은 클래스 설계를 위해 알아야할 프로그램 5대원칙

클래스 설계를 위해 어떤 클래스 설계가 좋은지에 대해 찾아보다보니
객체지향 소프트웨어 설계에 대해 자세히 알고 싶어졌고
그에 대한 많은 원칙들이 존재한다는 것을 알게 되었는데요.
그중 5가지 원칙을 중심으로 살펴보겠습니다.

---

그전에 알아야할 개념

---

의존관계

• 소프트웨어는 변한다는 것을 받아들이고 변경을위한 디자인이 항상 필요해왔다.
  변화에 유동적으로 반응하기위해 새로운 의존관계를 생성 또는 변경시킨다.
  이러한 개념을 쉽게 적용 및 이해하기위해 응집도와 결합도라는 개념이 있다.

응집도란?

• '하나의 클래스가 하나의 기능을 온전히 담당하는 정도'를 의미한다.
  응집도가 높아질수록. 프로그램은 단순 명쾌해진다.

결합도란?

• '클래스간의 서로 다른 책임이 얽혀있는 정도'를 뜻한다.
  결합도가 높을수록 코드가 연결고리가 많아짐으로 코드 보기가 복잡하고 힘들다.

즉 높은 응집도와 낮은 결합도를 갖는 원칙은 고전적 개념이자 원리인것이다.

---

그럼 상세히 프로그램 5대원칙을 알아보겠습니다.

1. 단일 책임의 원칙(SRP;Signle Responsibility Principle)

• 객체는 하나의 책임만 맡아야한다
  하나의 클래스는 하나의 책임만 맡아야한다. 하나이상을 맡게되면 결합도가 커지며 변경이 어려워진다.
  예로 DB클래스가 있다면 이 클래스는 오직 데이터베이스와 관련하여 수행되어야된다.

2. 의존관계 역전의 원칙(DIP;Dependency Inversion Principle)

• 클라이언트는 구체 클래스가 아닌 인터페이스나 추상클래스에 의존해야한다
• 왜? 인터페이스에 의존하도록하면 향후 변화개셩겼을때 객체 생성부분만 수정하여 유동적으로 처리할 수 있기때문이다.

3. 인터페이스 분리의 원칙(ISP;Interface Segragation Principle)

• 클라이언트에 특화된 여러개의 인터페이스가 하나의 범용 인터페이스보다 낫다
  쉽게말해 인터페이스를 어느정도 세분화 할 필요가 있다는 것이다.
  이말은 결합도를 낮추는 방법이 될 수 있다. 언제나 그렇듯이 적당한 세분화가 필요하다

4. 리스코프대체(치환) 원칙(LSP; Liskov Subtitution Principle)

• 기반 클래스는 파생 클래스로 대체 가능해야한다"
  자식이 부모의 메서드 중 일부를 거부하면 안된다는 의미다.
  부모클래스의 메서드를 받지않으면 그것 자체가 올바른 상속구조가 아니라는 것을 말해준다.

5. 개발폐쇄의 원칙 (OCP;Open Closed Principle)

• 모듈은 확장에는 열려있어야하고 변경에는 닫혀있어야한다
  은닉화 라는 표현이 존재한는 이유중 하나일 거란 생각이든다. 변경하려는 것을 getter/setter로 보호하는것은 변경에는 닫혀있는 경우 일 것이다. 허나 수평적인 확장은 용이해야 한다는 의미다.예를 들면 인터페이스 추가로 손쉽게 새로운 기능을 추가하는 것이다.

출처:https://yenos.tistory.com/entry/설계-소프트웨어의-설계-기본[Yenos's..]