S.O.L.I.D - 객체지향 설계의 가장 큰 원리

객체지향적 프로그래밍을 할때에는 S.O.L.I.D 라고 불리는 5가지 큰 원리를 따라서 설계를 해야 한다.

이것들은 GRASP(General Responsibility Assignment Software Patterns) 소프트웨어 일반 책임 적용 패턴 9가지로 세분화할 수 있다.

---

S : Single Responsibility Principle 단일 책임 원칙

• 모든 클래스는 단 하나의 분명한 역할 만을 책임져야 한다. 클래스를 수정할 이유가 단 하나여야 한다.
• DO THIS!
  총 클래스가 있을때, 총은 플레이어가 입력을 할 때마다 총알을 생성한다. 이것이 총 클래스가 할 일의 거의 전부다.
• DON'T DO THIS!
  생성된 총알이 무엇과 충돌하고 어떤 결과를 야기하는 지에 대해서는 전혀 관여하지 않는다.

O : Open Closed Principle 개방 폐쇄 원칙

• 소프트웨어 엔티티들은 확장에 대해서는 개방 되어 있어야 하지만, 수정에 대해서는 폐쇄 되어야 한다.
• DO THIS!
  몬스터를 하나 생성한다고 할때, 각 몬스터의 행동이 다를 경우 행동 패턴 구현을 하위 클래스에서 한다면 객체의 패턴만 재정의 하면 된다. (확장에 대한 개방)
• DON'T DO THIS!
  몬스터 클래스의 수정은 필요가 없다.(수정에 대해 폐쇄)

L : Liskov Substitusion Principle 리스코프 치환 원칙

• 자식 클래스는 언제나 자신의 부모클래스를 교체할 수 있다는 원칙이다.
  대략 아래 코드와 같다.

Programmer p = new Programmer;
Human h = (Human)p;

I : Interface Segregation Principle 인터페이스 분리 원칙

• 클라이언트가 자신이 사용하지 않는 메소드에 의존하지 않아야 한다는 원칙이다.
• DO THIS!
  일반적인 클래스를 하나 구현해서 사용하지도 않는 함수를 implement 시키지 말고, 여러 개의 구체적인 클래스를 생성해 implement 시키자.
• DON'T DO THIS!
  Fat Class(함수가 몇십, 몇백개 가지는 클래스)를 만들고 싶은 사람은 없지만 경우에 따라 불가피하게 만들때도 있다. 이 클래스는 덩치가 큰 것도 문제라고 할 수 있지만 실제 이 안에서 사용되는 함수는 몇개 안될 수도 있다. 하지만 유저는 자신이 사용하지도 않은 함수에서 생긴 변화에도 영향을 받게 된다.

D : Dependency Inversion Principle 의존성 역전 원칙

• 상위클래스는 하위클래스에 의존해서는 안된다는 원칙이다.