[Clean Code] 6-2 객체지향 절차지향 2

객체와 자료구조

디미터 법칙

모듈은 자신이 조작하는 객체의 속을 몰라야 한다는 법칙이다.
객체는 조회 함수로 내부 구조를 공개한다면 안 된다는 의미
(내부 구조를 노출하는 셈)
C 클래스의 f 메소드는 다음과 같은 객체의 메소드만 호출 해야 한다.

• 클래스 C
• f가 생성한 객체
• f로 넘어온 인수
• 클래스 C 인스턴스 변수 객체

디미터 법칙을 어긴 예시

같은 객체가 아닌 서로 다른 객체를 가지고 서로 연결해서 작성한
이런 코드를 기차 충돌 이라고 부른다.
일반적으로 조잡하니 지향하는 편이 좋다.

outputDir := cTxt.GetOptions().GetScratchDir().GetAbsolutePath()

변경 예시

opts := cTxt.GetOptions();
scratchDir := opts.GetScratchDir();
outputDir := scratchDir.GetAbsolutePath();

자료전달 객체

자료 구조체의 전형적인 형태는 공개 함수만 있는 클래스다.
(일명 DTO, Data Transfer Object)
DTO 는 보통 데이터베이스 혹은 소켓통신 후 결과값에 대해서 가공되지 않은 데이터를 사용할 객체로 변환 할 때 사용 한다.

DTO는 보통 조회로 사용하지만 때때로 변경이나 설정 등이 있을 수 있지만
규칙과 목적이 있는데 그렇게 사용하는 것은 바람직 하지 않다.

package test

import (
    "bytes"
    "io/ioutil"
    "net/http"
)

type HttpSuccessResult struct {
    statusCode int
    status     string
    result     string
}

func NewHttpSuccessResult(statusCode int, status string, result string) *HttpSuccessResult {
    h := HttpSuccessResult{
        statusCode: statusCode,
        status:     status,
        result:     result,
    }
    return &h
}

func (h *HttpSuccessResult) StatusCode () int{
    return h.statusCode
}

func (h *HttpSuccessResult) Status () int{
    return h.status
}
func (h *HttpSuccessResult) Result () int{
    return h.result
}

func main() {
    reqBody := bytes.NewBufferString("Post plain text")
    resp, err := http.Post("http://sample.post", "text/plain", reqBody)
    if err != nil {
        panic(err)
    }
    defer resp.Body.Close()

    respBody, err := ioutil.ReadAll(resp.Body)
    if err == nil {
        status := resp.Status
        statusCode := resp.StatusCode
        result := string(respBody)
        httpSuccessResult := NewHttpSuccessResult(statusCode, status, result)
    }
    else{
        htttpFailedResult := ...
    }
}

6-1과 6-2 를 통해서...

우리는 객체를 쓸 것인지 절차를 쓸 것인지 생각 하고 고민 해야 한다.
객체는 무조건적인 답이 아니다.
객체는 기존 동작에 영향을 미치지 않으면서 새 객체를 추가 하기는 쉽지만
기존 객체에 있는 것을 고칠 경우 다른 객체들을 생각해야 하기 때문에 어렵다.

지금 하고 있는 WMS에서는 
출고 요청시 요청 받은 데이터에 대해서 상점 별로  
namedtuple 로 parsing 후 Factory로 create 한 객체를 실행 시켜 출고 처리를 하는데
TA 처럼 로직이 달라지는 경우가 있어 Adapter 감싸서 실행 되도록 개발을 해놓았는데
이번 TA 가 서비스 로직이 변경 되어 사용을 못하게 되었다.  

절차적으로 했다면 If 문으로 그냥 해당 부분 주석 처리하고 변경해서 처리하도록 하면 된다.  
하지만 객체로 interface 로 동작이 구현되어 있기에 변경을 하지 못해 아예 새로 만들어야 했다.

그래도 나는 객체지향, 함수지향적으로 개발을 할 것이다.
왜? 확장성, 유지보수성, 재사용성 등등 측면을 생각 해보면 당연한다고 생각 된다.