세터가 "this"를 반환하는 것은 나쁜 습관입니까?

자바의 setter가 "this"를 반환하게하는 것이 좋은 생각입니까?

public Employee setName(String name){
   this.name = name;
   return this;
}

이 패턴은 다음과 같이 setter를 연결할 수 있기 때문에 유용 할 수 있습니다.

list.add(new Employee().setName("Jack Sparrow").setId(1).setFoo("bacon!"));

이 대신에 :

Employee e = new Employee();
e.setName("Jack Sparrow");
...and so on...
list.add(e);

...하지만 일종의 표준 규칙에 위배됩니다. 세터가 다른 것을 유용하게 만들 수 있기 때문에 가치가 있다고 생각합니다. 이 패턴이 JMock, JPA와 같은 일부 장소를 사용하는 것을 보았지만 드물게 보이며 일반적 으로이 패턴이 어디서나 사용되는 매우 잘 정의 된 API에만 사용됩니다.

최신 정보:

내가 설명한 것은 분명히 유효하지만 실제로 찾고있는 것은 이것이 일반적으로 수용 가능한지 여부와 함정이나 관련 모범 사례가 있는지에 대한 생각입니다. 빌더 패턴에 대해 알고 있지만 설명하고있는 것보다 조금 더 관련이 있습니다. Josh Bloch가 설명했듯이 객체 생성을 위해 관련된 정적 빌더 클래스가 있습니다.

나는 그것에 특별히 문제가 있다고 생각하지 않습니다. 그것은 단지 스타일의 문제입니다. 다음과 같은 경우에 유용합니다.

• 한 번에 많은 필드를 설정해야합니다 (건설시 포함).
• 코드를 작성할 때 어떤 필드를 설정해야하는지 알고
• 필드를 설정하려는 여러 가지 조합이 있습니다.

이 방법의 대안은 다음과 같습니다.

1. 하나의 메가 생성자 (단점 : 많은 null 또는 기본값을 전달할 수 있으며 어떤 값이 무엇에 해당하는지 알기가 어렵습니다)
2. 오버로드 된 여러 생성자 (단점 : 몇 개 이상 있으면 다루기 힘들다)
3. 팩토리 / 정적 메소드 (단점 : 오버로드 된 생성자와 동일-몇 개 이상 있으면 다루기 힘들다)

한 번에 몇 가지 속성 만 설정하려는 경우 'this'를 반환 할 가치가 없다고 말하고 싶습니다. 나중에 상태 / 성공 표시기 / 메시지와 같은 다른 것을 반환하기로 결정하면 확실히 떨어집니다.

나쁜 습관이 아닙니다. 점점 일반적인 관행입니다. 원하지 않는 경우 대부분의 언어는 반환 된 객체를 처리 할 필요가 없으므로 "일반적인"세터 사용법 구문을 변경하지 않지만 세터를 서로 연결할 수 있습니다.

이것을 일반적으로 빌더 패턴 또는 유창한 인터페이스 라고합니다 .

Java API에서도 일반적입니다.

String s = new StringBuilder().append("testing ").append(1)
  .append(" 2 ").append(3).toString();

요약:

• 이를 "유창한 인터페이스"또는 "메소드 체인"이라고합니다.
• 이것은 "표준"Java는 아니지만 요즘 더 많이 볼 수 있지만 (jQuery에서 잘 작동합니다)
• JavaBean 스펙을 위반하므로 다양한 도구 및 라이브러리, 특히 JSP 빌더 및 Spring과 충돌합니다.
• JVM이 정상적으로 수행하는 일부 최적화를 방해 할 수 있습니다.
• 어떤 사람들은 코드를 정리한다고 생각하고 어떤 사람들은 "거대한"생각

언급되지 않은 몇 가지 다른 점 :

• 이는 각 기능이 한 가지만 수행해야한다는 원칙에 위배됩니다. 이것을 믿거 나 믿지 않을 수도 있지만 Java에서는 잘 작동한다고 생각합니다.

• IDE는 기본적으로이를 생성하지 않습니다.

• 마지막으로 여기 실제 데이터 포인트가 있습니다. 이와 같은 라이브러리를 사용하는 데 문제가 있습니다. Hibernate의 쿼리 빌더는 기존 라이브러리에서 이에 대한 예입니다. Query의 set * 메소드가 쿼리를 리턴하므로 서명을 사용하여 사용법을 알려주는 것만으로는 불가능합니다. 예를 들면 다음과 같습니다.

  Query setWhatever(String what);

• 모호성을 소개합니다 : 메소드가 현재 객체 (패턴)를 수정합니까, 아니면 Query가 실제로 불변 (매우 인기 있고 귀중한 패턴)이며 메소드가 새로운 것을 반환합니다. 라이브러리를 사용하기 어렵게 만들고 많은 프로그래머가이 기능을 이용하지 않습니다. 세터가 세터 인 경우 사용 방법이 더 명확합니다.

나는 이것을 위해 'with'방법을 사용하는 것을 선호합니다 :

public String getFoo() { return foo; }
public void setFoo(String foo) { this.foo = foo; }
public Employee withFoo(String foo) {
  setFoo(foo);
  return this;
}

그러므로:

list.add(new Employee().withName("Jack Sparrow")
                       .withId(1)
                       .withFoo("bacon!"));

경고 :이 withX구문은 일반적으로 불변 개체에 "세터"를 제공하는 데 사용되므로 이러한 메서드를 호출하면 기존 인스턴스를 변경하지 않고 새 개체를 만들 것으로 기대할 수 있습니다. 아마도 더 합리적인 표현은 다음과 같습니다.

list.add(new Employee().chainsetName("Jack Sparrow")
                       .chainsetId(1)
                       .chainsetFoo("bacon!"));

chainsetXyz () 명명 규칙을 사용하면 거의 모든 사람이 행복해야합니다.

'this'setter에서 돌아 가지 않고 두 번째 옵션을 사용하지 않으려면 다음 구문을 사용하여 속성을 설정할 수 있습니다.

list.add(new Employee()
{{
    setName("Jack Sparrow");
    setId(1);
    setFoo("bacon!");
}});

제쳐두고 C #에서는 약간 깨끗하다고 ​​생각합니다.

list.Add(new Employee() {
    Name = "Jack Sparrow",
    Id = 1,
    Foo = "bacon!"
});

getter / setter의 관례를 위반할뿐만 아니라 Java 8 메소드 참조 프레임 워크도 손상시킵니다. MyClass::setMyValueA는 BiConsumer<MyClass,MyValue>, 그리고 myInstance::setMyValueA는 Consumer<MyValue>. setter return이있는 경우 this더 이상 유효한 인스턴스가 Consumer<MyValue>아닌의 인스턴스이며 Function<MyValue,MyClass>void 설정이라고 가정하면 해당 setter에 대한 메소드 참조를 사용하는 모든 항목이 중단됩니다.

Java를 모르지만 C ++ 에서이 작업을 수행했습니다. 다른 사람들은 그것이 줄을 정말로 길고 읽기가 어렵게한다고 말했지만, 나는 이것을 여러 번 그렇게했습니다.

list.add(new Employee()
    .setName("Jack Sparrow")
    .setId(1)
    .setFoo("bacon!"));

이것은 더 낫습니다 :

list.add(
    new Employee("Jack Sparrow")
    .Id(1)
    .foo("bacon!"));

적어도 나는 생각합니다. 그러나 당신은 저를 downvote하고 당신이 원한다면 나에게 끔찍한 프로그래머라고 불러도 좋습니다. 그리고 당신이 Java로 이것을 할 수 있는지 모르겠습니다.

'유창한 인터페이스'라고하는이 체계 (펀칭 된 의도)는 현재 매우 인기가 있습니다. 괜찮지 만 실제로 차 한잔은 아닙니다.

void를 반환하지 않기 때문에 더 이상 유효한 JavaBean 속성 설정자가 아닙니다. 시각적 "Bean Builder"도구를 사용하는 세계 7 명 중 하나이거나 JSP-bean-setProperty 요소를 사용하는 17 명 중 하나 인 경우에는 문제가 될 수 있습니다.

적어도 이론상 ,이 호출 사이에 거짓 종속성을 설정하여 JVM의 최적화 메커니즘을 손상시킬 수 있습니다.

그것은 구문 설탕이어야하지만 실제로는 지능이 뛰어난 Java 43의 가상 머신에서 부작용을 일으킬 수 있습니다.

그렇기 때문에 투표하지 않습니다. 사용하지 마십시오.

전혀 나쁜 습관이 아닙니다. 그러나 JavaBeans Spec 과 호환되지 않습니다 .

그리고 이러한 표준 접근 자에 따라 많은 사양이 있습니다.

항상 서로 공존 할 수 있습니다.

public class Some {
    public String getValue() { // JavaBeans
        return value;
    }
    public void setValue(final String value) { // JavaBeans
        this.value = value;
    }
    public String value() { // simple
        return getValue();
    }
    public Some value(final String value) { // fluent/chaining
        setValue(value);
        return this;
    }
    private String value;
}

이제 함께 사용할 수 있습니다.

new Some().value("some").getValue();

불변의 객체를위한 다른 버전이 있습니다.

public class Some {

    public static class Builder {

        public Some build() { return new Some(value); }

        public Builder value(final String value) {
            this.value = value;
            return this;
        }

        private String value;
    }

    private Some(final String value) {
        super();
        this.value = value;
    }

    public String getValue() { return value; }

    public String value() { return getValue();}

    private final String value;
}

이제 우리는 이것을 할 수 있습니다.

new Some.Builder().value("value").build().getValue();

전체 응용 프로그램에서 동일한 규칙을 사용하면 괜찮습니다.

어쨌든 응용 프로그램의 기존 부분이 표준 규칙을 사용하면 더 복잡한 클래스에 빌더를 추가합니다.

public class NutritionalFacts {
    private final int sodium;
    private final int fat;
    private final int carbo;

    public int getSodium(){
        return sodium;
    }

    public int getfat(){
        return fat;
    }

    public int getCarbo(){
        return carbo;
    }

    public static class Builder {
        private int sodium;
        private int fat;
        private int carbo;

        public Builder sodium(int s) {
            this.sodium = s;
            return this;
        }

        public Builder fat(int f) {
            this.fat = f;
            return this;
        }

        public Builder carbo(int c) {
            this.carbo = c;
            return this;
        }

        public NutritionalFacts build() {
            return new NutritionalFacts(this);
        }
    }

    private NutritionalFacts(Builder b) {
        this.sodium = b.sodium;
        this.fat = b.fat;
        this.carbo = b.carbo;
    }
}

Paulo Abrantes 는 JavaBean 세터를 유창하게 만드는 또 다른 방법을 제공합니다. 각 JavaBean에 대한 내부 빌더 클래스를 정의하십시오. 값을 반환하는 세터에 의해 플럭 소화 된 툴을 사용하는 경우 Paulo의 패턴이 도움이 될 수 있습니다.

나는 "this"리턴을 가진 세터에 찬성한다. 콩과 호환되지 않더라도 상관 없습니다. 나에게 "="표현식 / 문을 사용하는 것이 괜찮다면 값을 반환하는 세터가 좋습니다.

나는이 접근 방식을 선호했지만 반대하기로 결정했다.

원인:

• 가독성. 각 setFoo ()를 별도의 줄에 갖도록 코드를 더 읽기 쉽게 만듭니다. 일반적으로 코드를 작성할 때보 다 코드를 여러 번 더 많이 읽습니다.
• 부작용 : setFoo ()는 필드 foo 만 설정해야합니다. 이것을 돌려주는 것은 "WHAT was that"입니다.

내가 본 빌더 패턴은 setFoo (foo) .setBar (bar) 규칙을 사용하지 않고 더 많은 foo (foo) .bar (bar)를 사용합니다. 아마도 그 이유 때문일 것입니다.

항상 맛의 문제입니다. 나는 "최소한의 놀라움"접근법을 좋아한다.

이 특정 패턴을 Method Chaining이라고합니다. Wikipedia link 에는 다양한 프로그래밍 언어에서 어떻게 수행되는지에 대한 자세한 설명과 예제가 있습니다.

추신 : 특정 이름을 찾고 있었기 때문에 여기에 남겨 두는 것을 생각했습니다.

첫눈에 : "거대한!".

더 생각에

list.add(new Employee().setName("Jack Sparrow").setId(1).setFoo("bacon!"));

실제로보다 오류가 덜 발생합니다

Employee anEmployee = new Employee();
anEmployee.setName("xxx");
...
list.add(anEmployee);

매우 흥미 롭습니다. 툴백에 아이디어 추가 ...

예, 좋은 생각이라고 생각합니다.

무언가를 추가 할 수 있다면이 문제는 어떻습니까?

class People
{
    private String name;
    public People setName(String name)
    {
        this.name = name;
        return this;
    }
}

class Friend extends People
{
    private String nickName;
    public Friend setNickName(String nickName)
    {
        this.nickName = nickName;
        return this;
    }
}

이것은 작동합니다 :

new Friend().setNickName("Bart").setName("Barthelemy");

이것은 이클립스에서 받아 들여지지 않을 것이다! :

new Friend().setName("Barthelemy").setNickName("Bart");

setName ()은 친구가 아닌 사람을 반환하고 PeoplesetNickName이 없기 때문입니다.

클래스 이름 대신 SELF 클래스를 반환하도록 setter를 작성하는 방법은 무엇입니까?

이와 같은 것이 좋습니다 (SELF 키워드가 존재하는 경우). 어쨌든 존재합니까?

class People
{
    private String name;
    public SELF setName(String name)
    {
        this.name = name;
        return this;
    }
}

일반적으로 좋은 습관이지만, set-type 함수가 Boolean type을 사용하여 작업이 성공적으로 완료되었는지 여부를 결정해야 할 수도 있습니다. 일반적으로 이것이 좋거나 침대라고 말하는 교리가 없으며 물론 상황에서 비롯됩니다.

진술에서

list.add(new Employee().setName("Jack Sparrow").setId(1).setFoo("bacon!"));

나는 두 가지를보고있다

1) 무의미한 진술. 2) 가독성 부족.

읽기 어려울 수 있습니다

list.add(new Employee().setName("Jack Sparrow").setId(1).setFoo("bacon!")); 

아니면 이거

list.add(new Employee()
          .setName("Jack Sparrow")
          .setId(1)
          .setFoo("bacon!")); 

이것은 다음보다 읽기 쉽습니다.

Employee employee = new Employee();
employee.setName("Jack Sparrow")
employee.setId(1)
employee.setFoo("bacon!")); 
list.add(employee); 

나는 오랫동안 setter를 만들고 있었고 유일한 진짜 문제는 엄격한 getPropertyDescriptors를 사용하여 bean reader / writer bean 접근자를 얻는 라이브러리와 관련이 있습니다. 이 경우, Java "bean"에는 예상 한 writter가 없습니다.

예를 들어, 확실하게 테스트하지는 않았지만 Jackson이 json / maps에서 Java 객체를 만들 때 Jackson이 설정자를 인식하지 못한다는 사실에 놀라지 않습니다. 나는 이것에 대해 잘못되기를 바랍니다 (곧 테스트 할 것입니다).

사실, 나는 가벼운 SQL 중심 ORM을 개발 중이며 이것을 반환하는 인식 된 setter에 getPropertyDescriptors 코드를 추가해야합니다.

오래 전에 대답했지만 내 센트는 ... 괜찮습니다. 이 유창한 인터페이스가 더 자주 사용되기를 바랍니다.

'factory'변수를 반복해도 아래에 더 많은 정보가 추가되지 않습니다.

ProxyFactory factory = new ProxyFactory();
factory.setSuperclass(Foo.class);
factory.setFilter(new MethodFilter() { ...

이것은 더 깨끗합니다.

ProxyFactory factory = new ProxyFactory()
.setSuperclass(Properties.class);
.setFilter(new MethodFilter() { ...

물론 이미 언급 한 답변 중 하나 인 상속 및 도구와 같은 일부 상황 에서이 작업을 올바르게 수행하려면 Java API를 조정해야합니다.

가능한 경우 다른 언어 구문을 사용하는 것이 좋습니다. 예를 들어 Kotlin에서는 with , apply 또는 let을 사용 합니다. 이 방법을 사용하는 경우 실제로 setter에서 인스턴스를 반환 할 필요 가 없습니다 .

이 접근 방식을 통해 클라이언트 코드는 다음과 같습니다.

• 반환 유형에 무관심
• 손쉬운 유지
• 컴파일러 부작용 방지

여기 몇 가지 예가 있어요.

val employee = Employee().apply {
   name = "Jack Sparrow"
   id = 1
   foo = "bacon"
}


val employee = Employee()
with(employee) {
   name = "Jack Sparrow"
   id = 1
   foo = "bacon"
}


val employee = Employee()
employee.let {
   it.name = "Jack Sparrow"
   it.id = 1
   it.foo = "bacon"
}

API를 작성하는 경우 "return this"를 사용하여 한 번만 설정되는 값을 설정하십시오. 사용자가 변경할 수있는 다른 값이 있으면 표준 void setter를 대신 사용합니다.

그러나 그것은 실제로 선호의 문제이며 체인 세터는 상당히 시원하게 보입니다.

JavaBeans 사양을 위반한다고 주장하는 모든 포스터에 동의합니다. 그것을 보존해야 할 이유가 있지만, 나는 또한이 건축 자 패턴의 사용이 그 자리에 있다고 생각합니다. 모든 곳에서 사용되지 않는 한 수용 가능해야합니다. "장소"는 엔드 포인트가 "build ()"메서드를 호출하는 곳입니다.

물론 이러한 모든 것들을 설정하는 다른 방법이 있지만 여기서 장점은 1) 많은 매개 변수 공용 생성자와 2) 부분적으로 지정된 객체를 피한다는 것입니다. 여기에서 빌더가 필요한 것을 수집 한 후 마지막에 "build ()"를 호출하여 부분적으로 지정된 오브젝트가 구성되지 않도록 할 수 있습니다. 그 조작은 공개보다 덜 가시성이 부여 될 수 있기 때문입니다. 대안은 "매개 변수 객체"이지만, IMHO는 문제를 한 단계 뒤로 밀어냅니다.

많은 매개 변수 생성자를 싫어합니다. 많은 동일한 유형의 인수가 전달 될 가능성이 높기 때문에 잘못된 인수를 매개 변수에 쉽게 전달할 수 있습니다. 객체를 완전히 구성하기 전에 사용할 수 있기 때문에 많은 setter를 사용하는 것을 좋아하지 않습니다. 또한 이전 선택에 따라 기본값을 설정한다는 개념은 "build ()"메서드를 사용하는 것이 좋습니다.

요컨대 제대로 사용한다면 좋은 습관이라고 생각합니다.

나쁜 습관 : 세터가 게터를 얻는다

메소드를 명시 적으로 선언하면 어떨까요?

setPropertyFromParams(array $hashParamList) { ... }