객체지향 SOLID 원칙

객체지향의 SOLID 5대 원칙에 대해 글을 작성해보겠습니다.
글에서 사용된 예제는 언어와 무관하지만 타입스크립트를 이용하여 작성되었습니다.

단일 책임 원칙, SRP(Single Responsibility Principle)

객체는 단 하나의 책임만 가져야 한다

코드의 간소화를 위해 메서드를 구현하지 않았습니다.

 

Caculator라는 클래스에는 더하기, 빼기, 곱하기, 나누기 기능을 제공합니다.

하지만 기능 중 음악을 재생하는 기능이 생겼을때 위와 같이 Caculator에 playMusic을 추가하는 것은 단일 책임 원칙에 위배됩니다.

위와 같이 새로운 클래스를 선언하여 메서드를 구현해야합니다.

개방-폐쇄 원칙, OCP(Open-Closed Principle)

확장에는 개방적이고 수정에는 폐쇄적이어야 한다

위의 예제에서 Light클래스의 on메서드는 빨간색 불을 킵니다. 하지만 만약 파란색불이 켜지도록 바꾸고 싶다면 아래와 같이 바꿔야 겠죠?

이는 수정에 닫혀있지 않는 상태입니다. 확장에 열려있고 수정에 닫히기 위해서 추상화를 통해 해결할 수 있습니다.

위와 같이 Light인터페이스를 통해 새로운 조명이 추가되면 Light의 구현체를 만들어 확장할 뿐입니다.

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

자식 클래스는 자신의 부모 클래스의 역할을 대체할 수 있어야한다

처음 들었을때 가장 이해되지 않던 원칙이었습니다. 하지만 평소 개발습관을 생각하며 이해하니 수월하게 이해할 수 있었습니다.
예제를 통해 알아보겠습니다.

조금 억지스로운 예제일 수 있지만 이해하기 쉬운 예제인것 같습니다. Animal 클래스를 상속받는 Cat 클래스는 sound메서드를 오버라이딩 합니다.

 

이때 printSound 함수는 animal의 정확한 타입인 Cat을 모르기 때문에 멍멍이 출력될 것 이라고 예상합니다. 하지만 야옹이 실제로 출력됩니다.

 

부모 클래스 메서드의 오버라이딩은 간혹 예상하지 못한 값을 얻습니다.

이런 문제를 해결하기위해 추상클래스 혹은 인터페이스 를 통해 자식에서 구현되는 클래스임을 명시해주는 방법이 있습니다.

저 또한 평소 상속을 사용할 시 주로 추상클래스, 인터페이스를 상속받아 사용합니다. 이런 방식을 토대로 이해하여 쉽게 이해할 수 있었습니다.

인터페이스 분리 원치, ISP(Interface Segregation Principle)

거대한 인터페이스보다 구체적인 여러 인터페이스가 낫다

이전 버전의 폰은 인터넷 기능을 지원하지 않고 새로운 폰들만 인터넷 기능을 지원하려면 위와 같은 방식은 안되겠죠?

그렇다면 internet 메서드를 Phone인터페이스에서 정의하지 않고 NewPhone 클래스에서 정의하여 구현하면 되지 않을까? 라는 생각이 들 수 있습니다. 하지만 앞으로의 모든 폰에 각각 internet메서드를 정의하고 구현해야됩니다.

아래와 같이 각각의 기능을 인터페이스로 분리한다면 자신이 사용할 기능만을 쉽게 선택하여 구현할 수 있습니다.

의존 역전 원칙, DIP(Dependency Inversion Principle)

고수준 모듈은 저수준 모듈의 구현에 의존해서는 안된다

위의 경우 Car 의 타이어를 바꾸기 위해서 새로운 타이어 클래스를 만들어 Car의 코드들도 모두 수정해야합니다.

하지만 위와 같이 Tire인터페이스를 통해 Tire를 추상화 한다면 언제든 new SnowTire()만 바꿔준다면 쉽게 타이어를 바꿀 수 있습니다.

의존성 주입, DI(Dependency Injection)

하지만 여전히 Car 클래스는 SnowTire에 의존하고 있습니다. 그렇다면 외부에서 의존성을 주입할 수 있습니다.

위와 같이 생성자 주입방식을 통해 SnowTire객체를 주입하고 있습니다. 이렇게 된다면 Car의 코드를 전혀 수정하지 않고 Tire를 바꿔가며 Car객체를 생성할 수 있습니다.