Добрі причини статичних методів?

Я використовую статичні методи для речей, які мені дійсно потрібно, щоб бути статичними. Я використовую ReSharper для кращої якості коду. Іноді ReSharper припускає, що метод може стати статичним.

Коли я отримав наступний клас:

public class WhatEverClass {
    private string DoSomethingFancy(string input) 
    {
       string fancyStuff;
      //Fancy Stuff here
       return fancyStuff;
    }

    public WhatEverClass() {
       string awesome=DoSomethingFancy("some fancy string");
    }
}

ReSharper може сказати "DoSomethingFancy може бути статичним".

Я знаю, що може стати статичним, але чи є вагома причина для цього? Або я повинен просто ігнорувати ці пропозиції?

2
@astander Я не думаю, що його дублікат. Зв'язана стаття є дуже загальним питанням. У шахти є конкретний приклад і бажання, чому цей повинен стати статичним
додано Автор Ole Albers, джерело
@astander Я не думаю, що його дублікат. Зв'язана стаття є дуже загальним питанням. У шахти є конкретний приклад і бажання, чому цей повинен стати статичним
додано Автор Ole Albers, джерело
додано Автор Adriaan Stander, джерело
Я думаю, ви не повинні позначити його як статичний, якщо ви не на 100% впевнені, що метод не потребуватиме стану в якийсь момент.
додано Автор vc 74, джерело
інше подібне -
додано Автор NDJ, джерело
інше подібне -
додано Автор NDJ, джерело

12 Відповіді

Визначивши статичний метод, тому процедуру, яка обчислює , ви виявите наміри для споживача вашого API про безгромадянство ваша функція .

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

Коротше кажучи: коли ви бачите функцію, яка лише виконує дію над параметром і не зберігає певний стан, вона є хорошим кандидатом для створення статичної .

4
додано
+1 для того, щоб фактично надати корисні міркування за це, а не просто варіант "використовувати статичний, якщо вам явно не потрібно щось ще ...".
додано Автор Kjartan, джерело

Визначивши статичний метод, тому процедуру, яка обчислює , ви виявите наміри для споживача вашого API про безгромадянство ваша функція .

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

Коротше кажучи: коли ви бачите функцію, яка лише виконує дію над параметром і не зберігає певний стан, вона є хорошим кандидатом для створення статичної .

4
додано
+1 для того, щоб фактично надати корисні міркування за це, а не просто варіант "використовувати статичний, якщо вам явно не потрібно щось ще ...".
додано Автор Kjartan, джерело

Якщо вашому методу не потрібно говорити або змінювати стан об'єкта instanciated, то він повинен бути статичним.

1
додано
Виправте мене, якщо я помиляюся, але приватні статичні методи не повинні (негативно) впливати на блок-тести взагалі?
додано Автор Ole Albers, джерело
А як щодо модульного тестування?
додано Автор Dan Teesdale, джерело
Якщо статичний метод не змінює станів інших класів, це не буде проблемою з модульним тестом. Якщо метод викликається з інших класів, це не є одиничним тестом, це більше схоже на тестування інтеграції.
додано Автор user1648170, джерело
TypeMock мають можливість робити тест на статичні методи. Але так, статичні методи - це величезна проблема з модульним тестуванням.
додано Автор user1648170, джерело

Якщо вашому методу не потрібно говорити або змінювати стан об'єкта instanciated, то він повинен бути статичним.

1
додано
Виправте мене, якщо я помиляюся, але приватні статичні методи не повинні (негативно) впливати на блок-тести взагалі?
додано Автор Ole Albers, джерело
А як щодо модульного тестування?
додано Автор Dan Teesdale, джерело
Якщо статичний метод не змінює станів інших класів, це не буде проблемою з модульним тестом. Якщо метод викликається з інших класів, це не є одиничним тестом, це більше схоже на тестування інтеграції.
додано Автор user1648170, джерело
TypeMock мають можливість робити тест на статичні методи. Але так, статичні методи - це величезна проблема з модульним тестуванням.
додано Автор user1648170, джерело

Звичайне поняття полягає в тому, що якщо ви не створюєте примірник нічого, ви можете оголосити його статичним. Що стосується того, де вона повинна використовуватися, ReSharper дає вам пропозиції на основі стандартної практики програмування. Тим не менш, я беру "стандартні практики програмування" з зерном солі. Це питання особистої переваги програмування для деяких. Ось детальне посилання на тему:

http://msdn.microsoft.com/en-us/library/79b3xss3.aspx

1
додано

Звичайне поняття полягає в тому, що якщо ви не створюєте примірник нічого, ви можете оголосити його статичним. Що стосується того, де вона повинна використовуватися, ReSharper дає вам пропозиції на основі стандартної практики програмування. Тим не менш, я беру "стандартні практики програмування" з зерном солі. Це питання особистої переваги програмування для деяких. Ось детальне посилання на тему:

http://msdn.microsoft.com/en-us/library/79b3xss3.aspx

1
додано

Тому що ви будете викликати метод WhatEverClass() за межами класу, створивши примірник WhatEverClass . Таким чином, значення для кожного екземпляра буде різним, оскільки змінна є локальною і буде створюватися кожного разу при створенні екземпляра класу.

Але якщо ви хочете зберегти одне і те ж значення для всіх екземплярів, ви можете зробити його static , так що він буде створений один раз у пам'яті, і всі екземпляри будуть використовувати його.

0
додано
Вибачте. Але мова йде не про статичні значення.
додано Автор Ole Albers, джерело

Тому що ви будете викликати метод WhatEverClass() за межами класу, створивши примірник WhatEverClass . Таким чином, значення для кожного екземпляра буде різним, оскільки змінна є локальною і буде створюватися кожного разу при створенні екземпляра класу.

Але якщо ви хочете зберегти одне і те ж значення для всіх екземплярів, ви можете зробити його static , так що він буде створений один раз у пам'яті, і всі екземпляри будуть використовувати його.

0
додано
Вибачте. Але мова йде не про статичні значення.
додано Автор Ole Albers, джерело

Остерігайтеся наслідків статичного методу!

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

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

0
додано
Я не хочу, щоб забезпечити рамки або щось подібне. Це проект для клієнта, де я і члени команди мають джерело, але ніхто "зовні" не буде використовувати його як джерело чогось іншого
додано Автор Ole Albers, джерело
У вас завжди є споживачі - чи вважаєте ви їх зовнішніми чи ні. Первинне застосування, а також випробувальний джгут є двома споживачами з різними вимогами. Що робити, якщо ваш тест-ремінь хоче перевірити аспект вашої системи, не використовуючи конкретну реалізацію вашого алгоритму? Інші члени вашої команди споживатимуть ваш код - так?
додано Автор Lawrence, джерело

Остерігайтеся наслідків статичного методу!

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

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

0
додано
Я не хочу, щоб забезпечити рамки або щось подібне. Це проект для клієнта, де я і члени команди мають джерело, але ніхто "зовні" не буде використовувати його як джерело чогось іншого
додано Автор Ole Albers, джерело
У вас завжди є споживачі - чи вважаєте ви їх зовнішніми чи ні. Первинне застосування, а також випробувальний джгут є двома споживачами з різними вимогами. Що робити, якщо ваш тест-ремінь хоче перевірити аспект вашої системи, не використовуючи конкретну реалізацію вашого алгоритму? Інші члени вашої команди споживатимуть ваш код - так?
додано Автор Lawrence, джерело

Якщо метод DoSomethingFancy не використовує нічого в об'єкті WhatEverClass , він повинен бути в моїй книзі статичним, оскільки він фактично не має нічого спільного з об'єктом в якому він використовується.

0
додано

Якщо метод DoSomethingFancy не використовує нічого в об'єкті WhatEverClass , він повинен бути в моїй книзі статичним, оскільки він фактично не має нічого спільного з об'єктом в якому він використовується.

0
додано
var chat = new Chat();
var chat = new Chat();
642 учасників

Обсуждение вопросов по C# / .NET / .NET Core / .NET Standard / Azure Сообщества-организаторы: — @itkpi — @dncuug