게터와 세터 스타일

StackOverflow https://stackoverflow.com/questions/1610029

  •  05-07-2019
  •  | 
  •  

문제

(당신이 그것을 가지고 있어야하는지에 대한 질문은 제쳐두고.)

나는 항상 getter와 setter 모두에 동일한 이름을 제공하기 위해 함수 오버로딩을 사용하는 것을 선호했습니다.

int rate() { return _rate; }      
void rate(int value) { _rate = value; }

// instead of     
int getRate() { return _rate; }      
void setRate(int value) { _rate = value; }

// mainly because it allows me to write the much cleaner     
total( period() * rate() );    
// instead of      
setTotal( getPeriod() * getRate() );

당연히 내 말이 맞지만, 도서관 작가들이 타당한 이유가 있는지 궁금합니다.

도움이 되었습니까?

해결책

무슨 일이 일어나고 있는지 더 명확하기 때문에 Get/Set 버전을 선호합니다. 속도 () 및 rate (10)를 보았을 때, 비율 (10)이 계산에서 10을 사용하여 속도를 반환하는 것이 아니라는 것을 어떻게 알 수 있습니까? 나는 그렇지 않기 때문에 이제 무슨 일이 일어나고 있는지 알아 내기 위해 검색을 시작해야합니다. 단일 함수 이름은 두 가지 반대되는 일이 아니라 한 가지를 수행해야합니다.

또한 다른 사람들이 지적했듯이 일부는 'get'을 생략하고 '세트'를 떠나는 것을 선호합니다.

int Rate( );
void SetRate( int value );

그 컨벤션도 분명합니다. 나는 그것을 읽는 데 아무런 문제가 없습니다.

다른 팁

나는 항상 당신과 마찬가지로 내 getters의 'get'을 생략하는 것을 선호했습니다. rate() 대신에 getRate(). 하지만 세터에 대한 과부하는 나에게 아주 좋은 생각처럼 보이지 않습니다. rate 물체가 돌연변이되고 있음을 전달하지 않습니다. 고려하다:

total(period() * rate()); // awesome, very clear

rate(20); // Looks like it computes a rate, using '20'...but for what?  And why ignore the return value?

어때 int rate(); 그리고 void setRate(int value);? 이것은 같은 이름의 두 가지 기능이 다른 일을하는 것에 대한 미덕을 가지고 있으며 여전히 허용합니다. period() * rate().

몇 년 전, 나는 완전히 동의했을 것입니다. 더 최근에는 의심의 여지가 시작되기 시작했습니다. 왜냐하면 그것은 게터 나 세터의 주소를 모호하게 만들기 때문입니다. tr1 :: bind와 같은 도구를 사용하면 정말 성가시다.

예를 들어:

struct A
{
   void Foo(int);
   int Foo()const;
};

std::vector<A> v = ....;
std::vector<int> foos;
// Extract Foo
std::transform(
   v.begin(), v.end(), 
   std::back_inserter(foos), 
   //Ambiguous
   // std::tr1::bind(&A::Foo)
   //must write this instead. Yuck!
   std::tr1::bind(static_cast<int(Foo::*)()>(&A::Foo));
);

당신이 그들을 가지고 있어야한다는 질문을 제외하고 ;-)

계속해서 커뮤니티 위키 질문이 될 것입니다.

C ++를 배우기 시작했을 때 스타일 가이드를 찾았고 Google은 몇 가지 점에 좋았습니다.

  • 대문자의 방법 (단지 더 예쁘다).
  • getters and lowecase (rate).
  • 세터는 명시 적으로 및 소문자 (setRate).

간결한 것은 중요하지만 불완전하거나 오도하는 비용은 중요하지 않습니다. 이런 이유로 getFoo () 및 setFoo () to foo () 및 foo (int foo)를 선호합니다.

"얻기"및 "설정"에는 몇 가지 레벨이 있습니다.

  • "빠른"작업을 위해 Get and Set을 사용합니다.
  • 실행하는 데 시간이 더 오래 걸리면,이 이름은 결과를 검색하기 위해 일부 작업을 수행해야한다는 것을 암시하기 때문에 종종 석회질이됩니다.
  • 더 긴 작업의 경우로드/저장, 쿼리/스토어, 읽기/쓰기, 검색/찾기 등과 같은 접두사로 시작됩니다.

따라서 Get/Set은 유용한 의미로 기인하고 더 크고 일관된 이름 지정 전략의 일부가 될 수 있습니다.

Ed의 의견은 사실이지만 Setter/Getter antipattern보다 실제 속성을 선호합니다. 도메인 그래프의 메소드의 1/3이 Eclipse에 의해 생성 된 더미 메소드 인 경우, 뭔가 잘못되었습니다.

그러나 일등석 속성이 없으면 안티 패턴이 가장 의미가 있다고 생각합니다.

또한 코드 완료를 더 쉽게 만듭니다.

obj.set (control shift space) 세터 용
obj.get (control shift space) getters를 위해

개인적으로, 나는 쌍으로 발견되는 getters와 setters는 "시각적"언어와 그 "속성"에서 이루어진 코드 냄새라고 생각합니다. "좋은"클래스에서 데이터 구성원은 쓰기 또는 읽기 만하지만 읽기/쓰기는 아닙니다.

나는 게터와 세터의 가장 일반적인 원인이 객체 모델을 충분히 깊이 들지 않는다고 생각합니다. 당신의 예에서, 왜 총계가 기간과 요율을 통과합니까? 그들은 반원이 아닌가? 따라서 기간과 요율 만 설정해야하며 총만을 얻어야합니다.

예외가있을 수 있지만 수업을보고 "getx/setx, gety/sety 등"을 찾는 것을 싫어합니다. 수업을 어떻게 사용하는지에 대한 생각이 충분하지 않은 것 같습니다. 오히려 저자는 수업을 데이터에 쉽게 얻을 수있게하여 클래스 사용 방법을 고려하지 않아도됩니다.

당연히 나는 맞습니다.

아무도 언급하지 않은 또 다른 문제는 함수 오버로드의 경우입니다.다음의 (인위적이고 불완전한) 예를 들어보세요:

class Employee {
    virtual int salary() { return salary_; }
    virtual void salary(int newSalary) { salary_ = newSalary; }
};

class Contractor : public Employee {
    virtual void salary(int newSalary) {
        validateSalaryCap(newSalary);
        Employee::salary(newSalary);
    }
    using Employee::salary; // Most developers will forget this
};

그것 없이는 using 조항, 사용자 Contractor 과부하로 인해 급여를 조회할 수 없습니다.최근에 추가했어요 -Woverloaded-virtual 내가 작업하고 있는 프로젝트의 경고 세트에 보니, 이게 여기저기서 나타났습니다.

나는 방법이 항상 동사 여야하고 클래스는 항상 명사 여야하는 규칙을 시행합니다 (명백한 이유로 기능을 제외하고). 이 경우 Get/Set 접두사를 일관성을 위해 사용해야합니다. 즉, 나는 또한 Ed Swangren과 전적으로 동의합니다. 이것은 그 접두사를 사용하지 않는 것으로 나에게 합산합니다.

Get and Set 라벨을 피하는 것을 선호합니다. 컴파일러가 이러한 간단한 속성의 대부분에 대해 컴파일러가 작업 할 필요가 없습니다.

문제가있을 수 있습니다.

class Stuff {
  void widget( int something ); // 'special' setter
  const Widget& widget( int somethingelse ) const; // getter
}
Stuff a; 
a.widget(1); // compiler won't know which widget you mean, not enough info

당신의 getter가 간단하다면 rate(), 당신의 컴파일러는 당신의 다른 사람의 재정의라고 불평합니다. rate 상징, 당신이 당신의 필드에 좋은 의미있는 이름을 주었다면. 이 경우 회원 이름과 같은 어리석은 일을해야합니다. _rate 또는 다른 유사한 접근법. 나는 개인적으로 그 밑줄을보고/입력하는 것을 싫어하므로 getRate() 접근하다.

이것은 분명히 주관적이며 이것은 단지 내 개인적인 취향입니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top