세터 인수 수정 - 해킹입니까?

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

  •  10-07-2019
  •  | 
  •  

문제

세터 인수를 수정하는 것이 정상입니까? 우리가 setstring 방법을 가지고 있다고 상상해 봅시다. 그리고 우리는 정말로 트리밍 된 형태의 문자열을 유지하고 싶습니다. 따라서 후행 공간이있는 끈은 유효하지만 예외를 던지고 싶지는 않습니다.

최상의 솔루션은 무엇입니까? 세터의 값을 다듬려면 예를 들어

public void setString(String string) {
    this.string = string.trim();
}

또는 발신자 (두 번 이상)에서 다듬습니다.

object.setString(string.trim());

아니면 다른 것이 있습니까?

도움이 되었습니까?

해결책

예. 결국, 세터는 이런 종류의 것들을 위해 설계되었습니다! 필드에 쓰여진 값을 제어하고 소독하기 위해;)

다른 팁

완전히. 예는 다음과 같습니다. 다른 유형의 측정 단위가있는 엔지니어링 프로그램이 있다고 가정 해 봅시다. 내부 값을 하나의 측정 시스템에 보관하지만 세터의 다른 모든 것에서 변환하고 getter로 다시 변환합니다 (예 :).

public double UserTemperature
{
  get
  {
    return Units.Instance.ConvertFromSystem(UnitType.Temperature, temperature);
  }
  set  
  {
    double v = Units.Instance.ConvertToSystem(UnitType.Temperature, value);
    if (temperature != v)
    {
      temperature = v;
      Changed("SystemTemperature");
      Changed("UserTemperature");
    }
  }
}

물론이지. 메소드 (예 : Trim ())을 적용하기 전에 NULL을 확인하는 데주의하십시오.

두 개의 학교가 있습니다. 하나는 Param in Setter (학교 스타일)를 확인해도 괜찮다고 말하고 두 번째는 Bean에는 논리와 데이터 스타일 만 포함되어서는 안된다고 말합니다.

나는 두 번째를 더 믿습니다. 콩 구현을 얼마나 자주 보십니까? GetUser는 예외를 던지거나 Null을 반환해야합니까?

세터와 getter에 논리를 넣을 때 많은 사람들이 구현을 보지 않기 때문에 무슨 일이 일어나고 있는지 이해하기가 더 어려워집니다. 당신이 동의하지 않는다면 나는 당신이 그것을 사용하기 전에 콩이 아닌지 확인하기 전에 모든 세터를 살펴보고 getter 구현을 촉구합니다.

언뜻보기에는 그것이 위반되는 것처럼 보입니다 최소한의 원칙. 내가 당신의 수업의 사용자라면, 나는 세터가 내가 말하는 것을 정확하게 수행 할 것을 기대합니다. Setter에서 예외를 던지기 위해 사용자가 입력을 다듬도록 강요했습니다.

다른 하나 (더 나은?) 대안은 메소드의 이름을 TrimandSetString으로 변경하는 것입니다. 그렇게하면 입력을 다듬는 것이 놀라운 동작이 아닙니다.

내가 틀렸다면 나를 바로 잡으십시오. 그러나 세터가 이런 종류의 논리를 고정해야한다는 것은 논리적으로 보입니다. 세터가 확인하지 않고 내부 VAR에 값을 할당하는 경우 VAR 자체를 노출하지 않겠습니까?

이것이 바로 객체 필드를 전체 세계에 노출시키지 않고 세터를 사용하는 이유입니다.

0에서 359 사이에있는 정수 각도를 보유한 클래스를 고려하십시오.

필드에 노출되면 호출 기능이 원하는대로 설정할 수 있으며 이는 API가 지정한 계약을 중단합니다. 또한 코드가 해당 변수의 특정 범위를 가정하도록 작성 되었기 때문에 트랙 어딘가에 기능을 중단 할 수 있습니다.

세터를 사용하면 할 수있는 일이 많이 있습니다. 하나는 유효하지 않은 값이 통과되었음을 나타내는 예외를 제기하는 것입니다. 그러나 내 견해에서는 잘못 될 것입니다 (이 경우). 입력 값을 다음과 같이 0에서 359 사이의 것으로 수정하면 더 유용 할 수 있습니다.

actualVal = passedValue % 360;

이것이 인터페이스 (API)에 지정되는 한 완벽하게 유효합니다. 실제로, 당신이 그것을 지정하지 않더라도, 발신자가 계약을 위반했기 때문에 (범위 이외의 값을 통과함으로써) 원하는대로 자유롭게 할 수 있습니다. 나는 "가능한 한 빨리 입력을 소독한다"라는 규칙을 따르는 경향이 있습니다.

특정 경우, 문자열이 트림 형식으로 저장되어 있음을 지정하는 한 발신자가 불만을 제기 할 이유가 없습니다 (이미 그러한 문자열이 유효하지 않다고 언급했습니다). 세터를 호출하는 모든 코드가 아닌 세터에서 코드 크기 (속도가 아님) 측면에서 더 좋습니다. 또한 문자열이 예상대로 저장되어 있음을 보장합니다. 발신자가 우연히 (또는 의도적으로) 비 트림 문자열을 저장하지 않을 것이라는 보장은 없습니다.

예. 객체 지향 디자인의 특징은 발신자가 클래스를 블랙 박스로 취급 할 수 있다는 것입니다. 인터페이스의 동작이 문서화되고 논리적 인 한 자신의 사업입니다.

다른 사람들이 다른 철학을 가지고 있지만, 나는 지시 된 값과 일치하도록 대상 상태의 측면을 설정하고 변화에 관심이있는 사람에게 알리지 만 달리 영향을 미치지 않을 수도있는 경우에만 속성 세터가 적절하다고 제안합니다. Object의 상태 (속성 세터가 값을 변경하는 것이 전적으로 적절합니다. 읽기 전용 속성 해당 속성이 속성 세터와 관련된 상태로 정의 된 경우; 예를 들어, 컨트롤의 읽기 전용 Right 속성은 그것의 관점에서 정의 될 수 있습니다 Bounds). 지시 된 작업을 수행 할 수없는 경우 속성 세터는 예외를 던져야합니다.

클라이언트가 위의 설명을 충족시키지 않은 방식으로 객체의 상태를 수정하기를 원한다면, 속성이 아닌 메소드를 사용해야합니다. 한 번 전화하면 Foo.SetAngle(500) 메소드가 각도를 설정하는 데 표시된 매개 변수를 사용할 것으로 합리적으로 예상됩니다. Angle 속성은 설정된 것과 동일한 형태로 각도를 반환하지 않을 수 있습니다 (예 : 140이 반환 될 수 있음). 반면에 Angle 읽기 쓰기 속성입니다. 500의 값을 작성하는 것은 금지되거나 다른 값이 500을 읽게 될 것으로 예상됩니다. 객체 저장을 0에서 359 범위의 각도를 유지하려면 물체입니다. 또한 읽기 전용 속성을 호출 할 수도 있습니다 BaseAngle 항상 그 형태의 각도를 반환합니다.

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