Подсказки для предотвращения Злоупотребления Статического метода

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

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

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

HFile.save('filename')

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

9
задан Joshua Taylor 10 October 2013 в 19:40
поделиться

6 ответов

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

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

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

6
ответ дан 4 December 2019 в 07:35
поделиться

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

11
ответ дан 4 December 2019 в 07:35
поделиться

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

5
ответ дан 4 December 2019 в 07:35
поделиться

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

3
ответ дан 4 December 2019 в 07:35
поделиться

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

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

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

2
ответ дан 4 December 2019 в 07:35
поделиться

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

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

2
ответ дан 4 December 2019 в 07:35
поделиться
Другие вопросы по тегам:

Похожие вопросы: