당신이 파일을 업데이트 있어 코드 또는 데이터 베이스. 내가 잘못?
클래스가 일반적으로 공용 getters/setters를 사용하는 개인 멤버를 포함하고있는 이유 중 하나는 데이터를 확인할 수 있기 때문입니다.
1에서 100 사이의 숫자를 사용할 수 있다면 분명히 그 코드의 유효성을 검사하고 코드에 의해 잡히는 예외를 던질 수 있습니다. 그 이유는 간단합니다. 설정자에서하지 않으면 설정을 할 때마다 1에서 100까지의 제한이 있으므로 코드가 중복되거나 잊어 버리면 무효 상태가됩니다.
성능에 관해서는, 나는 여기 누스와 함께 해요 :
"우리는 작은 효율성에 대해 잊지한다, 시간의 약 97 %가 말 :. 조기 최적화는 모든 악의 뿌리입니다"
유효성 검사는 유효성 검사 방법에서 getter 또는 setter와 별도로 캡처해야합니다. 여러 구성 요소에서 유효성 검사를 다시 사용해야하는 경우이를 사용할 수 있습니다.
setter가 호출되면 이러한 유효성 검사 서비스를 사용하여 개체에 입력 된 내용을 삭제해야합니다. 그렇게하면 객체에 저장된 모든 정보가 항상 유효하다는 것을 알 수 있습니다.
개체 정보가 이미 유효하다고 신뢰할 수 있으므로 게터에 대한 유효성 검사가 필요하지 않습니다.
데이터베이스를 업데이트 할 때까지 유효성 검사를 저장하지 마십시오! 이 빠르면이 실패하는 것이 좋습니다.
가장 유지하기 쉬운 코드를 사용한다는 관점에서 볼 때 속성 작성자는 최대한 많은 유효성 검사를 수행해야한다고 생각합니다. 이렇게하면 유효하지 않은 데이터를 캐싱하거나 다룰 수 없습니다.
결국이 속성이 의미하는 바입니다. 당신은 모두가 같은 속성의 무리 ...
public string Name
{
get
{
return _name;
}
set
{
_name = value;
}
}
인 경우 ... 그들은뿐만 아니라 상황에 따라 다르다 필드
수 있습니다.
일반적으로 코드가 빨리 실패해야합니다. 코드의 여러 지점에서 값을 설정할 수 있고 값을 검색 한 후에 만 유효성을 검사하면 버그가 업데이트를 수행하는 코드에있는 것으로 보입니다. setter가 입력을 확인하면 잘못된 값을 설정하려고하는 코드를 알 수 있습니다.
에릭 에반스 (Eric Evans)가 Domain Driven Design을 확인하고 싶을 수도 있습니다.DDD는 이러한 개념을 가지고 있습니다.
... 명시 적 술어와 유사한 VALUE 특수 목적을위한 OBJECTS. A SPECIFICATION은 이 개체가 수행하는지 또는 어떤 조건을 만족하지 않는지를 결정하는 술어입니다.
나는 빨리 실패하는 것이 한 가지이며, 다른 하나는 유효성 검사를 위해 논리를 유지하는 것입니다. 도메인은 논리를 유지할 수있는 적절한 장소이며, 여러분의 도메인 객체에 대한 명세 객체 또는 유효성 검사 메소드가 좋은 장소라고 생각합니다.
IDataErrorInfo을 구현하고 오류 및이 [columnName] 속성에 내 유효성 검사 로직을 넣는 것을 좋아합니다. 그런 식으로 프로그래밍 방식으로 오류가 있는지 여부를 확인하려면 코드에서 해당 속성을 테스트하거나 Web Forms, Windows Forms 또는 WPF의 데이터 바인딩에 유효성 검사를 전달할 수 있습니다.
WPF의 "ValidatesOnDataError"바인딩 속성을 사용하면 특히 편리합니다.
@Terrapin 재 :
당신이 가지고있는 모든 경우 [간단한 공공 세트/수] 속성의 무리 ... 그들이 뿐만 아니라 수 있습니다 필드
속성이 분야에 대한 다른 이점. 그것들은 더 명백한 계약이고 직렬화되어 나중에 디버깅 될 수 있습니다. 상속을 통한 확장을위한 좋은 장소입니다. clunkier 문법은 실수로 복잡합니다. 예를 들어 .net 3.5가이를 극복합니다.
공용 필드에서 시작하여 나중에 필요에 따라 속성으로 변환하는 것이 일반적입니다. 이것은 수업을 사용하는 사람과 계약을 맺지 않으므로 속성으로 시작하는 것이 가장 좋습니다.
나는 내 개체가 무효 상태가되도록하지 않으므로 세터는 상태를 변경하는 모든 방법뿐만 아니라 유효성 검사도 수행하게 될 것입니다. 이렇게하면, 내가 다루고있는 객체가 유효하지 않다는 것을 걱정할 필요가 없습니다. 메서드를 유효성 검사의 경계로 유지하면 유효성 검사 프레임 워크와 IsValid() 메서드 호출이 모든 곳에서 뿌리 내릴 염려가 없습니다.
자세히 설명해 주시겠습니까? 예를 들어 <5 && > 0을 별도의 검증 방법으로 확인 하시겠습니까? 그러면 게터와 세터는 정확히 어떤 일을하고 있습니까? –