Советы по предотвращению чрезмерного использования статического метода

Question

Я рефакторинг некоторого кода, и я смотрю на класс под названием HFile. HFile имеет все частные конструкторы, поэтому вы не можете создавать его экземпляры. Вместо того чтобы создавать экземпляры HFiles следующим образом:

var file = new HFile('filename')
file.Save()

все взаимодействия HFile обрабатываются статическими методами. Поэтому, если бы я хотел сохранить файл, я бы позвонил:

HFile.save('filename')

, а затем внутренне будет создан экземпляр HFile, а затем сохранен. Очевидно, не зная всей истории, любой читатель должен оставить за собой суждение, но кажется, что использование статических методов стало очень модным на моем рабочем месте. Поэтому мне интересно, есть ли хорошие принципы / лучшие практики для использования статических методов, которые могут быть полезны для группы парней, сидящих и рассматривающих использование статических методов.

Answer 1

Множество статических методов / статических классов является симптомом процедуралита - написания процедурного кода на объектно-ориентированном языке. Лучший из известных мне способов устранения такого мышления - это глубокое понимание объектно-ориентированных принципов и практик. Использование управляемой тестами разработки и принуждение кода быть тестируемым поможет, потому что писать тесты для статических классов намного сложнее. В конце концов, если вы используете TDD, вы, естественно, тяготеете к более несвязной архитектуре OO, хотя бы для облегчения тестирования.

Answer 2

В общем, если ваша ситуация требует инкапсуляции состояния или организационной структуры, то вы будете использовать классы.

С другой стороны, если у вас есть что-то, что является сквозной задачей и может широко использоваться в вашем приложении, вы можете рассмотреть методы в статическом служебном классе. System.Math в .NET Framework (и Java) является примером этого.

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

Answer 3

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

Answer 4

Я бы не беспокоился о количестве статических методов так же, как о том, что делают эти методы. Статический метод, который возвращает значение или изменяет объект, который вы передаете в качестве аргумента? Ничего страшного. Статический метод, который изменяет частные статические поля? Я беспокоюсь. Статический метод, который изменяет открытые статические поля, принадлежащие другим классам? Мне нужно лечь в темной комнате с влажной тряпкой на лбу.

Answer 5

Статические методы IMO бесполезны для целей, которые вы описали, распространены на вашем рабочем месте. Недостатки этого метода:
- Какой смысл создавать объект, представляющий файл, чтобы просто вызвать один метод для него?
- не может использовать интерфейсный полиморфизм

Чтобы ответить на ваш вопрос, вот несколько случаев, когда я бы использовал статический метод:
- служебный метод, который делает что-то, связанное с функциональностью класса, но не с каким-либо одним объектом. Возможно, он берет массив объектов и сравнивает их. Возможно, он выполняет некоторые общие операции с данными (преобразования и т. Д.).
- где вам нужно делать связанные с классом вещи с переменными класса
- где вы хотите реализовать шаблон одноэлементного дизайна

Answer 6

Это не очень объектно-ориентированный, не так ли?Теперь, может быть, вашему месту не очень нравится ОО-код, и это нормально.Но если вы хотите инкапсулировать данные и методы, вам понадобятся методы экземпляра для работы с этими данными.

Обилие статических методов, вероятно, связано с большим количеством глобальных переменных.Например.информация, которую вы пытаетесь сохранить в имя файла, должна быть глобальной, если вы собираетесь вызывать статический HFile.save ('filename').Обычно мы стараемся сократить глобальные переменные, чтобы сделать их более управляемыми.

Но если вы хотите написать процедурный код, тогда все в порядке.