코드 줄의 관점에서 'Get'크기에 대한 지침이나 일반적인 합의가 있습니까? 여기에 30 줄의 코드로 쉽게 성장한 멤버에게 Get 메서드가 있습니다. 나는 이것을 어떤 방법으로 끌어 내야하는지 확신 할 수 없다. 그런 다음 GetMyString과 같은 식으로 값을 지정하고 다른 멤버에게 값을 할당하고 어쨌든 생성자에서 값을 호출합니다.Get 메서드의 크기
이 작업을 수행 할 가치가 있습니까?
너무 주관적입니까?
dcastro의 대답은 잘하지만, 일부 확장 사용할 수 있습니다
을 반환 오래 걸리지하지 않습니다; 저것을 정량화합시다. 속성은 필드를 가져 오는 데 걸리는 시간보다 10 배 이상 오래 걸리지 않아야합니다.
사람들은 느리고 첫 번째 규칙에 해당하므로 일반적으로하지만,이에 두 번째 측면이있다 : 실패해야 희귀하거나 불가능할 수 있습니다. 프로퍼티 게터는 예외를 던져서는 안됩니다.
이 없습니다. 속성 getter는 속성을 한 번 계산하고 나중에 캐시하기 때문에 부작용이 있지만 관찰 할만한 부작용이 아닙니다.
속성을 관찰 할 수있는 부작용이 발생하는 것은 철학적으로 나빠질뿐만 아니라 디버깅 경험을 엉망으로 만들 수도 있습니다. 디버거에서 기본적으로 객체를 볼 때 디버거는 해당 속성 게터를 자동으로 호출하고 결과를 표시합니다. 그렇게하면 느리게 디버깅 속도가 느려집니다. 그렇게하면 디버깅 환경이 실패 메시지로 가득 차게됩니다. 그렇게하면 부작용이 생기면 프로그램을 디버깅하여 프로그램 작동 방식이 바뀌므로 버그를 찾기가 어려울 수 있습니다. 물론 자동 속성 평가를 해제 할 수 있지만, 우선 좋은 속성을 디자인하는 것이 좋습니다.
Eric에서 chiming 해줘서 고마워! 나는 양을 정하는 데 큰 팬이 아닙니다. 나는 "일반 데이터 액세스보다 훨씬 오래 걸리지 않아야한다"는 것이 좋은 처방이라고 생각합니다. 얼마나 오랜 시간이 걸릴지 실제로 측정 할 사람이 아닌 것 같습니다. 그 밖의 모든 것에 관해서 - 스포트! +1 – dcastro
@dcastro : 물론, 그건 어렵고 빠르지 만 규칙이 너무 느릴 때를 어떻게 알 수 있는지에 대한 일반적인 지침입니다. 다시 말해, 내부 루프에서 속성에 액세스하는 것에 대해 걱정할 필요가 없습니다. –
그건 확실히 좋은 방법입니다! – dcastro
전체 줄을 Get 메서드로 이동하는 것은 일반적으로 좋지 않은 습관입니다. CodeMaid라는 Visual Studio에 뭔가 설치되어 있습니다. 그것은 CodeMaid Spade라고 불리는 것을 가지고 있으며, 각 방법을 평가하고 점수를줍니다. 점수가 높을수록 점수가 떨어집니다. 속성에도 사용할 수 있습니다. 여러분이 시도해 보길 권합니다. 포맷팅, 들여 쓰기, 다른 좋은 연습들도 도움이 될 것입니다.
정말 중요한 크기는 아닙니다. 그것은 오래는
다음은 적절한 속성 사용에 대한 몇 가지 지침입니다.
편집
위의 지침을 공유 한 이상적인 : 그 사용자가 기대하는 것 때문에 속성 접근은, 데이터 액세스처럼 행동해야한다. 빌 와그너에 의해 도서 효과적인 C#을에서
:등록 데이터처럼 호출 코드에서 볼 수있는 방법이 있습니다. 그것은 사용자의 머리 속에 몇 가지 기대를 안겨줍니다. 그들은 속성 액세스를 데이터 액세스 인 것처럼 보게됩니다. 결국, 그 모양입니다. 부동산 접근자는 이러한 예상치 인 에 부합해야합니다. 접근자는 접근 할 수있는 측면이 없어야합니다. 효과. 접근 자 설정은 상태를 수정하므로 사용자는 을 통해 변경 사항을 볼 수 있어야합니다.
속성 접근자는 또한 사용자에 대한 기대치가 입니다. 속성 액세스는 데이터 필드 액세스와 같습니다. 의 성능 특성이 단순한 데이터 액세스와 크게 다를 수 없습니다.
속성 이 긴 계산을 수행하거나 만들 응용 프로그램 간 호출 (예 : 데이터베이스 쿼리를 수행) 또는 속성 접근에 대한 사용자의 기대 과 일치하지 않는 것, 다른 긴 작업을하지 말아야 액세서.알베르토에 의해
보너스 : 일반적인 지침으로 http://msdn.microsoft.com/en-us/library/vstudio/ms229054%28v=vs.100%29.aspx
정확히 내가 쓰려고했던 내용이었습니다. 당신이 저에게 묻는다면 "부작용"부분이 가장 중요합니다. –
+1. 임의의 라인 한도는 정확히 임의적입니다. 가능한 한 작게하려고 노력해야합니다. 그러나 임의의 한계로 인해 메소드를 분리하면 가독성이 떨어질 수 있습니다. –
속성과 메서드 중 하나를 선택하는 방법에 대한 좋은 정보를 추가하고 싶습니다. http://msdn.microsoft.com/en-us/library/vstudio/ms229054%28v=vs.100%29.aspx – Alberto
는 방법은 한 화면에 맞게보다 더 줄 필요는 없습니다. 스크롤해야하는 경우 너무 큽니다. 작은 방법으로 분할하십시오.
나는 메소드가 가능한 작고 작아야한다고 믿습니다. 임의의 한도 (한 화면 - 해상도)로 인해 메소드를 다른 메소드로 분할하면 가독성이 저하 될 수 있습니다. 임의의 한계를 상회하는 상식. –
누구의 화면입니까? :) 때로는 긴 방법을 갖는 것이 좋습니다. 논리 만이 메소드 크기를 지정해야합니다. –
나쁘다는 것은 아니지만, 나라면 긴장하게 만들 것이고 어떻게 든 해보려하고 노력할 것입니다. getter는 메서드이기 때문에 전체를 30 회선 방법으로 끌어 당기는 것이 내 의견으로는 시간 낭비 일 것입니다. 나는 그것을 자르려고 노력했을거야. 예 : 어떤 수표가있는 고리 인 경우 수표를 방법 또는 일부로 추출합니다.
속성에 대한 구체적인 지침은 알지 못하지만 많은 최상의 코딩 방법은 한 가지 방법에서 선의 기본 설정으로 7-10 줄을 사용합니다. –
게터는 무엇을하고 있습니까? –
좋은 질문입니다. getter는 다음 문서와 유사한 기능을 포함하는 클래스에서 사용됩니다. http://umerpasha.wordpress.com/2013/06/13/c-code-to-get-latest-tweets-using-twitter-api- 1-1/클래스의 다른 멤버 (예 : 모든 OAuth 토큰)에서 생성 할 수있는 많은 수의 스팅 (예 : baseString)을 알 수 있습니다. –