게터와 세터가 정당화되는시기

게터와 세터는 종종 적절한 OO가 아니라고 비판합니다. 반면에 내가 본 대부분의 OO 코드에는 광범위한 게터와 세터가 있습니다.

게터와 세터는 언제 정당화됩니까? 그것들을 사용하지 않으려 고합니까? 그들은 일반적으로 남용됩니까?

좋아하는 언어에 속성 (광산)이있는 경우 이러한 질문은이 질문에 대한 게터 및 세터로 간주됩니다. 그것들은 OO 방법론 관점에서 똑같습니다. 그들은 더 좋은 구문을 가지고 있습니다.

Getter / Setter 비판의 출처 (일부 의견에서 더 나은 가시성을 제공하기 위해 가져옴) :

• http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html
• http://typicalprogrammer.com/?p=23
• http://c2.com/cgi/wiki?AccessorsAreEvil
• http://www.darronschall.com/weblog/2005/03/no-brain-getter-and-setters.cfm
• http://www.adam-bien.com/roller/abien/entry/encapsulation_violation_with_getters_and
• http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html

비판을 간단히 말하면 : Getter와 Setter를 사용하면 객체 외부에서 객체의 내부 상태를 조작 할 수 있습니다. 이것은 캡슐화를 위반합니다. 객체 자체 만 내부 상태를 관리해야합니다.

그리고 절차 적 코드 버전의 예입니다.

struct Fridge
{
    int cheese;
}

void go_shopping(Fridge fridge)
{
     fridge.cheese += 5;
}

코드의 뮤 테이터 버전 :

class Fridge
{
     int cheese;

     void set_cheese(int _cheese) { cheese = _cheese; }
     int get_cheese() { return cheese; }
 }

void go_shopping(Fridge fridge)
{
     fridge.set_cheese(fridge.get_cheese() + 5);        
}

getter와 setter는 적절한 캡슐화없이 코드를 훨씬 더 복잡하게 만들었습니다. 내부 상태는 다른 객체에 액세스 할 수 있기 때문에 이러한 게터와 세터를 추가하여 많은 것을 얻지 못합니다.

이 질문은 이전에 스택 오버플로에서 논의되었습니다.

• https://stackoverflow.com/questions/565095/java-are-getters-and-setters-evil
• https://stackoverflow.com/questions/996179

게터와 세터가 있다고해서 캡슐화가 깨지는 것은 아닙니다. 캡슐화를 깨뜨리는 것은 모든 데이터 멤버 ( Java lingo의 모든 필드 )에 대해 아무런 생각없이 자동으로 getter 및 setter를 추가하는 것입니다. 이것은 모든 데이터 멤버를 공개하는 것보다 낫지 만 조금만 걸 으면됩니다.

캡슐화의 요점은 당신이 알고 또는 객체 외부에서 개체의 상태를 변경할 수 없게하는 것,하지만 당신은 합리적인있는 것이 아니다 정책 을 수행하기위한합니다.

• 일부 데이터 멤버는 객체 내부에있을 수 있으며 게터 나 세터가 없어야합니다.

• 일부 데이터 멤버는 읽기 전용이어야하므로 게터가 필요하지만 세터는 필요하지 않을 수 있습니다.

• 일부 데이터 멤버는 서로 일관성을 유지해야 할 수도 있습니다. 이 경우 각 설정기에 대해 세터를 제공하지 않고 동시에 설정하는 단일 방법을 제공하므로 값의 일관성을 확인할 수 있습니다.

• 일부 데이터 멤버는 일정량 씩 증가 또는 감소와 같은 특정 방식으로 만 변경하면됩니다. 이 경우 세터 대신 increment()및 / 또는 decrement()메소드를 제공해야합니다 .

• 그러나 다른 사람들은 실제로 읽기 / 쓰기가 필요할 수 있으며 게터와 세터가 모두 있어야합니다.

의 예를 고려하십시오 class Person. 사람의 이름, 사회 보장 번호 및 연령이 있다고 가정 해 봅시다. 사람들이 이름이나 주민등록번호를 변경하는 것을 허용하지 않는다고 가정 해 봅시다. 그러나 사람의 나이는 매년 1 씩 증가해야합니다. 이 경우 이름과 SSN을 지정된 값으로 초기화하고 나이를 0으로 초기화하는 생성자를 제공합니다. 또한 incrementAge()나이를 1 씩 증가시키는 메소드 도 제공합니다. 세 가지 모두에 대한 게터. 이 경우 세터가 필요하지 않습니다.

이 디자인에서는 클래스 외부에서 오브젝트의 상태를 검사하고 클래스 외부에서 오브젝트를 변경할 수 있습니다. 그러나 상태를 임의로 변경할 수는 없습니다. 이름과 SSN을 전혀 변경할 수 없으며 연령을 한 번에 1 년씩 증분 할 수 있다는 정책이 있습니다.

이제 사람에게 급여가 있다고 가정 해 봅시다. 그리고 사람들은 마음대로 일자리를 바꿀 수 있습니다. 즉, 급여도 바뀔 것입니다. 이 상황을 모델링하기 위해 다른 방법은 없습니다 setSalary(). 이 경우 연봉 변경을 허용하는 것이 완벽하게 합리적인 정책입니다.

그런데, 귀하의 예제에서, 나는 클래스 줄 것 과 대신의 방법을, 하고 . 그러면 여전히 캡슐화가 발생합니다.FridgeputCheese()takeCheese()get_cheese()set_cheese()

public class Fridge {
  private List objects;
  private Date warranty;

  /** How the warranty is stored internally is a detail. */
  public Fridge( Date warranty ) {
    // The Fridge can set its internal warranty, but it is not re-exposed.
    setWarranty( warranty );
  }

  /** Doesn't expose how the fridge knows it is empty. */
  public boolean isEmpty() {
    return getObjects().isEmpty();
  }

  /** When the fridge has no more room... */
  public boolean isFull() {
  }

  /** Answers whether the given object will fit. */
  public boolean canStore( Object o ) {
    boolean result = false;

    // Clients may not ask how much room remains in the fridge.
    if( o instanceof PhysicalObject ) {
      PhysicalObject po = (PhysicalObject)o;

      // How the fridge determines its remaining usable volume is a detail.
      // How a physical object determines whether it fits within a specified
      // volume is also a detail.
      result = po.isEnclosedBy( getUsableVolume() );
    }

     return result;
  }

  /** Doesn't expose how the fridge knows its warranty has expired. */
  public boolean isPastWarranty() {
    return getWarranty().before( new Date() );
  }

  /** Doesn't expose how objects are stored in the fridge. */
  public synchronized void store( Object o ) {
    validateExpiration( o );

    // Can the object fit?
    if( canStore( o ) ) {
      getObjects().add( o );
    }
    else {
      throw FridgeFullException( o );
    }
  }

  /** Doesn't expose how objects are removed from the fridge. */
  public synchronized void remove( Object o ) {
    if( !getObjects().contains( o ) ) {
      throw new ObjectNotFoundException( o );
    }

    getObjects().remove( o );

    validateExpiration( o );
  }

  /** Lazily initialized list, an implementation detail. */
  private synchronized List getObjects() {
    if( this.list == null ) { this.list = new List(); }
    return this.list;
  }

  /** How object expiration is determined is also a detail. */
  private void validateExpiration( Object o ) {
    // Objects can answer whether they have gone past a given
    // expiration date. How each object "knows" it has expired
    // is a detail. The Fridge might use a scanner and
    // items might have embedded RFID chips. It's a detail hidden
    // by proper encapsulation.
    if( o implements Expires && ((Expires)o).expiresBefore( today ) ) {
      throw new ExpiredObjectException( o );
    }
  }

  /** This creates a copy of the warranty for immutability purposes. */
  private void setWarranty( Date warranty ) {
    assert warranty != null;
    this.warranty = new Date( warranty.getTime() )
  }
}

Java에서 getter 및 setter의 기본 이유는 매우 간단합니다.

• 인터페이스에서는 필드가 아닌 메소드 만 지정할 수 있습니다 .

따라서 필드가 인터페이스를 통과하게하려면 리더와 라이터 메소드가 필요합니다. 이들은 일반적으로 필드 x에 대해 getX 및 setX라고합니다.

에서 http://www.adam-bien.com/roller/abien/entry/encapsulation_violation_with_getters_and

자바 빈즈 스타일 :

connection.setUser("dukie");
connection.setPwd("duke");
connection.initialize();

OO 스타일 :

connection.connect("dukie","duke");

글쎄, 나는 후자의 접근법을 선호한다. 구현 세부 사항을 피하지 않고 더 간단하고 간결하며 필요한 모든 정보가 메서드 호출에 포함되어 있으므로 올바르게 얻을 수 있습니다. 또한 가능할 때마다 생성자에서 매개 변수를 사용하여 개인 멤버를 설정하는 것을 선호합니다.

귀하의 질문은 언제 getter / setter가 정당화되는 것입니까? 아마도 모드 변경이 필요하거나 정보를 얻기 위해 개체를 조사해야 할 때가 있습니다.

myObject.GetStatus();
myObject.SomeCapabilitySwitch = true;

그것에 대해 생각할 때, C #으로 코딩을 처음 시작했을 때 위에서 설명한 Javabeans 스타일로 많은 코드를 작성했습니다. 그러나 언어에 대한 경험을 쌓으면서 생성자에서 더 많은 멤버를 설정하고 위의 OO 스타일과 유사한 메소드를 사용하기 시작했습니다.

게터와 세터는 언제 정당화됩니까?

동작 "get"및 "set"이 실제로 모델의 동작과 일치 할 때 실제로는 결코 그렇지 않습니다 .

비즈니스 영역의 동작이 명확하지 않기 때문에 다른 모든 용도는 속임수입니다.

편집하다

그 대답은 플립 팬트로 나타 났을 것입니다. 위의 답변은 대부분 정확하지만 OO 디자인의 프로그래밍 패러다임과 큰 그림을 놓친 부분에 중점을 둡니다. 내 경험상 이것은 사람들로 하여금 get과 setter를 피하는 것이 OO 프로그래밍 언어의 학문적 규칙이라고 생각하게합니다 (예 : 사람들은 getter를 속성으로 대체하는 것이 웅장하다고 생각합니다)

실제로 이는 설계 프로세스의 결과입니다. 인터페이스와 캡슐화 및 패턴에 빠질 필요가 없으며 이러한 패러다임을 깨뜨릴 것인지 아닌지, 그리고 OO 프로그래밍이 좋은지 아닌지를 논쟁합니다. 궁극적으로 중요한 점은 도메인에 이런 식으로 작동하는 도메인이 없으면 도메인을 모델링하지 않는다는 것입니다.

실제로는 도메인 공간의 시스템에 게터와 세터가있을 가능성이 거의 없습니다. 급여를 담당하는 남녀에게 걸어 가서 "이 급여를 X로 설정하십시오" 또는 "이 급여를 받으십시오 " 라고 간단히 말 하십시오 . 그러한 행동은 단순히 존재하지 않습니다

이것을 코드에 넣으면 도메인 모델과 일치하도록 시스템을 설계하지 않은 것입니다. 예, 인터페이스와 캡슐화를 깨뜨 렸지만 요점은 아닙니다. 요점은 존재하지 않는 것을 모델링하고 있다는 것입니다.

더 이상 당신은 아마도 중요한 단계 또는 프로세스를 잃어 버릴 것입니다. 왜냐하면 내가 롤을 지불 하고이 급여를 X로 설정한다고 말할 수없는 이유가있을 수 있기 때문입니다.

사람들이 게터와 세터를 사용할 때이 프로세스에 대한 규칙을 잘못된 위치로 밀어 넣는 경향이 있습니다. 이것은 도메인에서 훨씬 더 멀어지고 있습니다. 실제 예를 사용하면, 들어간 임의의 사람이 이러한 값을 얻을 수있는 권한이 있다고 가정하면 급여와 같습니다. 그렇지 않으면 값을 요구하지 않을 것입니다. 그것은 도메인의 상태뿐만 아니라 실제로 도메인의 상태에 관한 것입니다.

일반적으로 게터와 세터는 나쁜 생각입니다. 필드가 논리적으로 인터페이스의 일부가 아니고 개인으로 만들면 괜찮습니다. 논리적으로 인터페이스의 일부이고 공용으로 만들면 괜찮습니다. 그러나 비공개로 만든 다음 게터와 세터를 제공하여 다시 공개하고 효과적으로 공개하면 코드가 더 장황하고 난독 화 된 것을 제외하고 시작한 곳으로 돌아갑니다.

분명히 예외가 있습니다. Java에서는 인터페이스를 사용해야합니다. Java 표준 라이브러리는 일반적인 코드 품질 측정치보다 훨씬 높은 역 호환성 요구 사항을 갖습니다. 실제로 전설을 다루는 경우도 있지만 인터페이스를 손상시키지 않고 저장된 필드를 즉석 계산으로 바꿀 수도 있습니다. 그러나 이것들은 예외입니다. 게터와 세터는 특별한 타당성을 요구하는 반 패턴입니다.

필드가 직접적으로 접근 가능한지 아니면 방법을 통해 접근 할 수 있는지 여부는 실제로 중요하지 않습니다.

클래스 불변 (유용한 것)이 중요합니다. 그리고 그것들을 보존하기 위해 때때로 외부에서 무언가를 바꿀 수 없어야합니다. 예 : 너비와 높이가 분리 된 Square 클래스가 있으면 그 중 하나를 변경하면 사각형이 아닌 다른 것이됩니다. 따라서 메소드 변경이 필요합니다. Rectangle 인 경우 setters / public 필드를 가질 수 있습니다. 그러나 0보다 큰지 테스트하는 것이 더 좋습니다.

그리고 구체적인 언어 (예 : java)로 우리가 그러한 메소드 (인터페이스)가 필요한 이유입니다. 방법의 또 다른 이유는 호환성 (소스 및 이진)입니다. 따라서 추가하기가 더 쉬워서 공공 장소가 충분한 지 생각합니다.

btw. 공개 최종 필드와 함께 간단한 불변 값 보유 클래스를 사용하고 싶습니다.

인터페이스를 동일하게 유지하면서 내부를 무엇이든 바꿀 수 있습니다. 인터페이스가 다양하지 않으면 코딩하지 않습니다. 당신은 여전히 ​​당신이 원하는대로 내부를 변경할 수 있습니다.

내 접근 방식은 이것입니다-

나중에 데이터와 함께 수수께끼를 기대할 때 getter / setter가 정당화됩니다. 또한 변경이 발생하면 종종 데이터를 getter / setter로 푸시합니다.

POD 구조라면 슬롯을 사용할 수 있습니다.

보다 추상적 인 수준에서 문제는 "데이터를 관리하는 사람"이며 프로젝트에 따라 다릅니다.

게터와 세터를 사용하는 것이 복잡하다고 생각되면 개념 자체가 아닌 언어 문제 일 수 있습니다.

다음 은 Ruby로 작성된 두 번째 예제 의 코드입니다 .

class Fridge
  attr_accessor :cheese
end

def go_shopping fridge
  fridge.cheese += 5
end

Java 의 첫 번째 예제 와 매우 비슷 합니까? 게터와 세터가 일류 시민으로 취급 될 때, 그들은 사용하기 힘든 일이 아니며, 추가 된 유연성이 때로는 실질적인 이익이 될 수 있습니다. 예를 들어, 새로운 냉장고에서 치즈의 기본값을 반환하기로 결정할 수 있습니다.

class Fridge
  attr_accessor :cheese

  def cheese
    @cheese || 0
  end
end

물론 공개적으로 노출되어서는 안되는 변수가 많이 있습니다. 내부 변수를 불필요하게 노출하면 코드가 더 나빠지지만 게터와 세터에서 그 코드를 탓할 수는 없습니다.

Size너비와 높이를 캡슐화 하는 클래스를 고려하십시오 . 생성자를 사용하여 세터를 제거 할 수는 있지만 어떻게 사각형을 그리는 데 도움이 Size됩니까? 너비와 높이는 클래스의 내부 데이터가 아닙니다. 그들은 크기의 소비자가 사용할 수있는 공유 데이터입니다.

객체는 동작과 상태 또는 속성으로 구성됩니다. 노출 된 상태가 없으면 동작 만 공개됩니다.

상태가 없으면 개체 컬렉션을 어떻게 정렬 하시겠습니까? 객체의 특정 인스턴스를 어떻게 검색 하시겠습니까? 생성자 만 사용하는 경우 객체에 긴 속성 목록이 있으면 어떻게됩니까?

검증없이 메소드 매개 변수를 사용해서는 안됩니다. 따라서 쓰는 게으름입니다.

setMyField(int myField){
    this.myField = myField;
}

그런 식으로 쓰면 적어도 세터를 사용하여 유효성을 검사 할 준비가 된 것입니다. 공공 장소보다 낫지 만 간신히. 그러나 최소한 고객의 코드를 위반하지 않고 되돌아와 유효성 검사 규칙을 적용 할 수있는 일관된 공용 인터페이스가 있습니다.

게터, 세터, 프로퍼티, 뮤 테이터는 여러분이 원하는대로 부르지 만 필요합니다.

게터와 세터가 캡슐화와 진정한 OO를 위반하면 심각한 문제가 발생합니다.

나는 항상 당신이 필요로하는 것이 무엇이든 마음에 드는 것을 나타내는 물체를 느꼈습니다.

Java로 Maze를 생성하는 프로그램 작성을 마쳤으며 "Maze Squares"를 나타내는 클래스가 있습니다. 이 클래스에는 좌표, 벽 및 부울 등을 나타내는 데이터가 있습니다.

이 데이터를 변경 / 조작 / 액세스 할 수있는 방법이 필요합니다! 게터와 세터없이 무엇을해야합니까? Java는 속성을 사용하지 않으며이 클래스에 로컬 인 모든 데이터를 public으로 설정하는 것은 분명히 캡슐화 및 OO의 위반입니다.

첫째, 가치와 서비스 유형이라는 두 가지 유형의 객체가 있습니다.

서비스 유형에는 setter가 없어야합니다. 필요한 종속성은 gettable이 아니어야합니다. 종속성을 전달하는 가장 좋은 방법은 생성자 또는 팩토리를 통해 모든 인스턴스가 처음부터 평범하고 단순하게 완전히 구성되는 방식입니다.

ORM과 같이 실용적이지 않거나 위젯에서 객체로의 다른 매핑과 같은 실용적이지 않은 경우도 있습니다. 한 계층에서 다른 계층으로 시스템을 통과하는 다른 모든 값 유형은 변경할 수 없으며 설정자가 없어야합니다.

Getter / Setter는 다른 공용 메소드와 마찬가지로 정당화됩니다. 정당화는 주로 클래스가 다른 클래스와 상호 작용하는 방식을 정의하는 인터페이스를 외부 세계에 제공하려고하기 때문입니다. 우리는 주로 별도의 엔티티 사이의 커플 링을 줄이려고하기 때문에이를 수행합니다. 여러 가지 이유로 커플 링을 줄이는 것이 좋습니다.

• 현재 클래스에서 동일한 클래스 인터페이스를 사용할 수 있지만 그 동안 클래스에는 새로운 메소드가 추가되었지만 이전 인터페이스는 유지됩니다.
• 소비자에게 영향을 미치지 않고 클래스의 내부 표현을 변경할 수 있습니다
• 버그 발생 가능성 감소 : 내부 데이터를 비공개로 설정하면 외부 코드가 내부 데이터와 충돌하지 않는지 확인할 수 있습니다.

예, getter 및 setter는 객체 지향 프로그래밍의 반 패턴이며 http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html 과 같이 사용 해서는 안됩니다 . 간단히 말해서, 객체 지향 패러다임에는 적합하지 않습니다. 데이터 구조처럼 객체를 처리하도록 권장하기 때문입니다. 이것은 중요한 오해입니다.

프로그래밍 언어 자동 생성을 개발하는 회사가 개발 한 IDE가 "객체 지향의 원칙"을 위반하지 않기를 바랍니다.

즉, 공개 범위 변수가있을 때마다 게터와 세터를 사용하면 황금색입니다. 마치 엄청나게 많은 코드처럼 보일지라도 캡슐화의 객체 지향 원칙의 필수 요소 인 것 같습니다.

그것들을 사용하는 이유는 적절한 캡슐화가 아직 이루어질 수 있고 객체를 원숭이가 객체를 느끼는 사람이 객체를 느끼게하는 레이어를 추상화하지 않는 한 올바르게 알지 않고도 객체를 가져갈 수 있기 때문입니까?

충분히 말하면, 분할 된 주택은 참을 수 없으며 OO의 입주자 중 하나는 스스로 켜지지 않으며 캡슐화와 조기 최적화를 모두 제공 할 수 없습니다.

나는 우리가 여기에 더 일반적인 대답을 줄 것이라고 생각 했습니까?

게터와 세터는 일반적으로 매우 OOP입니다 (다른 것을 잘못 말하는 사람은 그렇게 간단합니다).

오버 엔지니어링을하지 않아도된다는 것을 기억해야하지만 필요없는 게터 나 세터를 만들지 마십시오. 다른 클래스에서 사용하지 않을 정보는 getter 또는 setter가 없어야합니다.

하지만 필드를 공개하지 않고 게터와 세터가있는 이유는 대부분 다음과 같습니다.

• 필드를 사용하여 적절한 테스트를 수행 할 수 없습니다. 그런 점에서 게터 / 세터가 훨씬 좋습니다.

• 실시간 프로그래밍 설정에서 필드를 올바르게 사용하는 것은 불가능합니다. 동기화 된 게터 / 세터가 갈 길입니다.

• 인터페이스 주제 (이미 설명하지 않았으므로).

• 시스템을 올바르게 재사용 할 때 사용하기가 더 쉽습니다.

• 클래스를 사용하는 클래스와 getter / setter보다 필드를 변경하면 어떤 클래스가 중단되는지 알기가 훨씬 어렵습니다.

따라서 게터 / 세터 대신 퍼블릭 필드를 사용하는 유일한 경우는 공식 프로젝트를 만들지 않고 단지 재미를 위해 게터를 쓰거나 게터 / 세터를 방해 할 수없는 경우입니다.