getter에서 표현식을 사용하는 경우

공개 속성을 사용하는 것이 맞습니까? 아니면 개인 필드 _count을 사용해야합니까? 주제에 대한 정보를 읽었지만 답변을 찾을 수 없습니다.getter에서 표현식을 사용하는 경우

public int Count 
{ 
    get 
    { 
     if (this._feeds.IsValueCreated) 
     { 
      return this._feeds.Value.Count; 
     } 
     else 
     { 
      return this._dbConnection.Table<T>().Count(); 
     } 
    } 
} 

public FeedRepository(SQLiteConnection dbConnection) 
{ 
    this._dbConnection = dbConnection; 
    this._feeds = new Lazy<IList<T>>(() => _dbConnection.Table<T>().ToList()); 
}

출처

2014-02-20 J.Marciniak

당신이하고 싶은 것과 왜 이것을 묻고있는 이유에 대해 설명해주십시오. 기본적인 대답은 _ "맞습니까?"_는 "작동합니까?"라고 묻는 것으로 얻을 수 있습니다. _, 다른 것에 대해 우려한다면, 그렇게 설명하십시오. – CodeCaster

왜 잘못되었을 수 있습니까? –

저장소 패턴을 구현하는 데 걱정이 있습니까? * Count * getter에 대해 묻는 경우, 그렇다고해서, 개인 필드를 구현할 필요가 없습니다. –

게터/세터 메소드는 속성에 대한 캡슐화을 제공하는 -의 구현을 "에서는"사용자에게 무관 - 결과는 내부 수집에 위임하거나 DB는 '아무튼에서 쿼리 여부를 문제 없습니다.

즉, 예, 게이터 내부에 if 문을 사용하는 것이 완벽합니다.

출처

2014-02-20 11:10:49 James

스마트 UI 패턴을 사용하는 경우 논리가 getter 및 setter 내에 존재하는 데 문제가 없습니다. 언젠가 우리의 응용 프로그램은이 옵션을 사용하기 쉽고 매력적으로 만들 정도로 작습니다.

역으로도 마찬가지입니다. 문제가 복잡해지면 도메인을 다시 생각하고 어떻게 상호 작용하는지 다시 생각해야합니다. getter와 setter에 if 문과 기타 비즈니스 논리를 추가하면 도메인의 기술적 부채가 증가한다고 주장 할 수 있습니다.

읽을 수있는 흥미로운 토론

는 프로그래머에서 찾을 수 있습니다 : what should be allow inside getters and setters

희망이 도움이됩니다.

ps. smart-ui는 또한 도메인의 범위에 따라 반 패턴으로 간주 될 수 있습니다.

출처

2014-02-20 11:11:01

이 Code Review에 테두리,하지만 난 당신이 묻고 싶은 질문을하고 답변을 위해 노력할 것은 :

내 저장소 패턴 읽기 전용 Count 속성이 있습니다. 저장소를 사용하여 데이터를로드 한 경우 Count 속성은로드 된 레코드 수를 반환해야합니다. 그렇지 않으면 기본 테이블의 모든 레코드 중 Count을 반환해야합니다.

게터에 사용 된 코드가이를 "너무 많이"라고 생각합니까?

대답은 다음과 같습니다. getter는 사용자가 기대하는 것과 정확히 일치합니다. 두 가지 시나리오가 있으므로 if이 필요합니다. 어쩌면 주위에서 작업 할 수 있지만 코드를 더 깨끗하게 만들지는 못합니다.

출처

2014-02-20 11:14:51 CodeCaster

getter에서 표현식을 사용하는 경우

답변

관련 문제