게터와 세터 / 액세서를 사용하는 이유는 무엇입니까?

변수에 공용 필드를 사용하는 대신 getter 및 setter를 사용하면 얻을 수있는 장점은 무엇입니까?

getter와 setter가 단순한 get / set 이상의 기능을 수행하는 경우이 정보를 매우 빠르게 파악할 수 있지만 방법에 대해서는 100 % 명확하지 않습니다.

public String foo;

다음보다 더 나쁘다 :

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

전자는 상용구 코드가 훨씬 적습니다.

실제로이 있습니다 많은 좋은 이유 접근을 사용하는 것을 고려하는 캡슐화 단지 인수를 넘어 미래를 쉽게 변경하기 -보다는 직접 클래스의 필드를 노출은.

내가 알고있는 몇 가지 이유는 다음과 같습니다.

• 속성 가져 오기 또는 설정과 관련된 동작 캡슐화-유효성 검사와 같은 추가 기능을 나중에 더 쉽게 추가 할 수 있습니다.
• 대체 표현을 사용하여 속성을 노출시키면서 속성의 내부 표현을 숨 깁니다.
• 퍼블릭 인터페이스를 변경으로부터 보호-기존 소비자에게 영향을주지 않으면 서 구현이 변경되는 동안 퍼블릭 인터페이스를 일정하게 유지할 수 있습니다.
• 속성의 수명 및 메모리 관리 (처분) 시맨틱 제어-특히 관리되지 않는 메모리 환경 (C ++ 또는 Objective-C)에서 중요합니다.
• 런타임에 속성이 변경 될 때 디버깅 차단 지점 제공-일부 언어에서는 속성이 특정 값으로 변경된 시점과 위치를 디버깅하는 것이 매우 어려울 수 있습니다.
• 속성 게터 / 세터에 대해 작동하도록 설계된 라이브러리와의 향상된 상호 운용성-Mocking, Serialization 및 WPF가 떠 오릅니다.
• 상속자가 getter / setter 메서드를 재정 의하여 속성의 동작 및 노출 방식에 대한 의미를 변경할 수 있도록합니다.
• getter / setter를 값이 아닌 람다 식으로 전달할 수 있습니다.
• 게터와 세터는 서로 다른 액세스 수준을 허용 할 수 있습니다 (예 : get은 공개적이지만 집합은 보호 될 수 있음).

지금부터 2 주 (월, 년) 동안 세터가 단순히 값을 설정하는 것보다 더 많은 일을해야한다는 것을 깨달았 기 때문에이 속성이 238 개의 다른 클래스에서 직접 사용되었다는 것을 알게 될 것입니다. :-)

공개 필드는 필드를 반환하고 할당하는 것 외에는 아무것도하지 않는 getter / setter 쌍보다 나쁘지 않습니다. 첫째, (대부분의 언어에서) 기능상의 차이가 없다는 것이 분명합니다. 차이는 유지 관리 성 또는 가독성과 같은 다른 요소에 있어야합니다.

getter / setter 쌍의 장점은 그렇지 않습니다. 구현을 변경할 수 있으며 클라이언트를 다시 컴파일 할 필요가 없다는 주장이 있습니다. 아마도 setter를 사용하면 나중에 유효성 검사와 같은 기능을 추가 할 수 있으며 클라이언트도 알 필요가 없습니다. 그러나 세터에 유효성 검사를 추가하는 것은 이전 계약을 위반 하는 전제 조건의 변경 입니다. 이는 단순히 "여기에 아무 것도 넣을 수 있으며 나중에 게터에서 같은 것을 얻을 수 있습니다"라는 것입니다.

따라서 계약을 파기 했으므로 코드베이스의 모든 파일을 변경하는 것은 피해야 할 일입니다. 피하지 않으면 모든 코드가 해당 메소드의 계약이 다르다고 가정합니다.

이것이 계약이 아니어야한다면, 인터페이스는 클라이언트가 객체를 유효하지 않은 상태로 놓을 수 있도록 허용 한 것입니다. 이것이 캡슐화의 정반대입니다. 해당 필드를 처음부터 아무것도 설정할 수 없다면 왜 처음부터 검증이 이루어지지 않았습니까?

이와 같은 주장은 이러한 통과 게터 / 세터 쌍의 다른 가정 된 장점에도 적용됩니다. 나중에 설정중인 값을 변경하기로 결정하면 계약을 위반하게됩니다. 파생 클래스에서 기본 기능을 재정의하면 몇 가지 무해한 수정 (예 : 로깅 또는 기타 관찰 할 수없는 동작)을 넘어 서면 기본 클래스의 계약을 위반하게됩니다. 이는 OO의 신조 중 하나로 여겨지는 Liskov Substitutability Principle을 위반하는 것입니다.

클래스에 모든 필드에 대해 이러한 벙어리 게터와 세터가있는 경우, 불변성이 없고 계약 이없는 클래스입니다 . 이것이 실제로 객체 지향 디자인입니까? 모든 클래스에 게터와 세터가 있다면 바보 데이터 홀더 일뿐이며 바보 데이터 홀더는 바보 데이터 홀더처럼 보일 것입니다.

class Foo {
public:
    int DaysLeft;
    int ContestantNumber;
};

이러한 클래스에 패스 스루 게터 / 세터 쌍을 추가하면 값이 추가되지 않습니다. 다른 클래스는 필드가 이미 제공 한 작업뿐만 아니라 의미있는 작업을 제공해야합니다. 이것이 유용한 불변량을 정의하고 유지할 수있는 방법입니다.

클라이언트 : "이 클래스의 객체로 무엇을 할 수 있습니까?"
디자이너 : "여러 변수를 읽고 쓸 수 있습니다."
클라이언트 : "아 ... 근사한 것 같아?"

게터와 세터를 사용해야 할 이유가 있지만, 그 이유가 존재하지 않으면 거짓 캡슐화 신의 이름으로 게터 / 세터 쌍을 만드는 것은 좋지 않습니다. 게터 나 세터를 만드는 유효한 이유에는 유효성 검사 또는 다른 내부 표현과 같이 나중에 변경할 수있는 잠재적 변경 사항으로 자주 언급되는 사항이 포함됩니다. 또는 클라이언트가 값을 읽을 수는 있지만 쓸 수는 없지만 (예 : 사전의 크기를 읽는 것) 간단한 getter를 선택하는 것이 좋습니다. 그러나 이러한 이유는 나중에 원하는 잠재적 인 것이 아니라 선택을 할 때 있어야합니다. 이것은 YAGNI의 인스턴스입니다 ( You Ai n't Gonna Need It ).

많은 사람들이 게터와 세터의 장점에 대해 이야기하지만 저는 악마의 옹호자를하고 싶습니다. 지금은 프로그래머가 모든 게터와 세터를 만들기로 결정한 매우 큰 프로그램을 디버깅하고 있습니다. 멋지게 보일지 모르지만 리버스 엔지니어링의 악몽입니다.

수백 줄의 코드를 살펴보고 다음과 같은 내용을 접한다고 가정 해보십시오.

person.name = "Joe";

세터를 깨닫기 전까지는 아주 간단하게 코드입니다. 이제 해당 세터를 따라 person.firstName, person.lastName, person.isHuman, person.hasReallyCommonFirstName을 설정하고 person.update ()를 호출하여 데이터베이스로 쿼리를 보내는 등을 찾습니다. 메모리 누수가 발생한 위치

로컬 코드를 한눈에 이해하는 것은 게터와 세터가 깨지기 쉬운 가독성의 중요한 속성입니다. 그렇기 때문에 가능한 한 피하는 것을 피하고 사용하면하는 일을 최소화하려고합니다.

순수한 객체 지향 세계에서 게터와 세터는 끔찍한 안티 패턴 입니다. 이 기사를 읽으십시오 : Getters / Setters. 악. 기간 . 간단히 말해서 프로그래머는 데이터 구조를 기준으로 객체에 대해 생각하도록 장려하며 이러한 유형의 사고는 순수한 절차 적입니다 (COBOL 또는 C와 같이). 객체 지향 언어에는 데이터 구조가 없지만 동작을 노출하는 객체 만 있습니다 (속성 / 속성이 아님).

Elegant Objects의 3.5 절 (객체 지향 프로그래밍에 관한 저서) 에서 더 많은 것을 찾을 수 있습니다 .

여러 가지 이유가 있습니다. 내가 가장 좋아하는 것은 동작을 변경하거나 변수에 설정할 수있는 것을 조절해야 할 때입니다. 예를 들어 setSpeed ​​(int speed) 메서드가 있다고 가정 해 봅시다. 그러나 최대 속도 100 만 설정할 수 있기를 원합니다.

public void setSpeed(int speed) {
  if ( speed > 100 ) {
    this.speed = 100;
  } else {
    this.speed = speed;
  }
}

이제 코드의 어디에나 퍼블릭 필드를 사용하고 있고 위의 요구 사항이 필요하다는 것을 깨달았다면 어떻게해야합니까? 세터를 수정하는 대신 퍼블릭 필드의 모든 사용법을 재미있게 찾아보십시오.

내 2 센트 :)

접근 자와 뮤 테이터의 장점 중 하나는 유효성 검사를 수행 할 수 있다는 것입니다.

예를 들어 foo공개 된 경우 쉽게 설정하고 null다른 사람이 객체에서 메소드를 호출하려고 시도 할 수 있습니다. 그러나 더 이상 존재하지 않습니다! setFoo방법을 사용하면 foo결코 설정되지 않았습니다 null.

접근 자와 뮤 테이터는 또한 캡슐화를 허용합니다. 값이 일단 설정되면 (생성자에서 설정되고 메소드에서 사용되지만 절대 변경되지 않아야 함) 값을 볼 수 없다면 아무도 볼 수 없습니다. 그러나 다른 클래스에서 보거나 변경하도록 허용하는 경우 적절한 접근 자 및 / 또는 뮤 테이터를 제공 할 수 있습니다.

언어에 따라 다릅니다. "Java"가 아닌 "object-oriented"에 태그를 달았으므로 ChssPly76의 답변은 언어에 따라 다릅니다. 예를 들어 파이썬에서는 게터와 세터를 사용할 이유가 없습니다. 동작을 변경해야하는 경우 기본 속성 액세스를 통해 getter 및 setter를 랩핑하는 특성을 사용할 수 있습니다. 이 같은:

class Simple(object):
   def _get_value(self):
       return self._value -1

   def _set_value(self, new_value):
       self._value = new_value + 1

   def _del_value(self):
       self.old_values.append(self._value)
       del self._value

   value = property(_get_value, _set_value, _del_value)

글쎄, 때로는 변수 / 객체의 캡슐화 및 보안에 필요한 경우에도 실제 객체 지향 프로그램을 코딩하려는 경우 액세서리 오버 스톱 을 중지 해야하며 때로는 우리가 많이 의존해야합니다. 실제로 필요하지 않을 때 변수를 공개하는 것과 거의 동일합니다.

고마워, 정말 내 생각을 명확히했다. 이제 getter와 setter를 사용하지 말아야 할 10 가지 이유가 있습니다.

1. 단순히 값을 설정하고 얻는 것 이상의 일을해야한다는 것을 깨닫게되면 필드를 비공개로 설정하면 바로 액세스 한 위치를 즉시 알 수 있습니다.
   
2. 거기에서 수행하는 모든 유효성 검사에는 컨텍스트가 없을 수 있으며 실제로는 거의 유효하지 않습니다.
   
3. 설정되는 값을 변경할 수 있습니다. 이것은 발신자가 당신에게 [쇼크 호러] 당신이 그대로 저장하기를 원하는 값을 전달할 때 절대 악몽입니다.
   
4. 내부 표현을 숨길 수 있습니다-환상적이므로 모든 작업이 대칭인지 확인하고 있습니까?
   
5. 시트 아래의 변경 사항으로부터 공용 인터페이스를 격리했습니다. 인터페이스를 디자인하고 있고 무언가에 직접 액세스 할 수 있는지 확실하지 않은 경우 계속 디자인해야합니다.
   
6. 일부 라이브러리는 이것을 기대하지만 반사, 직렬화, 모의 객체는 모두 공공 장소에서 잘 작동합니다.
   
7. 이 클래스를 상속하면 기본 기능을 재정의 할 수 있습니다. 즉, 구현을 숨기고 일관성이 없어서 호출자를 혼란스럽게 할 수 있습니다.
   

내가 마지막으로 떠나는 마지막 3 명 (N / A 또는 D / C) ...

약간 늦었지만 성능에 관심이있는 사람들이 있다고 생각합니다.

약간의 성능 테스트를 수행했습니다. 나는 정수를 보유하고있는 "NumberHolder"클래스를 작성했다. getter 메소드를 사용하거나을 anInstance.getNumber()사용하여 숫자에 직접 액세스 하여 해당 정수를 읽을 수 있습니다 anInstance.number. 내 프로그램은 두 가지 방법으로 1,000,000,000 번을 읽습니다. 이 과정이 5 번 반복되고 시간이 인쇄됩니다. 다음과 같은 결과가 나타납니다.

Time 1: 953ms, Time 2: 741ms
Time 1: 655ms, Time 2: 743ms
Time 1: 656ms, Time 2: 634ms
Time 1: 637ms, Time 2: 629ms
Time 1: 633ms, Time 2: 625ms

(시간 1은 직접적인 방법이고 시간 2는 게터입니다)

알다시피, 게터는 (거의) 항상 조금 더 빠릅니다. 그런 다음 다른 횟수의 사이클로 시도했습니다. 1 백만 대신 1 천만 및 0.1 백만을 사용했습니다. 결과 :

천만 사이클 :

Time 1: 6382ms, Time 2: 6351ms
Time 1: 6363ms, Time 2: 6351ms
Time 1: 6350ms, Time 2: 6363ms
Time 1: 6353ms, Time 2: 6357ms
Time 1: 6348ms, Time 2: 6354ms

천만 사이클로 시간은 거의 동일합니다. 10 만 사이클은 다음과 같습니다.

Time 1: 77ms, Time 2: 73ms
Time 1: 94ms, Time 2: 65ms
Time 1: 67ms, Time 2: 63ms
Time 1: 65ms, Time 2: 65ms
Time 1: 66ms, Time 2: 63ms

또한 다른 사이클 양으로 인해 게터는 일반적인 방식보다 약간 빠릅니다. 이것이 도움이 되었기를 바랍니다.

현재 제공에 필요한 경우가 아니면 getters setter를 사용하지 마십시오. 즉, 대부분의 프로덕션 응용 프로그램, 시스템에서 변경 요청이 변경 될 경우 향후 어떤 일이 발생할 지에 대해 너무 많이 생각하지 마십시오.

간단하고 쉽게 생각하고 필요할 때 복잡성을 추가하십시오.

나는 심도 깊은 기술 소유자의 무지를 활용하지 않을 것입니다. 그것이 옳다고 생각하거나 접근 방식을 좋아한다는 이유 만 알고 있습니다.

액세스 수정 자 및 n 비즈 로직을 검증하는 몇 가지 방법으로 만 getters setter없이 작성된 대규모 시스템이 있습니다. 당신이 절대적으로 필요한 경우. 무엇이든 사용하십시오.

우리는 getter와 setter를 사용합니다 :

• 재사용 성
• 프로그래밍의 후기 단계에서 검증을 수행

Getter 및 Setter 메서드는 개인 클래스 멤버에 액세스하기위한 공용 인터페이스입니다.

캡슐화 만트라

캡슐화 만트라는 필드를 개인용 및 메소드를 공용으로 만드는 것입니다.

Getter 메서드 : 개인 변수에 액세스 할 수 있습니다.

세터 메소드 : 개인 필드를 수정할 수 있습니다.

getter 및 setter 메소드가 새로운 기능을 추가하지 않더라도 나중에 다시 해당 메소드를 작성하도록 마음을 바꿀 수 있습니다.

• 보다 나은;
• 더 안전한; 과
• 빨리.

값을 사용할 수있는 곳이면 해당 값을 반환하는 메소드를 추가 할 수 있습니다. 대신에:

int x = 1000 - 500

사용하다

int x = 1000 - class_name.getValue();

평신도의 관점에서

이것의 세부 사항을 저장해야한다고 가정하자 Person. 이 Person필드를 가지고 name, age하고 sex. 이를 위해서는 name, age및에 대한 메소드를 작성해야합니다 sex. 우리가 다른 사람을 만들 필요하다면 지금, 그것은을위한 방법을 만들 필요가 name, age, sex다시 한번를.

이를 수행하는 대신 class(Person)getter 및 setter 메소드를 사용하여 Bean 을 작성할 수 있습니다 . 따라서 내일 우리는 class(Person class)새로운 사람을 추가해야 할 때마다이 Bean의 객체를 만들 수 있습니다 (그림 참조). 따라서 빈 클래스의 필드와 메소드를 재사용하는 것이 훨씬 좋습니다.

Java 케이스에 대해 이것을 생각하는 데 꽤 오랜 시간을 보냈으며 실제 이유는 다음과 같습니다.

1. 구현이 아닌 인터페이스에 대한 코드
2. 인터페이스는 필드가 아닌 메소드 만 지정합니다.

즉, 인터페이스에서 필드를 지정할 수있는 유일한 방법은 새 값을 작성하는 방법과 현재 값을 읽는 방법을 제공하는 것입니다.

그 방법은 악명 높은 게터와 세터입니다 ....

지연 로딩에 유용 할 수 있습니다. 문제의 객체가 데이터베이스에 저장되어 있으며 필요하지 않으면 가져 가기를 원하지 않습니다. getter가 객체를 검색하면 누군가가 요청할 때까지 내부 객체가 null 일 수 있습니다. 그러면 getter를 처음 호출 할 때 객체를 가져올 수 있습니다.

몇 가지 다른 웹 서비스 호출에서 일부 데이터를로드하는 프로젝트에 기본 페이지 클래스가 있었지만 해당 웹 서비스 호출의 데이터가 항상 모든 하위 페이지에서 사용되는 것은 아닙니다. 웹 서비스는 모든 이점을 위해 "느린"에 대한 새로운 정의를 개척하므로 필요하지 않은 경우 웹 서비스 호출을 원하지 않습니다.

공용 필드에서 게터로 이동했으며 이제 게터가 캐시를 확인하고 웹 서비스가 없으면 캐시를 확인합니다. 작은 줄 바꿈으로 많은 웹 서비스 호출이 방지되었습니다.

따라서 getter는 각 하위 페이지에서 필요한 내용을 파악하지 않아도됩니다. 필요한 경우 getter를 호출하고 아직없는 경우이를 찾으러갑니다.

    protected YourType _yourName = null;
    public YourType YourName{
      get
      {
        if (_yourName == null)
        {
          _yourName = new YourType();
          return _yourName;
        }
      }
    }

지금까지 답변에서 놓친 한 가지 측면은 액세스 사양입니다.

• 회원의 경우 설정 및 가져 오기에 대한 하나의 액세스 사양 만 있습니다
• 세터와 게터의 경우 세밀하게 조정하고 별도로 정의 할 수 있습니다.

편집 : 나는이 질문을하는 프로그래밍을 배우는 많은 사람들이 있기 때문에이 질문에 대답했으며, 대부분의 답변은 매우 기술적으로 유능하지만 초보자라면 이해하기 쉽지 않습니다. 우리는 모두 초보자 였기 때문에 좀 더 친숙한 답변을 시도 할 것이라고 생각했습니다.

두 가지 주요한 것은 다형성과 검증입니다. 바보 같은 데이터 구조 일지라도.

이 간단한 클래스가 있다고 가정 해 봅시다.

public class Bottle {
  public int amountOfWaterMl;
  public int capacityMl;
}

액체의 양과 용량 (밀리리터)을 담는 매우 간단한 클래스입니다.

내가 할 때 어떻게됩니까?

Bottle bot = new Bottle();
bot.amountOfWaterMl = 1500;
bot.capacityMl = 1000;

글쎄, 당신은 그 일을 기대하지 않을 것입니다. 당신은 어떤 종류의 위생 검사를 원합니다. 그리고 더 이상 최대 용량을 지정하지 않으면 어떻게됩니까? 오, 문제가 있습니다.

그러나 또 다른 문제가 있습니다. 병이 단지 한 유형의 용기라면? 용량과 액체가 채워진 용기가 여러 개인 경우 어떻게해야합니까? 인터페이스를 만들 수 있다면 나머지 프로그램에서 해당 인터페이스를 받아 들일 수 있으며 병, jerrycans 및 모든 종류의 것들이 상호 교환 적으로 작동합니다. 더 나아지지 않을까요? 인터페이스는 메소드를 요구하기 때문에 이것도 좋습니다.

우리는 다음과 같은 결과를 얻었습니다.

public interface LiquidContainer {
  public int getAmountMl();
  public void setAmountMl(int amountMl);
  public int getCapacityMl();
}

큰! 이제 병을 다음과 같이 변경합니다.

public class Bottle extends LiquidContainer {
  private int capacityMl;
  private int amountFilledMl;

  public Bottle(int capacityMl, int amountFilledMl) {
    this.capacityMl = capacityMl;
    this.amountFilledMl = amountFilledMl;
    checkNotOverFlow();
  }

  public int getAmountMl() {
    return amountFilledMl;
  }

  public void setAmountMl(int amountMl) {
     this.amountFilled = amountMl;
     checkNotOverFlow();
  }
  public int getCapacityMl() {
    return capacityMl;
  }

  private void checkNotOverFlow() {
    if(amountOfWaterMl > capacityMl) {
      throw new BottleOverflowException();
    }
}

나는 BottleOverflowException의 정의를 독자에게 연습으로 남겨 둘 것이다.

이제 이것이 훨씬 더 강력하다는 것을 알 수 있습니다. 이제 Bottle 대신 LiquidContainer를 수락하면 코드에서 모든 유형의 컨테이너를 처리 할 수 ​​있습니다. 이 병이 이런 종류의 물건을 다루는 방법은 모두 다를 수 있습니다. 상태가 변경 될 때 디스크에 상태를 기록하는 병이나 SQL 데이터베이스 또는 GNU에 저장된 병이 다른 것을 알고있을 수 있습니다.

그리고이 모든 것들은 다양한 솜씨를 다루는 다른 방법을 가질 수 있습니다. 병은 방금 확인하고 넘치면 RuntimeException을 발생시킵니다. 그러나 그것은 잘못된 일일 수 있습니다. (오류 처리에 관한 유용한 토론이 있지만 여기서는 매우 간단하게 설명하고 있습니다. 의견을 가진 사람들은이 단순한 접근 방식의 결함을 지적 할 것입니다.;))

그리고 그렇습니다. 우리는 매우 간단한 아이디어에서 훨씬 더 나은 답변을 빨리 얻는 것처럼 보입니다.

병의 용량은 변경할 수 없습니다. 이제 돌로 설정되었습니다. 최종 선언하여 int 로이 작업을 수행 할 수 있습니다. 그러나 이것이 목록 인 경우 목록을 비우고 새 항목을 추가하는 등의 작업을 수행 할 수 있습니다. 내부를 만지는 것에 대한 액세스를 제한 할 수 없습니다.

모든 사람이 해결하지 않은 세 번째 사항도 있습니다. getter 및 setter는 메소드 호출을 사용합니다. 즉, 다른 곳에서는 일반적인 방법처럼 보입니다. DTO 및 물건에 대해 이상한 특정 구문을 사용하는 대신 모든 곳에서 동일한 내용을 갖습니다.

"속성"(C ++, Java)을 지원하지 않거나 필드를 속성 (C #)으로 변경할 때 클라이언트를 다시 컴파일해야하는 언어에서는 get / set 메소드를 사용하는 것이 더 쉽습니다. 예를 들어, setFoo 메소드에 유효성 검증 로직을 추가하면 클래스의 공용 인터페이스를 변경할 필요가 없습니다.

"실제"속성을 지원하는 언어 (Python, Ruby, 아마도 Smalltalk?)에서는 메소드를 가져 오거나 설정할 필요가 없습니다.

OO 디자인의 기본 원칙 중 하나 : 캡슐화!

그것은 많은 이점을 제공합니다. 그중 하나는 배후에서 게터 / 세터의 구현을 변경할 수 있지만 그 값을 가진 소비자는 데이터 유형이 동일하게 유지되는 한 계속 작동합니다.

다음과 같은 경우 getter 및 setter를 사용해야합니다.

• 개념적으로 속성이있는 것을 다루고 있지만
  • 언어에 속성 (또는 Tcl의 변수 추적과 같은 유사한 메커니즘)이 없거나
  • 귀하의 언어 속성 지원이이 사용 사례에 충분하지 않거나
  • 귀하의 언어 (또는 경우에 따라 프레임 워크)의 관용적 관습은이 사용 사례에 대해 게터 나 세터를 권장합니다.

따라서 이것은 일반적인 OO 질문은 거의 없습니다. 다른 언어 (및 다른 유스 케이스)에 대해 다른 답변을 가진 언어 별 질문입니다.

OO 이론의 관점에서, 게터와 세터는 쓸모가 없습니다. 클래스의 인터페이스는 상태가 아니라 클래스의 인터페이스입니다. (그렇지 않은 경우, 잘못된 클래스를 작성했습니다.) 매우 간단한 경우, 클래스가하는 일이 예를 들어 직사각형 좌표로 점을 나타내는 것입니다. * 속성은 인터페이스의 일부입니다. 게터와 세터는 단지 그것을 클라우드합니다. 그러나 매우 단순한 경우를 제외하고는 속성이나 게터 및 세터가 인터페이스의 일부가 아닙니다.

다른 방법으로 설명하자면 : 클래스의 소비자가 자신이 spam속성 을 가지고 있다는 것을 알지 못한다고 생각할 경우, 속성을 변경할 수있는 능력이 훨씬 적으므로, set_spam메소드 를 제공하는 것이 마지막으로해야 할 일입니다.

_{* 간단한 클래스라도 x와 y값을 설정하지 않아도 됩니다. 이것이 실제로 클래스 translate라면 rotate, 등의 메소드가 없어야 합니까? 귀하의 언어에 레코드 / 구조체 / 명명 된 튜플이 없기 때문에 클래스 일뿐이라면 이것은 실제로 OO의 문제가 아닙니다 ...}

그러나 아무도 일반 OO 디자인을하고 있지 않습니다. 그들은 특정 언어로 디자인과 구현을하고 있습니다. 그리고 일부 언어에서는 게터와 세터가 쓸모가 없습니다.

언어에 속성이없는 경우 개념적으로 속성이지만 실제로 계산 또는 검증되는 것을 나타내는 유일한 방법은 getter 및 setter를 사용하는 것입니다.

언어에 속성이 있더라도 언어가 불충분하거나 부적절 할 수 있습니다. 예를 들어, 동적 액세스가없는 언어에서 하위 클래스가 속성의 의미를 제어 할 수 있도록하려면 하위 클래스가 계산 된 속성을 속성으로 대체 할 수 없습니다.

"나중에 구현을 나중에 변경하려면 어떻게해야합니까?" 질문 (OP의 질문과 허용 된 답변 모두에서 다른 표현으로 여러 번 반복됩니다) : 실제로 순수한 구현 변경이고 속성으로 시작한 경우 인터페이스에 영향을 미치지 않고 속성으로 변경할 수 있습니다. 물론, 당신의 언어가 그것을 지원하지 않는 한. 따라서 이것은 다시 똑같은 경우입니다.

또한 사용중인 언어 (또는 프레임 워크)의 관용구를 따르는 것이 중요합니다. C #으로 멋진 루비 스타일 코드를 작성하면 경험이없는 C # 개발자가 코드를 읽는 데 어려움을 겪을 수 있습니다. 어떤 언어는 다른 언어보다 관습에 대해 더 강한 문화를 가지고 있습니다. 관용 게터가 어떻게 다른 스펙트럼 끝에있는 Java와 Python이 가장 강한 문화 중 하나를 갖는 것은 우연이 아닙니다.

인간 독자 이외에도 규칙을 따르고 그렇지 않으면 인생을 더 힘들게 만드는 라이브러리와 도구가 있습니다. Interface Builder 위젯을 ObjC 속성 이외의 것에 연결하거나 게터없이 특정 Java mocking 라이브러리를 사용하면 인생이 더 어려워집니다. 도구가 당신에게 중요하다면, 싸우지 마십시오.

객체 지향 디자인 관점에서 두 가지 대안 모두 클래스의 캡슐화를 약화시켜 코드 유지 관리에 손상을 줄 수 있습니다. 토론을 위해이 훌륭한 기사를 볼 수 있습니다 : http://typicalprogrammer.com/?p=23

Getter 및 Setter 메서드는 접근 자 메서드이므로 일반적으로 개인 클래스 멤버를 변경하기위한 공용 인터페이스입니다. getter 및 setter 메소드를 사용하여 특성을 정의하십시오. 클래스 내에서 메소드로 정의하더라도 getter 및 setter 메소드는 클래스 외부의 특성으로 액세스합니다. 클래스 외부의 속성은 클래스의 속성 이름과 다른 이름을 가질 수 있습니다.

getter 및 setter 메소드를 사용하면 몇 가지 장점이 있습니다. 예를 들어, 유사한 특성에 액세스 할 수있는 정교한 기능을 가진 멤버를 작성할 수 있습니다. 또한 읽기 전용 및 쓰기 전용 속성을 만들 수 있습니다.

getter 및 setter 메소드가 유용하지만 다른 문제 중에서도 특정 상황에서 코드 유지 보수를 더 어렵게 만들 수 있으므로 과도하게 사용하지 않도록주의해야합니다. 또한 공개 멤버와 같은 클래스 구현에 대한 액세스를 제공합니다. OOP 연습은 클래스 내의 속성에 직접 액세스하지 않도록합니다.

클래스를 작성할 때는 항상 가능한 많은 인스턴스 변수를 전용으로 설정하고 그에 따라 getter 및 setter 메소드를 추가하는 것이 좋습니다. 사용자가 클래스 내에서 특정 변수를 변경하지 못하게하려는 경우가 여러 번 있기 때문입니다. 예를 들어 특정 클래스에 대해 생성 된 인스턴스 수를 추적하는 전용 정적 메서드가있는 경우 사용자가 코드를 사용하여 해당 카운터를 수정하지 못하게합니다. 생성자 명령문 만 호출 될 때마다 해당 변수를 증가시켜야합니다. 이 경우 개인 인스턴스 변수를 작성하고 카운터 변수에 대해서만 getter 메소드를 허용 할 수 있습니다. 즉, 사용자는 getter 메소드를 사용해야 만 현재 값을 검색 할 수 있으며 새 값을 설정할 수 없습니다. 세터 방법을 사용합니다.

코드가 진화합니다 . 데이터 멤버 보호가 필요할private 때 유용 합니다 . 결국 모든 클래스는 내부적으로 조일 수없는 잘 정의 된 인터페이스 를 가진 일종의 "미니 프로그램"이어야합니다 .

즉, 소프트웨어 개발 은 첫 번째 시도에서 주철 조각상을 누르는 것처럼 클래스의 최종 버전을 설정하는 것이 아닙니다. 작업하는 동안 코드는 점토와 비슷합니다. 개발 함에 따라 발전하고 해결하려는 문제 영역에 대해 자세히 알아 봅니다. 개발 과정에서 클래스는 서로 (인식 할 계획 인 의존성), 서로 합치거나 분리되는 것보다 서로 상호 작용할 수 있습니다. 그래서 나는 토론이 종교적으로 글을 쓰고 싶지 않은 사람들에게 귀결된다고 생각합니다.

int getVar() const { return var ; }

그래서 당신은 :

doSomething( obj->getVar() ) ;

대신에

doSomething( obj->var ) ;

getVar()시각적으로 시끄러울 뿐만 아니라 gettingVar()실제보다 복잡한 프로세스라는 착각을줍니다 . 당신이 (클래스 라이터로서) 신성함을 고려하는 var방법은 패스 스루 세터가있는 경우 클래스 사용자에게 특히 혼란 스럽습니다. 그러면 당신이 주장하는 것을 "보호"하기 위해이 게이트를 세우는 것처럼 보입니다. (신성함 var) 그러나 당신 var의 보호 조차도 당신 set var이하고있는 일에 대해 엿보기조차하지 않고, 누군가 가 원하는 값으로 들어올 수있는 능력에 의해 가치가있는 것은 아닙니다 .

따라서 다음과 같이 프로그래밍합니다 ( "민첩한"형식 접근을 가정합니다. 즉, 정확히 어떤 폭포 스타일 인터페이스 세트를 계획 할 시간이나 경험이 없는지 정확히 알 수 없는 코드를 작성할 때 ) :

1) 데이터와 행동으로 기본 개체에 대한 모든 공개 멤버로 시작하십시오. 이것이 모든 C ++ "example"코드 struct에서 class어디에서나 대신 사용 하는 것을 알 수있는 이유입니다 .

2) 데이터 멤버에 대한 객체의 내부 동작이 충분히 복잡해지면 (예를 들어, 내부 std::list를 어떤 종류의 순서 로 유지하는 것을 좋아함 ) 액세서 유형 함수가 작성됩니다. 내가 직접 프로그래밍하고 있기 때문에 항상 멤버를 private즉시 설정하지는 않지만 클래스의 발전이 어딘가에서 멤버가 protected또는 로 "승격"됩니다 private.

3) 완전히 구체화하고 자신의 내부에 대한 엄격한 규칙 (즉이되는 클래스 들은 그들이 무엇을 정확히 알고, 당신이 "씨발"(전문 용어로하지 않습니다) 지정된되어 그 내부로) class지정, 개인 회원 기본, 일부 회원 만 선택할 수 있습니다 public.

이 접근 방식을 사용하면 클래스 진화의 초기 단계에서 많은 데이터 멤버가 마이그레이션되거나 이동하는 등 종교적인 게터 / 세터를 피할 수 있습니다.

속성 상속이 없기 때문에 접근자를 사용하는 것이 좋습니다. 다음 예를 참조하십시오.

public class TestPropertyOverride {
    public static class A {
        public int i = 0;

        public void add() {
            i++;
        }

        public int getI() {
            return i;
        }
    }

    public static class B extends A {
        public int i = 2;

        @Override
        public void add() {
            i = i + 2;
        }

        @Override
        public int getI() {
            return i;
        }
    }

    public static void main(String[] args) {
        A a = new B();
        System.out.println(a.i);
        a.add();
        System.out.println(a.i);
        System.out.println(a.getI());
    }
}

산출:

0
0
4

게터 와 세터 는 다음과 같은 객체 지향 프로그래밍의 두 가지 기본 측면을 구현하는 데 사용됩니다.

1. 추출
2. 캡슐화

Employee 클래스가 있다고 가정하십시오.

package com.highmark.productConfig.types;

public class Employee {

    private String firstName;
    private String middleName;
    private String lastName;

    public String getFirstName() {
      return firstName;
    }
    public void setFirstName(String firstName) {
       this.firstName = firstName;
    }
    public String getMiddleName() {
        return middleName;
    }
    public void setMiddleName(String middleName) {
         this.middleName = middleName;
    }
    public String getLastName() {
        return lastName;
    }
    public void setLastName(String lastName) {
        this.lastName = lastName;
    }

    public String getFullName(){
        return this.getFirstName() + this.getMiddleName() +  this.getLastName();
    }
 }

여기서 전체 이름의 구현 세부 사항은 사용자에게 숨겨져 있으며 공용 속성과 달리 사용자가 직접 액세스 할 수 없습니다.

속성을 지원하는 언어에서 다른 용도로는 setter와 getter가 조작이 중요하지 않다는 것을 암시 할 수 있습니다. 일반적으로 속성에서 계산 비용이 많이 드는 작업은 피하려고합니다.

getter / setter의 상대적으로 현대적인 이점 중 하나는 태그가있는 (색인이있는) 코드 편집기에서 코드를 쉽게 찾을 수 있다는 것입니다. 예를 들어 누가 멤버를 설정하는지 보려면 세터의 통화 계층을 열 수 있습니다.

반면, 멤버가 공개 인 경우 도구를 사용하면 멤버에 대한 읽기 / 쓰기 액세스를 필터링 할 수 없습니다. 따라서 회원의 모든 용도를 망쳐 놓아야합니다.

객체 지향 언어에서 메소드와 액세스 수정자는 해당 객체에 대한 인터페이스를 선언합니다. 생성자와 액세서 및 뮤 테이터 메소드 사이에서 개발자가 오브젝트의 내부 상태에 대한 액세스를 제어 할 수 있습니다. 변수가 단순히 public으로 선언되면 해당 액세스를 조절할 방법이 없습니다. 그리고 setter를 사용할 때 필요한 입력으로 사용자를 제한 할 수 있습니다. 해당 변수에 대한 피드가 올바른 채널을 통해 전달되고 해당 채널이 Google에 의해 사전 정의되어 있음을 의미합니다. 따라서 세터를 사용하는 것이 더 안전합니다.

또한 이것은 수업을 "미래에 대비"하기위한 것입니다. 특히, 필드에서 속성으로 변경하는 것은 ABI 중단이므로 나중에 "필드 설정 / 받기"보다 더 많은 논리가 필요하다고 결정하면 ABI를 중단해야합니다. 그렇지 않으면 이미 클래스에 대해 컴파일되었습니다.

@getter 및 @setter : 주석 아이디어를 던지고 싶습니다. @getter를 사용하면 obj = class.field는 할 수 있지만 class.field = obj는 할 수 없습니다. @setter를 사용하면 그 반대도 마찬가지입니다. @getter와 @setter를 사용하면 둘 다 할 수 있어야합니다. 이렇게하면 런타임에 사소한 메서드를 호출하지 않아 캡슐화가 유지되고 시간이 줄어 듭니다.