SOLID in GO - Liskov Substitution Principle

Photo by Austin Distel on Unsplash

 

세 번째 Liskov Substitution Principle이다

 

- Single Responsibility Principle

- Open/Closed Principle

- Liskov Substitution Principle

- Interface Segregation Principle

- Dependency Inversion Principle

 

Liskov Substitution Principle

 

Dave Cheney on YouTube: https://youtu.be/zzAdEt3xZ1M?t=615

 

참고 - OOP에서의 Liskov Substitution Principle

 

OOP, 즉 Class가 있는 언어에서는, 슈퍼클래스를 물려 받은 파생클래스라면, 그래서 슈퍼클래스의 메서드가 구현되어 있다면, 슈퍼클래스를 요구하는 곳에서 쓸 수 있다는 것이다. 백엔드 개발자(=슈퍼 클래스)가 필요한 곳이라면, Node.js 백엔드 개발자나, Go 백엔드 개발자가 가서 일할 수 있다고 하면 될까?

 

그런데 Go는 클래스가 없다.

 

대신 임베딩을 생각해볼 수 있다.

 

1. 구조체가 있고, 구조체의 메서드가 있을때에, 그 메서드 행위를 요구하는 인터페이스 타입이 있다고 한다면

2. 해당 구조체를 임베딩한 구조체들도 인터페이스를 만족하고, 인터페이스를 사용하는 곳에 쓸 수 있다는 것이다.

→ Go는 최소한의 메서드 구현을 요구하는 인터페이스의 사용을 권장하고 있다.

 

아래 예제를 보면

 

soccerBall 구조체는 Ball 구조체를 그대로 임베딩 했지만, soccerBall2 구조체는 필드명 ball을 Ball 구조체 타입으로 정의했다. soccerBall에서는 inner type promotion이 일어나서 Ball의 메서드인 Shoot()을 마지 soccerBall 자신의 메서드인양 바로 쓸 수 있다. 이게 무얼 의미하냐면, 만약 특정 인터페이스가 Shoot() 메서드를 요구한다면, Ball을 임베딩 하는 것 만으로 인터페이스를 만족한다는 것이다.

 

예제 링크: https://play.golang.org/p/sHvgeAb3-6V

 

"Require no more, promise no less." - Jim Weirich

"요구사항은 최소한으로 하라. 구현은 최소한 그것만큼은 해줘라." 는 말이다.

 

인터페이스는 가능한 작아야 한다. 하나의 메서드만 요구하는게, 혹은 적을 수록 바람직하다. 그러면 이런 인터페이스를 만족하는 타입을 만족시키기는 쉽겠지? 그럼에도 불구하고 쓰일 곳은 많겠지?

그런 시각으로 보면 아름답게까지 보이는 Reader 인터페이스이다.

 

 

유튜브 예제 확인

 

예제를 보자. human 구조체가 GetName() 이라는 메서드를 가진다.

따라서 human은 person 인터페이스의 GetName() string 을 구현해야 한다는 요구사항을 만족한다. 

 

Student, Teacher 구조체는 별도로 GetName() 메서드를 구현하지 않고 human 구조체를 임베딩 한 것 만으로

person 인터페이스를 만족하고, person 인터페이스 타입을 파라미터로 받는 info() 메서드를 이용해 이름을 출력할 수 있다.

 

유튜브 출처: https://youtu.be/AKdvlr-RzEA?t=251

코드 링크: https://play.golang.org/p/NzwiMN3GTtF