Чи шкодять приватні статичні методи в C #?

Я створив приватний метод перевірки для певної перевірки, яка трапляється кілька разів у моєму класі (я не можу зберігати перевірені дані з різних причин). Тепер ReSharper припускає, що функція може бути статичною. Я трохи не бажаю цього робити через відомі проблеми зі статичними методами. Це був би приватний статичний метод. Моє запитання полягає в тому, чи можуть приватні статичні методи викликати подібні проблеми зв'язку та тестування, як державні статичні методи? Це погана практика? Я б не здогадався, але я не впевнений, чи є тут підводний камінь.

c# static-methods

— Тамаш Селей
джерело

Які "відомі проблеми" статичних методів?

— Роберт Харві

@Ed: Правильно. Правильно написані статичні методи ні в якому разі не повинні торкатися зовнішніх API чи стану. Маніпулювання внутрішнім станом, інкапсульованим у межах класу, здається мені цілком нормальним, і метод не потребує тестування на одиниці, оскільки тестування блоку перевіряє зовнішню поведінку класу.

— Роберт Харві

Статичні методи схильні до зміни глобального стану, і вони також вбивають спадщину (у будь-який момент, коли ви хочете розширити функціональність, вам потрібно буде змінити код виклику, оскільки ви не можете змінити метод у похідному класі). Ви пов'язані з цією реалізацією. Статичні методи не можна глузувати, що робить їх дуже важкими для одиничного тестування. Вони приховують залежність . Я впевнений, що є більше. Щоб не просто сліпо уникати їх, я прошу прийняти зважене рішення.

— Tamás Szelei

@ Tamás Статичні методи змінюють глобальний стан лише тоді, коли ви пишете їх так, чого я ніколи не роблю. Взагалі кажучи, я використовую лише статичні методи в класах корисних програм, методи, які беруть один або кілька об'єктів і повертають об'єкт без побічних ефектів. Такі методи не мають жодної з описаних вами проблем.

— Роберт Харві

@ TamásSzelei Як вони схильні змінювати глобальний стан? Вони навіть не можуть знайти глобальний стан, якщо ви не передасте його в параметр.

— CodesInChaos

Відповіді:

Я б подумав: "Чи потрібно це перевірити?"

Якщо ваш метод все одно приватний, це означає, що ви не хочете перевіряти логіку в самому методі, то, що стосується доказовості та ремонтопридатності, ваш клас - це чорна скринька, так чи інакше, внутрішня робота вашого класу - це його бізнес і тільки його. Не вплине і рефакторинг, що також варто врахувати.

Отже, на мою думку: Ні, перетворення "приватного" методу "приватної статики" не матиме довгострокових наслідків.

— Ед Джеймс
джерело

Приватні статичні методи - це найпростіша річ, з моєї точки зору.

DataIn -> Метод -> DataOut

Ніяких залежностей від зовнішніх об'єктів немає, побічних ефектів немає. Чому ви вважаєте їх поганими?

— Кодер
джерело

Дякую. Я пояснив свої занепокоєння в коментарях до цього питання.

— Tamás Szelei

Те, що ви описуєте, є правильним лише для статичних методів, не залежних від змінних статичних членів - саме те може стати різницею між "хорошим" і "поганим" статичним методом.

— Doc Brown

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

Однак я не бачу жодної причини не використовувати приватні статичні методи. Дійсно, є невелика користь від продуктивності, оскільки вам не потрібен примірник класу, щоб зайняти пам'ять.

З іншого боку, все статичне - це трохи кодовий запах. Це насправді "клас помічників"? Чи може бути, що метод може більш корисно розташовуватися на одному з класів, переданих як параметр? Відповідь на ці запитання часто "це добре як статичний", але варто пам'ятати.

— Джеремі Макгі
джерело

Клас, що містить статичний метод, у будь-якому випадку вже займає пам'ять. Ваш страх перед staticключовим словом здається безпідставним.

— Роберт Харві