Single Responsibility Principle in GO

☝ Single Responsibility

"In any well-designed system, objects should only have a single responsibility." by Robert Martine.

잘 설계 된 모든 시스템에서 객체들은 오로지 1개의 책임만을 가지고 있어야 한다.

즉, 객체를 구현하는 코드는 오로지 한가지 일만을 효율적인 방법으로 처리하는데 집중해야 한다는 말이다. 이 말을 제대로 이해하기 위해서는 이러한 원칙을 위반하는 코드를 살펴보는 것이 좋다.

우선, 드론을 기반으로 배달을 하는 서비스를 지원하는 소프트웨어를 개발하고 있다고 가정해보자.
다음 코드는 Drone 이 배달과정에서 수행해야하는 몇 가지 책임들을 정의하는 코드라고 볼 수 있다.

// NavigateTo applies any required changes to the drone's speed 
// vector so that its eventual position matches dst.
func (d *Drone) NavigateTo(dst Vec3) error { //... }

// Position returns the current drone position vector.
func (d *Drone) Position() Vec3 { //... }

// Position returns the current drone speed vector.
func (d *Drone) Speed() Vec3 { //... }

// DetectTargets captures an image of the drone's field of view (FoV) using
// the on-board camera and feeds it to a pre-trained SSD MobileNet V1 neural
// network to detect and classify interesting nearby targets. For more info
// on this model see: 
// https://github.com/tensorflow/models/tree/master/research/object_detection
func (d *Drone) DetectTargets() ([]*Target, error) { //... }

상기 코드는 SRP(Single Responsibility Principle)원칙을 위반하고 있다.
그 이유는 2가지 복합적인 책임을 동시에 수행하고 있다고 볼 수 있기 때문이다.

• Navigation ( 비행 )
• Detection ( 탐지 )

사실 비행과 탐지라는 두가지 책임을 동시에 Drone 이라고 하는 객체 타입에 같이 선언하여 개발한다고 하더라도 처음 프로그램 동작에는 문제가 없을 수 있다. 하지만, 문제는 그 이후에 발생한다. 비행과 탐지라는 두 가지 책임이 동시에 존재하기 때문에 Coupling (결합) 이 발생하게 되고 그로 인해 추가적인 개발과 확장에 어려움을 가중 시킬 수 있다.

예를 들면, 탐지에 사용되는 인공지능 모델을 다른 것으로 사용한다든지, 다른 종류의 Drone에 기존의 동일한 탐지 코드를 사용한다든지 하고 싶을 떄 어쩔 수 없이 존재하는 결합상태 때문에 비행과 관련한 코드를 항상 유지해야 한다는 것이다.