[GoLang] 추상 팩토리 디자인 사용해보기

추상 팩토리 디자인 패턴

추상 팩토리 디자인을 사용해 보겠습니다.

아마 여러분이 디자인 패턴을 한 번이라도 봤다면 이 패턴을 가장 처음 보게 될 텐데

이게 디자인 패턴 중 가장 친근할 겁니다.

 

요약하자면 

일정한 패턴을 가진 객체들을 자주 사용할 때

공통된 함수나 변수로 묶어서 인터페이스를 만들고, 이 인터페이스를 잘 활용을 하는 방법입니다.

 

이걸 구현하는 하위 객체들을 사용하는, 호출 부에서는 객체 하나하나의 생성을 로직을 몰라도 바로 쓸 수 있습니다.

이로써 객체 생성의 추상화가 구현됨으로써 유연성과 확장성을 높여 줍니다.

 

개념

추상화라는 말이 들어가는 걸로, 알 수 있듯이 객체 지향 언어에서 인터페이스를 사용해서 주로 구현합니다.

• 여러 객체를 생성하기 위해 이들을 묶는 상위 개념의 인터페이스 제공
• 각 객체는 Factory (생성 함수)를 통해 생성됨
• 클라이언트는 Factory(생성 함수)의 인터페이스만 알면 됨

 

이로 인해 아래 장점을 얻습니다.

• 객체 생성을 팩토리 함수에서 함으로써 클라이언트는 생성 방법을 몰라도 됨
  이게 가장 큰 장점으로 일일이 로직을 분석하지 않아도 돼서 유지보수에서 용이함
• 동일한 팩토리 함수를 쓰므로 객체 간의 호환성을 유지
• 이미 있는 패턴을 따라 하면 되므로 추후에 기능을 추가하기도 유리

즉 아래 이미지로 요약이 가능합니다

 

 

사용 예시로는 무엇을 할까 고민했는데..

 

제가 지금 다니는 회사는 안과 데이터를 다루는데.

 

이때 한 환자에 대해 여러 진단이 들어가게 됩니다.

그때 아주 용이하게 쓸 수 있을 것 같아서 이걸로 예시를 들었습니다.

 

진단마다 고정된 정보가 있을 수 있고, 반면에 진단마다 고유의 정보 또한 존재합니다.

즉 진단이라는 개념으로 여러 진단을 묶을 수 있죠.

 

예제

제가 예시로 든 상황을 코드로 한번 구현해 봅시다

저는 go 1.21.6을 사용했습니다.

 

우선 추상 팩토리를 만들어줍니다

diagnostic/define.go 

package diagnostic

import "fmt"

type Diagnosis interface {
	GetType() string
	GetDetails() string
}

// Diagnosis 를 구현하는 Topography
type Topography struct {
	Curvature string
	Surface   string
}

func (t Topography) GetType() string {
	return "Topography"
}

func (t Topography) GetDetails() string {
	return "Curvature: " + t.Curvature + ", Surface: " + t.Surface
}

// Diagnosis 를 구현하는 AxialLength
type AxialLength struct {
	Length float64
}

func (a AxialLength) GetType() string {
	return "AxialLength"
}

func (a AxialLength) GetDetails() string {
	return "Length: " + fmt.Sprintf("%.2f mm", a.Length)
}

// Diagnosis 를 구현하는 AxialLength
type VisualField struct {
	Count   int
	Success int
	Fail    int
}

func (v VisualField) GetType() string {
	return "VisualField"
}

func (v VisualField) GetDetails() string {
	return fmt.Sprintf("Count: %d", v.Count)
}

 

그 후 팩토리 함수를 만듭니다.

diagnostic/factory.go

package diagnostic

// DiagnosisFactory 추상 팩토리 인터페이스
type DiagnosisFactory interface {
	CreateDiagnosis() Diagnosis
}

// TopographyFactory 생성 팩토리 선언
type TopographyFactory struct {
	Curvature string
	Surface   string
}

func (f TopographyFactory) CreateDiagnosis() Diagnosis {
	return Topography{
		Curvature: f.Curvature,
		Surface:   f.Surface,
	}
}

// AxialLengthFactory 생성 팩토리 선언
type AxialLengthFactory struct {
	Length float64
}

func (f AxialLengthFactory) CreateDiagnosis() Diagnosis {
	return AxialLength{
		Length: f.Length,
	}
}

// VisualFieldFactory 생성 팩토리 선언
type VisualFieldFactory struct {
	Count   int
	Success int
	Fail    int
}

func (f VisualFieldFactory) CreateDiagnosis() Diagnosis {
	return VisualField{
		Count:   f.Count,
		Success: f.Success,
		Fail:    f.Fail,
	}
}

 

이제 main.go에서 아래처럼 사용이 가능합니다.

package main

import (
	"design-pattern.com/diagnostic"
	"fmt"
)

type Patient struct {
	Name      string
	Diagnoses []diagnostic.Diagnosis
}

func (p *Patient) AddDiagnosis(d diagnostic.Diagnosis) {
	p.Diagnoses = append(p.Diagnoses, d)
}

func (p Patient) PrintDiagnoses() {
	fmt.Println("Patient Name:", p.Name)
	for _, d := range p.Diagnoses {
		fmt.Printf("- [%s] %s\n", d.GetType(), d.GetDetails())
	}
}

func main() {
	// 환자 생성
	patient := Patient{Name: "Seung"}

	topography := diagnostic.TopographyFactory{
		Curvature: "Steep",
		Surface:   "Smooth",
	}.CreateDiagnosis()
	axialLength := diagnostic.AxialLengthFactory{
		Length: 23.45,
	}.CreateDiagnosis()
	visualField := diagnostic.VisualFieldFactory{
		Count:   12,
		Success: 8,
		Fail:    4,
	}.CreateDiagnosis()

	// 환자에 진단을 넣을 때와
	patient.AddDiagnosis(topography)
	patient.AddDiagnosis(axialLength)
	patient.AddDiagnosis(visualField)

	// 데이터를 출력할 때 기존 내용을 전혀 몰라도 됨 => 추상 팩토리 사용 이유
	patient.PrintDiagnoses()
}

 

이걸 사용해보면 아래 같은 결과를 봅니다

Patient Name: Seung
- [Topography] Curvature: Steep, Surface: Smooth
- [AxialLength] Length: 23.45 mm
- [VisualField] Count: 12

 

여태까지의 로직이나 패턴은 요약하면 아래 그림과 같죠 

실제 적용은..?

이 패턴을 이전 회사에서 Laravel을 다룰 때도 기존 프로젝트에 적용을 시켜본 적이 있었는데.

이 패턴을 설명해 줘도 같이 일하던 팀원이 필요성을 못 느껴서 적용하기 꺼려하던 경험이 있습니다.

 

끝내 프로젝트에 적용했지만 "왜 이걸 사용하지"라는 느낌을 지우지 못하더군요

이 부분은 지금은 더 잘 설득할 수 있을 텐데, 제가 부족했죠.

 

다시 돌아와서 이 패턴은 유지보수에서 엄청난 이점이 있는 건 맞지만

처음 작성하는 코드의 양이 배 이상 늘어나게 되니 작업 속도가 느려지는 경향이 있습니다.

 

지금 회사에 적용해 볼까 했지만 이미.. 많은 일이 쌓여있기 때문에

나중을 기약할 것 같습니다..