생성자에서 setter를 사용하는 것이 일반적인 패턴이 아닌 이유는 무엇입니까?

접근 자와 수정 자 (일명 setter 및 getter)는 세 가지 주요 이유로 유용합니다.

1. 변수에 대한 액세스를 제한합니다.
   • 예를 들어 변수에 액세스 할 수는 있지만 수정할 수는 없습니다.
2. 그들은 매개 변수의 유효성을 검사합니다.
3. 부작용이 발생할 수 있습니다.

웹의 대학교, 온라인 강좌, 튜토리얼, 블로그 기사 및 코드 예제는 모두 접근 자와 수정 자의 중요성에 대해 강조하고 있으며, 요즘에는 코드에 대해 "필수"인 것 같습니다. 따라서 아래 코드와 같이 추가 값을 제공하지 않아도 찾을 수 있습니다.

public class Cat {
    private int age;

    public int getAge() {
        return this.age;
    }

    public void setAge(int age) {
        this.age = age;
    }
}

즉, 더 유용한 수정자를 찾는 것이 일반적입니다. 실제로 매개 변수의 유효성을 검사하고 유효하지 않은 입력이 제공된 경우 예외를 발생 시키거나 부울을 반환하는 수정자는 다음과 같습니다.

/**
 * Sets the age for the current cat
 * @param age an integer with the valid values between 0 and 25
 * @return true if value has been assigned and false if the parameter is invalid
 */
public boolean setAge(int age) {
    //Validate your parameters, valid age for a cat is between 0 and 25 years
    if(age > 0 && age < 25) {
        this.age = age;
        return true;
    }
    return false;
}

그러나 그때조차도 수정자가 생성자에서 호출되는 것을 거의 보지 못하므로 내가 직면 한 간단한 클래스의 가장 일반적인 예는 다음과 같습니다.

public class Cat {
    private int age;

    public Cat(int age) {
        this.age = age;
    }

    public int getAge() {
        return this.age;
    }

    /**
     * Sets the age for the current cat
     * @param age an integer with the valid values between 0 and 25
     * @return true if value has been assigned and false if the parameter is invalid
     */
    public boolean setAge(int age) {
        //Validate your parameters, valid age for a cat is between 0 and 25 years
        if(age > 0 && age < 25) {
            this.age = age;
            return true;
        }
        return false;
    }

}

그러나이 두 번째 접근 방식이 훨씬 안전하다고 생각할 것입니다.

public class Cat {
    private int age;

    public Cat(int age) {
        //Use the modifier instead of assigning the value directly.
        setAge(age);
    }

    public int getAge() {
        return this.age;
    }

    /**
     * Sets the age for the current cat
     * @param age an integer with the valid values between 0 and 25
     * @return true if value has been assigned and false if the parameter is invalid
     */
    public boolean setAge(int age) {
        //Validate your parameters, valid age for a cat is between 0 and 25 years
        if(age > 0 && age < 25) {
            this.age = age;
            return true;
        }
        return false;
    }

}

당신의 경험에 비슷한 패턴이 보입니까, 아니면 단지 운이 좋지 않습니까? 그리고 그렇게한다면, 그 원인이 무엇이라고 생각하십니까? 생성자에서 수정자를 사용하는 데 명백한 단점이 있습니까? 아니면 더 안전한 것으로 간주됩니까? 다른 것입니까?

매우 일반적인 철학적 추론

일반적으로 생성자는 생성 된 객체의 상태에 대한 보증을 사후 조건으로 제공해야합니다.

일반적으로 인스턴스 메소드는 호출 할 때 이러한 보장이 이미 보유하고 있다고 가정하고 사전 조건으로 가정 할 수 있으며이를 중단하지 않아야합니다.

생성자 내부에서 인스턴스 메서드를 호출하면 해당 보증 중 일부 또는 전부가 아직 설정되지 않았으므로 인스턴스 메서드의 사전 조건이 충족되는지 여부를 추론하기가 어렵습니다. 예를 들어, 제대로 이해하더라도 매우 취약 할 수 있습니다. 인스턴스 메소드 호출 또는 기타 작업의 순서를 다시 지정합니다.

언어는 생성자가 여전히 실행되는 동안 기본 클래스에서 상속되거나 하위 클래스로 재정의되는 인스턴스 메서드에 대한 호출을 해결하는 방법도 다양합니다. 이것은 또 다른 복잡성 계층을 추가합니다.

구체적인 예

1. 이것이 어떻게 보일지에 대한 자신의 예는 그 자체가 잘못되었습니다.

   public Cat(int age) {
       //Use the modifier instead of assigning the value directly.
       setAge(age);
   }

   의 반환 값을 확인하지 않습니다 setAge. 분명히 setter를 호출한다고해서 정확성이 보장되는 것은 아닙니다.

2. 초기화 순서에 따라 다음과 같은 매우 쉬운 실수 :

   class Cat {
     private Logger m_log;
     private int m_age;
   
     public void setAge(int age) {
       // FIXME temporary debug logging
       m_log.write("=== DEBUG: setting age ===");
       m_age = age;
     }
   
     public Cat(int age, Logger log) {
       setAge(age);
       m_log = log;
     }
   };

   내 임시 벌목이 모든 것을 깨뜨 렸어요 으악!

생성자에서 setter를 호출하면 기본 초기화 낭비를 의미하는 C ++과 같은 언어도 있습니다 (일부 구성원 변수의 경우 피할 가치가 있음)

간단한 제안

대부분의 코드 는 이런 식으로 작성 되지 않았지만 생성자를 깨끗하고 예측 가능하게 유지하고 사전 및 사후 조건 논리를 재사용하려는 경우 더 나은 솔루션은 다음과 같습니다.

class Cat {
  private int m_age;
  private static void checkAge(int age) {
    if (age > 25) throw CatTooOldError(age);
  }

  public void setAge(int age) {
    checkAge(age);
    m_age = age;
  }

  public Cat(int age) {
    checkAge(age);
    m_age = age;
  }
};

또는 가능하면 더 좋을 수도 있습니다. 속성 유형으로 제약 조건을 인코딩하고 할당시 자체 값을 확인하도록하십시오.

class Cat {
  private Constrained<int, 25> m_age;

  public void setAge(int age) {
    m_age = age;
  }

  public Cat(int age) {
    m_age = age;
  }
};

그리고 마지막으로, 완전성을 위해 C ++의 자체 유효성 검사 래퍼입니다. 여전히 지루한 유효성 검사를 수행하고 있지만이 클래스는 다른 작업을 수행하지 않기 때문에 비교적 쉽게 확인할 수 있습니다.

template <typename T, T MAX, T MIN=T{}>
class Constrained {
    T val_;
    static T validate(T v) {
        if (MIN <= v && v <= MAX) return v;
        throw std::runtime_error("oops");
    }
public:
    Constrained() : val_(MIN) {}
    explicit Constrained(T v) : val_(validate(v)) {}

    Constrained& operator= (T v) { val_ = validate(v); return *this; }
    operator T() { return val_; }
};

자, 완전하지는 않습니다. 다양한 복사 및 이동 생성자와 할당을 생략했습니다.

오브젝트가 구성 될 때, 정의에 의해 완전히 형성되지 않습니다. 세터가 제공 한 방법을 고려하십시오.

public boolean setAge(int age) {
    //Validate your parameters, valid age for a cat is between 0 and 25 years
    if(age > 0 && age < 25) {
        this.age = age;
        return true;
    }
    return false;
}

유효성 검사의 일부에 개체의 나이 만 증가 할 수 있도록 속성에 setAge()대한 검사가 포함 된 경우 age어떻게됩니까? 그 상태는 다음과 같습니다.

if (age > this.age && age < 25) {
    //...

고양이는 한 방향으로 만 시간을 움직일 수 있기 때문에 꽤 순진한 변화처럼 보입니다. 유일한 문제는 이미 유효한 값이 this.age있다고 가정하기 때문에 초기 값을 설정하는 데 사용할 수 없다는 것 this.age입니다.

생성자에서 setter를 피 하면 생성자가 수행 하는 유일한 작업은 인스턴스 변수를 설정하고 setter에서 발생하는 다른 동작을 건너 뛰는 것입니다.

여기에 좋은 대답이 있지만 지금까지 아무도 당신이 여기에 두 가지를 요구하는 것을 보지 못했습니다. IMHO 게시물은 다음 두 가지 질문 으로 가장 잘 나타납니다 .

1. setter에 제약 조건의 유효성 검사가있는 경우이를 무시할 수 없도록 클래스의 생성자에도 있지 않아야합니까?

2. 왜 생성자 로부터이 목적으로 setter를 직접 호출하지 않습니까?

첫 번째 질문에 대한 대답은 분명히 "예"입니다. 예외를 발생시키지 않는 생성자는 객체를 유효한 상태로 두어야하며 특정 속성에 대해 특정 값이 금지 된 경우 ctor가이를 우회하도록하는 것은 전혀 의미가 없습니다.

그러나 파생 클래스에서 setter를 재정의하지 않도록 조치를 취하지 않는 한 두 번째 질문에 대한 대답은 일반적으로 "아니오"입니다. 따라서 더 나은 대안은 생성자뿐만 아니라 setter에서 재사용 할 수있는 전용 메소드에서 제한 조건 유효성 검증을 구현하는 것입니다. 나는이 디자인을 정확하게 보여주는 @Useless 예제를 반복하지 않을 것입니다.

다음은 생성자에서 최종이 아닌 메소드를 사용하여 발생할 수있는 문제의 종류를 보여주는 바보 같은 Java 코드입니다.

import java.util.regex.Pattern;

public class Problem
{
  public static final void main(String... args)
  {
    Problem problem = new Problem("John Smith");
    Problem next = new NextProblem("John Smith", " ");

    System.out.println(problem.getName());
    System.out.println(next.getName());
  }

  private String name;

  Problem(String name)
  {
    setName(name);
  }

  void setName(String name)
  {
    this.name = name;
  }

  String getName()
  {
    return name;
  }
}

class NextProblem extends Problem
{
  private String firstName;
  private String lastName;
  private final String delimiter;

  NextProblem(String name, String delimiter)
  {
    super(name);

    this.delimiter = delimiter;
  }

  void setName(String name)
  {
    String[] parts = name.split(Pattern.quote(delimiter));

    this.firstName = parts[0];
    this.lastName = parts[1];
  }

  String getName()
  {
    return firstName + " " + lastName;
  }
}

이것을 실행하면 NextProblem 생성자에서 NPE를 얻습니다. 이것은 물론 사소한 예이지만 상속 수준이 여러 개인 경우 상황이 빠르게 복잡해질 수 있습니다.

이것이 일반적이지 않은 더 큰 이유는 코드를 이해하기 어렵게 만들기 때문입니다. 개인적으로, 나는 setter 메소드를 거의 사용하지 않았고 멤버 변수는 거의 변하지 않습니다 (pun 예정). 따라서 생성자에서 값을 설정해야합니다. 불변의 객체를 사용하는 경우 (그리고 그렇게해야 할 많은 이유가있는 경우) 문제는 무의미합니다.

어쨌든 유효성 검사 또는 다른 논리를 재사용하는 것이 좋은 목표이며이를 정적 메서드에 넣고 생성자와 설정자에서 호출 할 수 있습니다.

그것은 달려있다!

속성을 설정할 때마다 적중해야하는 setter에서 간단한 유효성 검사를 수행하거나 나쁜 부작용을 일으키는 경우 setter를 사용하십시오. 대안은 일반적으로 setter에서 setter 로직을 추출하고 setter 와 생성자 모두에서 실제 set이 뒤 따르는 새 메소드를 호출하는 것입니다. 실제로 setter 를 사용하는 것과 동일합니다! (지금은 두 곳에서 작고 두 줄짜리 세터를 유지 관리하는 것을 제외하고)

그러나 특정 setter (또는 2!)가 성공적으로 실행 되기 전에 객체를 정렬하기 위해 복잡한 작업을 수행해야하는 경우 setter를 사용하지 마십시오.

두 경우 모두 테스트 사례가 있습니다. 어느 경로로 이동하든 단위 테스트를 수행하면 두 옵션 중 하나와 관련된 함정을 노출시킬 수 있습니다.

또한 저 멀리에서 내 기억이 원격으로 정확하다면, 이것은 내가 대학에서 가르친 일종의 추론이기도합니다. 그리고 내가 일한 특권을 얻은 성공적인 프로젝트와 전혀 관련이 없습니다.

추측해야 할 경우, 생성자에서 setter를 사용하여 발생할 수있는 일반적인 버그를 식별 한 "깨끗한 코드"메모가 누락되었습니다. 그러나 내 입장으로는 그러한 버그에 희생되지 않았습니다 ...

그래서 저는이 특정한 결정이 쓸데없고 독단적 일 필요는 없다고 주장합니다.