간단한 Getter / Setter 설명

간단한 Getter / Setter 설명

---

게터와 세터에 대해 어떤 규칙을 사용합니까? 이것은 예를 들어 꽤 오랫동안 궁금해 한 것입니다.

/**
 * (1a) what do you put here?
 * @param salary (1b) what do you put here?
 */
public void setSalary(float salary);

/*
 * (2a) what do you put here?
 * @return (2b)
 */
public float getSalary();

나는 항상 1a / b와 2a / b에 대해 정확히 똑같은 것을 쓰고 있다는 것을 알게됩니다 .1a) 직원의 급여를 설정하고 1b) 직원의 급여를 설정하십시오. 너무 중복되는 것 같습니다. 이제 좀 더 복잡한 것을 볼 수 있습니다. (a) 부분에서 더 많이 쓰면 문맥을 알 수 있지만 대부분의 게터 / 세터에게는 문구가 거의 동일합니다.

단순한 게터 / 세터가 (a) 부분 또는 (b) 부분 만 채우면 괜찮습니다.

어떻게 생각해?

---

나는 보통 setter의 param 부분과 getters의 @return 부분을 채 웁니다.

/**
 * 
 * @param salary salary to set (in cents)
 */
public void setSalary(float salary);

/**
 * @return current salary (in cents, may be imaginary for weird employees)
 */
public float getSalary();

그렇게하면 javadoc 검사 도구 (예 : Eclipse 경고)가 깨끗하게 나오고 중복이 없습니다.

---

절대로 무의미합니다. 이러한 쓰레기가 코드를 어지럽히 지 않으면 더 좋습니다.

/**
 * Sets the foo.
 * 
 * @param foo the foo to set
 */
public void setFoo(float foo);

필요한 경우 매우 유용합니다.

/**
 * Foo is the adjustment factor used in the Bar-calculation. It has a default
 * value depending on the Baz type, but can be adjusted on a per-case base.
 * 
 * @param foo must be greater than 0 and not greater than MAX_FOO.
 */
public void setFoo(float foo);

특히 속성이 실제로 무엇을 의미하는지에 대한 설명은 도메인 모델에서 중요 할 수 있습니다. 투자 은행가, 생화학 자 또는 양자 물리학 자만이 이해하는 이름이 모호한 속성으로 가득 찬 콩을 볼 때마다 setGobbledygook () 메소드가 "gobbledygook을 설정"한다고 설명합니다.

---

내가 도울 수 있다면 일반적으로 아무것도 아닙니다. 게터와 세터는 설명이 필요합니다.

나는 대답이 아닌 것처럼 들리지만 설명이 필요한 것들에 의견을 내기 위해 시간을 사용하려고합니다.

---

게터와 세터가 일종의 부작용이 있거나 초기화 외부에서 어떤 종류의 전제 조건이 필요한 경우에만 주석을 달기에 걱정할 것입니다 (예 : 데이터 구조에서 항목을 제거하거나 필요한 것을 설정하기 위해 얻는 것) x와 y를 먼저 배치하십시오). 그렇지 않으면 여기에 주석이 중복됩니다.

편집 : 또한 getter / setter에 많은 부작용이있는 경우 getter / setter를 다른 메소드 이름 (예 : 스택에 대해 밀어 넣기 및 팝)으로 변경하십시오. 아래의 의견]

---

주석이 JavaDocs (브라우저에서)로 표시 될 때 사람들이 무엇을보고 싶어하는지 스스로에게 물어보십시오. 많은 사람들은 문서가 분명하기 때문에 문서가 필요하지 않다고 말합니다. 필드가 개인용 인 경우에는 유지되지 않습니다 (개인용 필드에 대해 JavaDocs를 명시 적으로 설정하지 않은 경우).

In your case:

public void setSalary(float s)
public float getSalary()

It's not clear what salary is expressed in. It is cents, dollars, pounds, RMB?

When documenting setters/getters, I like to separate the what from the encoding. Example:

/**
 * Returns the height.
 * @return height in meters
 */
public double getHeight()

The first line says it returns the height. The return parameter documents that height is in meters.

---

Why don't they just include a reference tag to let you comment the field value and the reference from getters and setters.

/**
* The adjustment factor for the bar calculation.
* @HasGetter
* @HasSetter
*/
private String foo;

public String getFoo() {
  return foo;
}

public void setFoo() {
  this foo = foo;
}

So that the documentation applies to the getter and setter as well as the field (if private javadocs is turned on that is).

---

This kind of boilerplate can be avoided by using Project Lombok. Just document the field variable, even if it's private, and let Lombok annotations generate properly documented getters and setters.

For me, this benefit alone is worth the costs.

---

I'm really disappointed about the answers basically saying comprehensive documenting is a waste of time. How are clients of your API supposed to know that a method called setX is a standard JavaBean property setter unless you say so clearly in the documentation?

Without documentation, a caller would have no idea whatsoever if the method had any side effects, other than by crossing their fingers about the apparent convention being followed.

I'm sure I'm not the only one here to have had the misfortune to find out the hard way that a method called setX does a whole lot more than just set a property.

---

If there isn't special operation in getter/setter I usually write :

With Javadoc (with private option):

/** Set {@see #salary}. @param {@link #salary}. */
public void setSalary(float salary);

and/or

/** 
 * Get {@see #salary}.
 * @return {@link #salary}.
 */
public float salary();

With Doxygen (with private extract option):

/** @param[in] #salary. */
public void setSalary(float salary);

/** @return #salary. */
public float salary();

---

Commenting accessors, especially if they don't do any operations anywhere, is unnecessary and a waste of fingertips.

If someone reading your code can't understand that person.getFirstName() returns the first name of a person, you should try everything in your powers to get him fired. If it does some database magic, throws a few dice, calls the Secretary of First Names to get the first name, It's safe to assume it's a non-trivial operation, and document it well.

If, on the other hand, your person.getFirstName() doesn't return a person's first name... well, let's not go there, shall we?

---

Don't put anything if the field name is suficiently descriptive of the contents.

Generally, let the code be self standing, and avoid commenting if at all possible. This may require refactoring.

EDIT: The above refers to getters and setters only. I believe anything non trivial should be properly javadoc'ed.

---

it is ok to fill in the (b) part, especially if you put a comment at the field declaration indicating what the field is all about.

---

If the javadoc does not add anything, I delete the javadoc and use the auto-generated comments.

---

I always fill in both. The additional time spent typing is negligible, and more information is better than less, in general.

---

If it is a getter/setter, it should be documented.

I digress here, but if it can be made a property, perhaps that is better for simpler coding of the users of the class. I digress further but as for all the comments that have "java" anywhere in them, who said it was java? (the tags, but the question could apply anywhere really)

참고URL : https://stackoverflow.com/questions/1028967/simple-getter-setter-comments