내 개인 메서드를 정적으로 만들 것을 권장하는 Resharper의 권장 사항입니까?

Question

최근에 Resharper가 메서드를 정적으로 만들 수 있다는 힌트를 표시하는 개체에 몇 개의 필드를 설정하는 개인 메서드를 만들 때 알아 챘습니다.

다음은 내가 제안 할 수있는 방법에 대한 매우 간단한 예입니다.

private void MakeStatusTheSame(MyClass mc, MySecondClass msc) 
{ 
    mc.Status = msc.Status; 
} 

이와 같은 방법이있을 때 Resharper는이 방법을 정적으로 설정할 것을 권장합니다.

나는 단위 테스트에서 혼란을 야기하기 때문에 정적 메서드를 만드는 것을 피하려고 노력하지만 ... 같은 방법이 개인 메서드에 적용되는지 확신 할 수 없다.

Resharper의 권장 사항은 유효한 모범 사례입니까, 아니면 그냥 꺼야합니까?

Answer 1

필자는 이것이 확실히 정적 메서드의 주요 후보라고 생각합니다. 그것은 예를 들어 등 클래스의 속성, 필드, 여기

중 하나를 변화하는 아니에요 :

public static class Extensions 
{ 
    public static MyClass MakeStatusTheSame(this MyClass mc, MySecondClass msc) 
    { 
    mc.status = msc.status 
    return mc; /* make the method chainable */ 
    } 
} 

: 또한

class MyClass 
{ 
    public static void MakeStatusTheSame(MyClass mc, MySecondClass msc) 
    { 
    mc.status = msc.status; 
    } 

    private void MakeStatusTheSame(MySecondClass msc) 
    { 
    this.status = msc.status; 
    } 

    private int status; 
} 

을, 당신은 그것을 (정적 것) 확장 메서드를 만들 수

Answer 2

나는 그렇게 생각한다. 메소드가 정적이라는 것을 알면 메소드가 이 아니고이 인스턴스 멤버와 상호 작용해야한다는 명확한 표시입니다.

정적이 아닌 메소드를 디버깅하고 인스턴스가 손댈 수 없다는 것을 상상해보십시오. 즉시 냄새가 나는데, 기능이 무엇인지 설명하는 설명이 없으면 실제 문제로부터 정신을 잃을 수 있습니다.

Answer 3

나는 보통 R #의 추천과 함께 간다. 그것은 개인적인 방법입니다, 그래서 (희망을 갖고) 당신은 그것에 대해 단위 테스트를 작성하지 않습니다. static으로 명시 적으로 설정하면 인스턴스 멤버를 사용하지 않으므로 부작용을 검사하기가 더 쉽습니다.

Answer 4

contrarian처럼 들릴 위험이 있으므로 정적 메서드와 인스턴스 메서드를 섞어 놓는 것이 좋지 않다는 것을 인정해야합니다. 나는 일반적으로 정적 인 방법을 싫어한다. 정적 메서드는 테스트하기 어렵고 재정의하기 어렵고 유지하기가 어렵습니다. Foo 객체를 처리하기위한 모든 정적 메서드를 단일 FooUtils 클래스에 사용하는 것이 더 좋지만, FooSomethingDoer 클래스의 singleton 인스턴스에 사용하는 것이 더 좋습니다.

정적 메서드는 경우에 따라 완벽합니다. 예를 들어 앞에서 설명한 싱글 톤이나 팩토리를 만들 때 등 모든 고정 메서드가 순수한 악으로 만들어지는 것은 아닙니다. 나는 가능한 한 그들을 피할 수있는 측면에서 실수하는 것을 선호한다.