Почему прохождение объектов статическими методами было бы выгодно?

Почему было бы выгодно использовать статический метод и передавать ссылку на объект в качестве параметра, а не вызывать метод объекта?

Чтобы уточнить, что я имею в виду, рассмотрим следующий класс:

public class SomeClass {
    private double someValue;

    public SomeClass() {
        // Some constructor in which someValue is set
    }

    public void incrementValue() {
        someValue++;
    }
}

По сравнению с этой альтернативной реализацией со статическим методом:

public class SomeClass {
    private double someValue;

    public SomeClass() {
        // Some constructor in which someValue is set
    }

    public static void incrementValue(SomeClass obj) {
        obj.someValue++;
    }
}

Мой вопрос не ограничивается только этим классом; меня интересует любая точка, в которой вы передаете объект вместо вызова его в методе. Является ли это когда-либо выгодным? Если так, то почему?

Тривиальный пример: когда переданный экземпляр может на законных основаниях быть нулевым, и вы хотите включить (нетривиальную) обработку этого в метод.

В вашем примере метод instance - явный победитель.

В общем случае я могу подумать о нескольких причинах, когда статический метод может быть уместным:

• Вы хотите поместить статический метод в другой класс, поскольку у вас есть ситуация, когда имеет смысл отделить логику от данных (примечание: ваш пример не один из них).

• Вы передаете два или более объектов и хотите подчеркнуть, что они имеют одинаковое значение.

• null является допустимым значением (как объяснено пользователем 9000).

Было бы целесообразно включить методы, которые изменяют состояние объекта, в качестве методов экземпляра, а не статического метода.

Однако мы можем найти примеры статических методов, которые являются pureметодами и принимают объект в качестве входных данных, например, когда нам нужно создать экземпляр объекта на основе определенных правил проверки. Например, в .NET есть метод DateTime.TryParse(String s, DateTime d)для проверки и создания экземпляра объекта. Но параметр DateTime dявно помечен как out.

Другой случай может быть, когда мы сравниваем объекты и хотим получить желаемый объект как возвращаемое значение, а не логическое / целочисленное значение результата сравнения, например Team.GetHigherScorer(teamA, teamB).IncreaseRanking(),. Это будет чище, чем:

int compareResult = teamA.compareScoreWith(teamB);
if (compareResult == 1)
    teamA.IncreaseRanking();
else if (compareResult == -1) 
    teamB.IncreaseRanking();

(оставив корпус "вытянуть" для простоты).

Внедрение зависимостей будет хорошей причиной для выполнения вызова статического метода. Предполагая, что конкретная реализация SomeClassимеет цепочку наследования или является реализацией другого класса. Вы можете использовать макет объекта, передать его в целях тестирования, чтобы убедиться, что ваш метод делает то, что должен, и затем отчитаться об этом состоянии.