SOLID 원칙

SOLID란?

원칙은 가치를 지키기위해서 존재한다고 한다. 그렇다면 소프트웨어의 가치에는 무었이 있을까?

첫번째로는 가독성이 좋은 코드라고 할 수 있다. 개발자는 코드를 통한 커뮤니케이션을 하며, 읽고 이해할 수 없는 코드는 가치가 없기 때문이다.

두번째로는 단순해야 한다는 것이다. 이는 커뮤니케이션에 도움이 되고, 버그의 가능성이 적어지며, 추후 코드의 수정에 도움이 되기 때문이다.

마지막으로는 코드는 유연해야 한다는 것이다. 경직된 코드는 유지 보수를 어렵게 하기 때문이다.

그렇다면 위에 언급한 스프트웨어의 가치들을 지키기 위해서는 원칙이 필요하다. 이때 이러한 가치들을 지키기 위해 나온것이 SOLID원칙이다

S: Single Responsiblity Principle (단일 책임 원칙)
O: Open-Closed Principle (개방-패쇄 원칙)
L: Liskov Substitution Principle (리스코프 치환 원칙)
I: Interface Segregation Principle (인터페이스 분리 원칙)
D: Dependency Inversion Principle (의존 역전 원칙)

Single Responsiblity Principle (단일 책임 원칙)

하나의 클래스는 하나의 책임만을 가져야 한다는 뜻이다. 각각의 클래스들이 여러 가지의 책임을 가지고 있다면 수정과정에 있어서 하나의 수정이 또 다른 수정을 연쇄적으로 야기할 가능성이 높아지기 때문이다(클래스간 결합도가 높고, 응집도가 낮기 때문에). 이는 결국 유지보수에 비용이 증가한다는 것을 뜻하므로 각각의 클래스는 하난의 책임만을 가질 필요가 있다.

응집도 : 관련성 있는 코드들이 얼마나 응집해 있는가
결합도 : 불필요한 의존성이 존재하는가

• 코드 예시

그림 1

위의 예를 보면 쥬스만들기 라는 class 과일준비(), 쥬스만들기(), 쥬스를준다()의 많은 역할을 중구난방으로 가지고 있는 것을 알 수 있다.

그림 2

1번 예와 비교해서 각각의 과일준비(), 쥬스만들기(), 쥬스를준다() 역할을 하는 프로토콜을 만들어주고 각자의 역할만하는 메소드만을 구현하게 했다. 그리고 쥬스만들기에서는 이 프로토콜들을 활용해서 상효작용만을 하고 있다.

그로 인해 각각의 프로토콜들을 활용해서 로그인에 관한 책임만을 가지고 있다는 것을 알 수 있다.

Open-Closed Principle (개방-패쇄 원칙)

확장에는 열려있고 변경에는 닫혀있어야 한다는 뜻이다. 다시 말해 확장을 할때는 기존의 코드를 최대한 건드리지 않고 확장하고, 만약 기존의 코드를 수정하게 된다면 연쇄적인 수정을 하지 않을 수 있게 하자는 것이다(변경이 기존 코드에 영향을 미치지 않으면서 새로운 코드를 추가할 수 있는 구조 지향).

• 코드 예시

그림 1

그림 2

위 그림을 보면 교통수단을 각각 enum(그림 1)과 protocol(그림 2)로 구현을 하였다. 그리고 구체적인 교통수단의 종류를 case와 struct로 표현하였다. 이 둘은 수정과정에서 차이를 가진다.

그림 3

그림 4

만약 외발 자전거라는 교통수단을 추가하려 한다면 enum타입의 경우는 전반적인 수정을 요구한다(그림 3). 그러나 protocol의 경우 외발자전거 struct만 추가해주면 되어서 확장만 실시하면 된다(그림 4).

Liskov Substitution Principle (리스코프 치환 원칙)

부모 클래스로 작동 하는 기능을 자식클래스로 대체 하여도 동작이 가능 해야 한다는 뜻이다.

• 코드 예시

그림 1

그림 2

그림 3

정사각형은 직사각형이기도 하다. 그래서 직사각형 클래스를 상속 받고 있다. 하지만 정사각형은 양변의 길이가 똑같다는 자신만의 성질을 가지기 위해 직사각형의 메서드를 override 해주었고, 이로 인해 직사각형의 성질을 그대로 상속하는 것을 거부하고 자신만의 성질을 가지게 된다.(퇴화 함수)

위 처럼 LSP원칙을 깨지 않기 위해 상속을 할때는 보다 신중해야 할 필요가 있으나, 모든 코드에서 LSP를 지키기는 어려움이 따른다. 결국 적정선에서 타협을 보는 것도 하나의 방법이 될 수 있다.

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

인터페이스의 규모를 너무 크게 구현하여 구현할 객체가 쓸데 없는 메소드를 구현해야만 하는 경우를 만들지 말고 , 인터페이스를 좀더 세분화 하여 구현하라는 뜻이다.

• 코드 예시

상어의 경우 동물 프로토콜을 채택했음에도 메소드 두개는 구현하지 않게 된다. 해결 방법은 각 3개의 인터페이스(프로토콜)를 만들어 각각 필요한 프로토콜만 채택하는 것이다.

특성 별로 프로토콜을 정리할 경우 각각 필요한 프로토콜만 이용가능하다.

Dependency Inversion Principle (의존 역전 원칙)

객체는 객체(저수준 모듈)보다 인터페이스(고수준 모듈)에 의존해야 한다.
고수준 모듈 - 인터페이스 같은 추상적 개념
저수준 모듈 - 구현된 객체

자동차를 만들때 하나의 타이어(저수준 모듈) 종류만 의존하여 바퀴를 만들 경우 이후에 바퀴를 교체할 때 문제가 생길 수 있다. 이를 해결해 주기위해서는 모든 타이어 종류와 호환될 수 있는 바퀴(고수준 모듈)를 만들어 타이어를 그 바퀴에 의존 시켜 주면된다.

• 코드 예시

그림 1

그림 2

만약 자동차에 한국타이어에 의존하여 한 가지 타이어만 호환되도록 한다면 그림 2처럼 다른 타이어로 교체를 할 경우 문제가 발생한다.

그러나 하이브리드바퀴 프로토콜에 의존하여 타이어를 생산할 경우 타이어를 변경할 때 문제가 발생하지 않는 것을 확인 할 수 있다.