Вредны ли частные статические методы в C #?


10

Я создал частный метод проверки для определенной проверки, которая происходит несколько раз в моем классе (я не могу сохранить проверенные данные по разным причинам). Теперь ReSharper предлагает сделать функцию статичной. Я немного не хочу этого делать из-за известных проблем со статическими методами. Это был бы приватный статический метод. Мой вопрос заключается в том, могут ли частные статические методы вызывать такие же проблемы связывания и тестирования, как публичные статические методы? Это плохая практика? Думаю, нет, но я не уверен, что здесь есть подводный камень.


10
Каковы "известные проблемы" со статическими методами?
Роберт Харви

3
@ Эд: Верно. Правильно написанные статические методы в любом случае не должны касаться внешних API или состояния. Мне кажется, что манипулирование внутренним состоянием, инкапсулированным в классе, вполне нормально, и метод не нуждается в модульном тестировании, поскольку модульное тестирование проверяет внешнее поведение класса.
Роберт Харви

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

2
@ Tamás Статические методы изменяют глобальное состояние, только если вы пишете их таким образом, чего я никогда не делаю. Вообще говоря, я использую только статические методы в служебных классах, методы, которые принимают один или несколько объектов и возвращают объект без побочных эффектов. Эти методы не имеют проблем, которые вы описываете.
Роберт Харви

1
@ TamásSzelei Как они склонны изменять глобальное состояние? Они даже не могут найти глобальное состояние, если вы не передадите его в параметр.
CodesInChaos

Ответы:


16

Я бы подумал: «Мне нужно проверить это?»

Если ваш метод в любом случае является закрытым, то есть вы не хотите проводить модульное тестирование логики в самом методе, то с точки зрения тестируемости и ремонтопригодности ваш класс в любом случае является черным ящиком, внутренняя работа вашего класса - это его бизнес и только. Рефакторинг также не будет затронут, что также необходимо учитывать.

Итак, на мой взгляд: нет, создание «частного» метода «частной статики» не будет иметь никаких долгосрочных последствий.


17

С моей точки зрения, частные статические методы - самая легкая вещь из всех возможных.

DataIn -> Метод -> DataOut

Нет никаких зависимостей от внешних объектов, нет побочных эффектов. Почему вы считаете их плохими?


Спасибо. Я объяснил свои проблемы в комментариях под вопросом.
Тамас Селеи

2
То, что вы описываете, верно только для статических методов, не зависящих от статических переменных-членов - вот что может сделать разницу между «хорошим» и «плохим» статическим методом.
Док Браун

2

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

Тем не менее, я не вижу причин, чтобы не использовать частные статические методы. Действительно, есть небольшое преимущество в производительности, так как вам не нужен экземпляр класса для заполнения памяти.

С другой стороны, все, что статично, является запахом кода. Это действительно "вспомогательный класс"? Может ли быть так, что метод мог бы с большей пользой находиться в одном из классов, передаваемых в качестве параметра? Ответ на эти вопросы часто «хороший, как статичный», но его стоит запомнить.


Класс, содержащий статический метод, уже все равно занимает память. Ваш страх перед staticключевым словом кажется необоснованным.
Роберт Харви
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.