사용을 중지하십시오 ||= 항상

Ruby 코드에서 나는 종종 다음과 같은 코드를 작성하는 사람들을 봅니다.

def foo
    @foo ||= 'bla bla bla'
end

대신에

def initialize
    @foo = 'bla bla bla'
end

attr_reader :foo

오리 연산자||=는 initialize 메서드에서 인스턴스 변수를 초기화하는 대신 인스턴스 변수를 느리게 초기화하는 데 사용됩니다.

Ruby에서는 할당도 표현식이고 모든 메서드에 암시적 반환 값이 있기 때문에 가능합니다. 따라서 @foo ||= 123는 항상 123로 평가되지만 @foo에 두 번 이상 할당되지 않습니다.

이것은 매우 간결하지만 다른 언어로 코딩한 후 처음 Ruby에 왔을 때 이상하다는 것을 알았습니다. 그것은 일을 하는 매우 우회적인 방법처럼 느껴집니다. 인스턴스 변수를 초기화하는 경우 초기화 프로그램을 사용하지 않는 이유는 무엇입니까?

지연 초기화 패턴은 필요하지 않을 수 있는 비용이 많이 드는 계산 실행을 피하는 한 가지 방법입니다. 그러나 개체를 사용할 수 있으려면 초기화가 항상 필요하다는 것을 알고 있다면 이러한 방식으로 개체를 구성해도 성능상의 이점이 없습니다.

이와 같이 코드를 구조화하면 클래스를 보는 것만으로도 종속성을 알아차리기가 조금 더 어려워집니다. 클래스 사용자는 개체가 완전히 초기화되지 않았는데도 완전히 초기화된 것으로 오해할 수 있으며 이로 인해 테스트 또는 코드베이스의 다른 부분에서 개체를 초기화하기가 더 어려워질 수 있습니다.

실제로는 초기화가 선택적일 때도 의심스럽습니다. 선택적 초기화는 여전히 초기화와 분리되어 있어 코드를 읽을 때 명확하지 않기 때문입니다. 선택적 동작은 클래스가 가지고 있다는 신호일 수도 있습니다more than one responsibility.

이를 피하기 위해 항상 클래스를 리팩터링할 수 있습니다. 예를 들어 계산을 내부적으로 수행하는 대신 dependency injection을 사용하여 계산 결과에 의존하는 것을 고려하십시오.

def initialize(foo: nil)
    @foo = foo
end

# ...
# methods that use `foo`
# ...

private

attr_reader :foo

지연 초기화는 temporal coupling의 특수한 경우입니다. 클래스의 동작은 메소드를 호출하는 순서에 따라 달라질 수 있습니다. 동작이 복잡할수록 코드에 대해 추론하기가 더 어렵고 더 쉽습니다. 버그를 소개합니다. 이 경우 클래스의 다른 메서드가 인스턴스 변수에 의존하는 경우 초기화 메서드가 먼저 호출되지 않으면 읽을 수 있습니다nil.

참고: 요청별로 초기화되지 않고 보기와 통신하는 방법으로 작업 메서드 내에서 인스턴스 변수를 설정해야 하는 레일 컨트롤러에서 이 문제를 많이 봅니다. 이 디자인은 불행하지만 코드베이스의 다른 곳에서 여전히 문제를 피할 수 있습니다.

반면에 클래스에 대한 모든 초기화가 initialize 메서드에 의해 처리되면 클래스의 동작을 예측 가능하게 만드는 것이 매우 쉽습니다. command-query responsibility segregation(CQRS)를 사용하여 개체에 보내는 메시지가 정보를 요청하거나 개체 상태를 변경하도록 할 수 있지만 둘 다는 아닙니다.

Photo by Francesco Altamura from Pexels