객체지향 SOLID

SOLID

solid는 약자로 이루어져있습니다.

S → single responsiblity: 단일 책임의 원칙

O → open closed: 개방 폐쇄 원칙

L → Liskov subsituation: 리스코프 치환 원칙

I → interface segregation: 인터페이스 분리 원칙

D → dependency inversion: 의존 역전 원칙

단일 책임의 원칙

객체는 한 가지 역할(책임)만 가져야 한다. = 객체가 변경되는 이유는 단 한가지여야 한다.

책임은 변경의 축이기 때문에 분할되는 것이 중요하다.

→ 여러개의 책임을 가지게 된다면 요구사항의 변경이 일어났을 때 연쇄적인 변화가 발생할 것이다.

어떻게 해결할 수 있나

추상화를 통해 객체를 설계하는 과정에서 적절한 한 개의 역할만 갖도록 구상

→ 책임의 분배는 정답이 없기 때문에 경험이 중요하다

개방 폐쇄 원칙

객체는 확장에 열려있고 변경에는 닫혀있어야 한다.

확장에 열려있다 → 객체의 행위가 확장될 수 있다. 행위를 추가해 객체가 하는 일을 바꿀 수 있다.

변경에 닫혀있다 → 객체의 확장이 소스 코드의 변경을 초래하지 않아야 한다.

왜 지켜야 하나

기존 코드를 쉽게 확장할 수 있으므로 유연성, 재사용성, 유지보수성을 얻을 수 있다.

어떻게 해결할 수 있나

객체에 새로운 기능이 추가될 때 코드의 변경 없이 확장이 이뤄져야 한다.

모듈은 잘 변하지 않는 추상화에 의존해 수정에는 닫혀있고 추상화의 구현체를 추가해 확장에는 열려있게 된다.

리스코프 치환 원칙

서브 타입은 자신의 기반 타입으로 교체할 수 있어야 한다.

= 하위 클래스가 상위 클래스로 바뀌어도 역할 수행에 문제가 없어야 한다.

= 서브 타입은 기반 타입이 정해둔 약속을 지켜야 한다.

왜 지켜야 하나

리스코프 치환 원칙의 위반은 곧 개방 폐쇄 원칙의 위반하는 것과 같기 때문이다.

개방 폐쇄 원칙은 상속을 통해 이루어지고 리스코프 치환 원칙은 규약이 준수된 상속 구조를 보장한다.

기반 타입으로 대체가 안되면 구현체가 들어왔을 때 적절한 역할의 수행이 어렵다.

리스코프 치환 원칙은 어떻게 지킬 수 있는가?

• 하위 클래스 is - a 상위 클래스
• 구현 클래스 is able to 인터페이스

이 두 관계가 지켜지면 된다.

행위에 대한 is - a 관계도 잘 생각해봐야 한다.

ex) 직사각형 정사각형

• 정사각형 is - a 직사각형 ⇒ 어색하지 않음
• 정사각형의 높이 변경 is - a 직사각형의 높이 변경 ⇒ 어색하게 느껴짐

인터페이스 분리 원칙

인터페이스는 자신의 클라이언트가 사용할 메서드만 가지고 있어야 한다.

= 클라이언트는 자신이 사용하지 않는 메서드에 의존하게 강제되면 안된다.

왜 지켜야 하나

인터페이스가 비대해지면 같은 인터페이스를 구현하는 클라이언트간의 결합도가 높아진다

→ 특정 클라이언트를 위한 메서드를 추가 할 때, 다른 클라이언트에서도 구현이 강제되고 변경에 영향을 끼친다.

어떻게 해결할 수 있나?

자신의 클라이언트가 필요로하는 함수만 선언한다.

⇒ 인터페이스의 역할에 충실한 기능만 제공한다.

의존 관계 역전 원칙

구체적인 것이 추상화 된 것에 의존해야 된다. → 자주 변경되는 것(구체적인 것)에 의존하지 말아라

왜 지켜야 하나

상위 객체는 애플리케이션의 본질을 담고 정책을 결정하는 역할

하위 수준의 객체에 의존하면, 하위 수준의 변화가 상위 객체에 영향

구체적인 것의 변화에 따라 규칙이 변한다 ⇒ 어색하게 느껴진다.

추상화를 자유롭게 재사용하기 위함

만약, 상위가 하위 객체에 의존을 가지고 있다면 맥락에 맞게 재사용 변경해 재사용 불가

즉, 추상화가 구체적인 것에 의존하면 추상화를 자유롭게 재사용할 수 없다

어떻게 해결할 수 있나?

의존성은 이행적이다.

→ 한 레이어는 의존하고 있는 다른 레이어의 의존에도 의존하게 된다.

동일 레벨에서는 추상화를 의존하고 하위 레벨은 상위 레벨은 의존하게 만든다