방법은 정적으로 만들 수 있지만, 그래야 합니까?

방법은 정적으로 만들 수 있지만, 그래야 합니까?

ReSharper는 정적으로 만들 수 있는 ASP.NET 페이지당 여러 개의 함수를 지적하는 것을 좋아합니다.정적으로 만들면 도움이 됩니까?정적으로 만들고 유틸리티 클래스로 이동해야 합니까?

성능, 네임스페이스 오염 등은 모두 제가 볼 때 부차적인 것입니다.무엇이 논리적인지 자문해 보세요.메소드가 형식의 인스턴스에서 논리적으로 작동합니까, 아니면 형식 자체와 관련이 있습니까?후자의 경우에는 정적인 방법을 사용합니다.제어할 수 없는 유형과 관련된 경우에만 유틸리티 클래스로 이동합니다.

때때로 인스턴스에 논리적으로 작용하지만 아직 인스턴스의 상태를 사용하지 않는 메서드가 있습니다.예를 들어, 파일 시스템을 구축할 때 디렉터리의 개념을 얻었지만 아직 구현하지 않은 경우 파일 시스템 개체의 종류를 반환하는 속성을 작성할 수 있으며, 항상 "파일"이지만 인스턴스와 논리적으로 관련되어 있으므로 인스턴스 메서드도 마찬가지입니다.메소드를 가상화하려는 경우에도 중요합니다. 특정 구현에는 상태가 필요하지 않지만 파생 클래스가 있을 수 있습니다. (예를 들어, 컬렉션이 읽기 전용인지 여부를 묻는 경우, 해당 컬렉션의 읽기 전용 형식을 아직 구현하지 않았을 수 있지만 분명히 컬렉션 자체의 속성이지 유형이 아닙니다.)

대 입니다.
C# 언어 사양의 정적 및 인스턴스 멤버가 차이점을 설명합니다.일반적으로 정적 메소드는 인스턴스 메소드에 비해 매우 작은 성능 향상을 제공할 수 있지만, 다소 극단적인 상황에서만 사용할 수 있습니다(자세한 내용은 이 답변 참조).

FxCop 또는 코드 분석의 규칙 CA1822는 다음과 같이 명시합니다.

"[구성원을 정적으로 표시]한 후 컴파일러는 이러한 구성원에게 비가상 호출 사이트를 전송하여 현재 개체 포인터가 null이 아님을 확인하는 각 호출에 대한 런타임 검사를 방지합니다.이로 인해 성능에 민감한 코드에 대해 측정 가능한 성능 향상이 발생할 수 있습니다.경우에 따라 현재 개체 인스턴스에 액세스하지 못하는 것이 정확성 문제를 나타냅니다."

클래스
설계가 타당하지 않으면 유틸리티 클래스로 이동하면 안 됩니다.이 특정, 를 들어 적정방유관경우예, 들어를련된형과,ToRadians(double degrees)메소드는 각도를 나타내는 클래스와 관련이 있으며, 해당 메소드가 해당 유형의 정적 멤버로 존재하는 것이 타당합니다(참고로, 이것은 시연을 목적으로 하는 복잡한 예제입니다).

를 서드를다표시로 static클래스 내에서는 인스턴스 멤버를 사용하지 않는다는 것이 분명하므로 코드를 훑어볼 때 유용할 수 있습니다.

개념적으로 매우 밀접하게 연관된 다른 클래스와 공유해야 하는 경우가 아니라면 반드시 다른 클래스로 이동할 필요는 없습니다.

당신의 경우에는 이런 일이 일어나지 않을 것이라고 확신하지만, 제가 어떤 코드에서 본 "나쁜 냄새"는 많은 정적인 방법을 사용하여 유지해야 했습니다.

불행하게도, 그것들은 특정 애플리케이션 상태를 가정한 정적인 방법이었습니다.(물론 애플리케이션당 사용자가 한 명뿐입니다!사용자 클래스가 정적 변수에서 이를 추적하지 않는 이유는 무엇입니까?)그것들은 글로벌 변수에 접근하는 미화된 방법들이었습니다.그들은 또한 정적 생성자(!)를 가지고 있었는데, 이것은 거의 항상 나쁜 생각입니다.(저는 몇 가지 합리적인 예외가 있다는 것을 알고 있습니다.

그러나 정적 메서드는 실제로 개체의 인스턴스 상태에 의존하지 않는 도메인 논리를 추출할 때 매우 유용합니다.그것들은 당신의 코드를 훨씬 더 읽기 쉽게 만들 수 있습니다.

그것들을 올바른 위치에 놓는 것만 확인하세요.정적 방법이 다른 물체의 내부 상태를 침해적으로 조작하고 있습니까?대신에 그들의 행동이 그러한 클래스 중 하나에 속한다고 좋은 사례가 만들어질 수 있습니까?고민을 제대로 나누지 않으면 나중에 두통이 생길 수도 있습니다.

흥미로운 내용입니다.
http://.com/ 57p://thecuttingledge.com/ ?p=57

ReSharper는 실제로 메서드를 정적으로 만들라고 제안하지 않습니다.당신은 왜 그 방법이 그 클래스에 있는지 자문해봐야 합니다. 예를 들어, 서명에 나타나는 클래스 중 하나와 반대로...

그러나 ReSharper 설명서에 나와 있는 내용은 다음과 같습니다. http://confluence.jetbrains.net/display/ReSharper/Member+can+be+made+static

@Jason True의 답변에 덧붙이자면, 어떤 방법에 '정적'을 넣는 것만으로는 그 방법이 '순수'하다는 보장이 없다는 것을 깨닫는 것이 중요합니다.선언된 클래스와 관련하여 상태 비저장이지만 상태(응용프로그램 구성 등)가 있는 다른 '정적' 개체에 액세스할 수도 있습니다. 이것이 항상 나쁜 것만은 아닐 수 있지만, 제가 개인적으로 정적 방법을 선호하는 경향이 있는 이유 중 하나는 만약 그것들이 순수하다면,주변 상태에 대해 걱정할 필요 없이 격리된 상태에서 테스트하고 추론할 수 있습니다.

클래스 내의 복잡한 논리에 대해, 저는 인스턴스 입력이 메서드 시그니처에 명확하게 정의되고 인스턴스 부작용이 발생할 수 없는 격리된 논리를 만드는 데 유용한 개인 정적 방법을 발견했습니다.모든 출력은 반환 값 또는 out/ref 매개 변수를 통해 이루어져야 합니다.복잡한 논리를 부작용이 없는 코드 블록으로 분해하면 코드의 가독성과 코드에 대한 개발 팀의 신뢰도를 높일 수 있습니다.

반면에 그것은 유틸리티 방법의 확산에 의해 오염된 클래스로 이어질 수 있습니다.일반적으로 논리적 이름 지정, 문서화 및 팀 코딩 규칙의 일관된 적용은 이러한 문제를 완화할 수 있습니다.

주어진 시나리오에서 가장 읽기 쉽고 직관적인 작업을 수행해야 합니다.

. 실제로 매개 변수성능인가극상제좋는외인아고하은다닙수니가황을인수단장적는▁(성▁is▁the▁extra다▁parameter아▁that▁one니▁perform닙▁the▁thing▁is▁situ좋인ations▁argumentance▁as▁only▁actually▁that▁in▁the▁not가▁happening▁most)뿐이기 때문입니다. 실제로 발생하는 것은 하나의 추가 매개 변수(this인스턴스 메서드에 대한 스택으로 푸시되고 있습니다.

ReSharper는 논리를 확인하지 않습니다.메소드가 인스턴스 멤버를 사용하는지 여부만 확인합니다.메서드가 비공개이고 인스턴스 메서드 하나에서만 호출되는 경우 이는 인스턴스 메서드를 허용하는 신호입니다.

정적 방법과 인스턴스 방법의 차이를 이미 이해하셨기를 바랍니다.또한, 긴 대답과 짧은 대답이 있을 수 있습니다.긴 답변은 이미 다른 사람들이 제공합니다.

나의 짧은 대답:예, ReSharper가 제안하는 대로 정적 방법으로 변환할 수 있습니다.그렇게 해서 나쁠 것은 없습니다.메소드를 정적으로 만들면 메소드에 인스턴스 멤버가 불필요하게 들어가지 않도록 메소드를 실제로 보호할 수 있습니다.그런 방식으로 "클래스 및 구성원의 접근성 최소화" 원칙을 달성할 수 있습니다.

ReSharper가 인스턴스 메소드를 정적 메소드로 변환할 수 있다고 제안할 때 실제로는 다음과 같이 말합니다. "왜...이 메서드는 이 클래스에 있지만 실제로는 어떤 상태도 사용하지 않습니다."그래서, 그것은 여러분에게 생각할 거리를 줍니다.그러면 그 방법을 정적 유틸리티 클래스로 이동해야 하는지 여부를 인식할 수 있는 사람은 당신입니다.SOLID 원칙에 따르면, 수업은 오직 한 가지 핵심적인 책임만을 가져야 합니다.그래서, 여러분은 그런 방식으로 수업을 더 잘 정리할 수 있습니다.인스턴스 클래스에서도 도우미 메소드가 필요할 수 있습니다.그런 경우에는 #지역 도우미 내에 보관할 수 있습니다.

기능이 여러 페이지에서 공유되는 경우 기본 페이지 클래스에 배치한 다음 해당 기능을 사용하는 모든 asp.net 페이지가 해당 페이지에서 상속되도록 할 수도 있습니다(또한 기능이 정적일 수도 있음).

메서드를 정적으로 만든다는 것은 클래스의 인스턴스를 먼저 만들지 않고 클래스 외부에서 메서드를 호출할 수 있다는 것을 의미합니다.이 기능은 타사 벤더 개체 또는 추가 기능으로 작업할 때 유용합니다.con을 호출하기 전에 먼저 console 개체 "con"을 만들어야 한다고 상상해 보십시오.줄 바꿈();

네임스페이스 오염을 제어하는 데 도움이 됩니다.

그냥 내 터펜스야.유틸리티 클래스에 모든 공유 정적 메서드를 추가하면 다음을 추가할 수 있습니다.

using static className; 

코드를 더 빨리 입력하고 더 쉽게 읽을 수 있도록 하는 사용자의 설명입니다.예를 들어, 저는 제가 상속받은 일부 코드에서 "글로벌 변수"라고 불리는 것을 많이 가지고 있습니다.인스턴스 클래스인 클래스에서 전역 변수를 만드는 대신 모든 변수를 전역 클래스의 정적 속성으로 설정했습니다.이렇게 하면 번거롭더라도 작업을 수행할 수 있으며 정적 네임스페이스가 이미 참조되어 있으므로 이름으로 속성을 참조할 수 있습니다.

이게 좋은 연습인지 아닌지 모르겠어요.저는 C# 4/5에 대해 배울 것이 너무 많고 리팩터해야 할 레거시 코드가 너무 많아서 Roselyn 팁이 저를 안내하도록 노력하고 있습니다.

조이

언급URL : https://stackoverflow.com/questions/169378/method-can-be-made-static-but-should-it