Как решить между статическими и нестатическими методами C#?

Вот, пожалуйста.

Прежде всего:

Так что я склонен очень часто использовать статические методы (быть независимым от конкретного экземпляра - независимость всегда хорошая вещь). [1226 Скорее наоборот: при использовании статических методов вы очень зависите от конкретного экземпляра.

Что касается вашего документа , я бы не пошел ни в какую сторону. Вы перечислили все обязанности класса Document , который включает в себя агрегацию данных, сохранение себя в базе данных, а также операции над страницами и копирование.

Это много. Согласно SRP , каждый «модуль» (здесь «модуль», используемый как универсальный термин) должен иметь только одну причину для изменения. Ваш Документ имеет множество обязанностей, поэтому у него есть множество причин для изменения. Это не хорошо. 1229 С учетом этого я перенесу всю логику в другие классы со строго определенными обязанностями. Я полагаю, более или менее приемлемый критерий того, что перемещать, был введен Хербом Саттером или Андреем Александреску следующим образом: все операции (методы мышления), которые могут быть выполнены с объектом через его публичный контракт, должны быть перемещены за пределы рассматриваемый объект.

---

Вы не можете использовать статические методы для реализации интерфейса и не можете переопределить статические методы. Поэтому использование статических методов означает, что вы просто не выполняете ООП.

Подумайте, как бы вы реализовали следующую функциональность, используя только статические методы?

interface IDocument 
{
   void Print(IDevice targetDevice);
}

IDocument instance;

instance = new PdfDocument();
instance.Print(printer);

instance = new WordDocument();
instance.Print(printer);

Мое "правило":

• Если мне не нужно использовать свойства из моего класса, сделайте его статическим. (другими словами, если метод на самом деле не привязан к классу, просто для логической ассоциации используйте static)

В общем, если у вас есть такой метод, как:

Document.Copy(myDocumentObject, toPath);

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

Если вам нужно спросить, не используйте статику.

Фактическое практическое правило (и существует множество реальных технических причин, но я считаю, что это помогает объяснить концепции):

• Если рассматриваемый класс может существовать несколько раз, он не является статичным.

• Если рассматриваемый метод действует против информации об экземпляре, он не является статичным.

• Если метод или класс связан с метаинформацией, он является статическим.

С этими рекомендациями ясно, что файлы и документы кратны, а копирование акт против инстанции. Метод не должен быть статичным.

Статические методы Они могут быть очень полезны, мне нравятся методы расширения, но они принудительно связывают и при неправильном использовании могут сделать тестирование кошмаром!

Хороший пример того, когда использовать статический метод, когда вы хотите сделать проверку

public static errors Validate(Document myDoc)
{
..some validation code
}

, это очень проверяемый и не важно, что вы тесно связываете метод с объектом. Плохое место для использования статического метода - когда он дозирует что-то другое, а потом просто возвращает что-то, Примером может служить слой Biz, который проверяет объект, и, если он проходит проверку, он сохраняет данные в БД

public static errors ValidateAndSave(Document myDoc)
{
    errors docErrors = Validate(myDoc);
    if(docErrors.count==0)
    {
         docErrors = SaveToDB(myDoc);
    }

   return docErrors; 
} 

Это очень сложно проверить, потому что каждый раз, когда вы его запускаете, и он проходит проверку вашего переноса в базу данных. ваша логика Biz может генерировать не ошибку, но ваш уровень DAL может, поэтому вместо того, чтобы тестировать только функциональность уровня Biz, вам также придется тестировать также слой DAL, и вы тесно связываете свой объект, свой уровень Biz и ваш Dal вместе делает это очень трудно проверить и поддерживать.

поэтому вместо того, чтобы тестировать только функциональность уровня Biz, вам также необходимо протестировать также слой DAL, а также тесную связь вашего объекта, уровня Biz и вашего Dal, что делает его очень трудным для тестирования и сопровождения.

поэтому вместо того, чтобы тестировать только функциональность уровня Biz, вам также необходимо протестировать также слой DAL, а также тесную связь вашего объекта, уровня Biz и вашего Dal, что делает его очень трудным для тестирования и сопровождения.

В целом, я бы сказал, что «копирование» себя в отношении объекта обычно означает клонирование данных в новый объект. Описанное здесь «копирование» - это то, что файловая система делает от вашего имени, а не объект. Поэтому я бы сделал это статическим методом, а не методом в экземпляре Document.

То же, что и altCongnito, и я добавлю этот файлObject.Copy, который будет использовать каждый, больше, чем объект fileObject. Статика для функции, которая имеет идеальные отношения с классом, а не функциональную зависимость от него.

If you use any other objects then you shokld default to instance level methods so that you can configure those dependencies using Dependancy Injection.

For example, if one of those images was an SVG image then you may have a dependency on an XML parser which (in Java at least) have many implementations, likewise for SVG renderers I imagine and many other constituent image types may require similar arrangements that evolve as the state of the object evolves or which must be changed in different usage scenarios (e.g. test, production, different projects re-using your code).

The blinking amber warning light is that you may be using classes that are not part of your framework's default libraries, so you've made a choice of a third party component and if using statics you are not well placed to modify that decision.

A useful "redline" is that if you touch another process (database server, web service etc) then I'd regard a static method as bad 100% of the time as this makes unit testing more dificult.

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

Ваш пример, говорящий о классе Document с методом копирования, является ярким примером. Я бы сказал, что правильная реализация OO - это первый способ . То есть иметь копию как метод экземпляра, подобный этому:

document1.copy(toPath)

Имеет смысл, что способность копировать себя является частью базовой абстракции Documents. Таким образом, клиентский код, отправляющий сообщение о копировании, должен только указать, где скопировать в , потому что понятно, что Документ отслеживает, где он находится внутри. Нет необходимости копировать эту информацию где-либо еще, что является серьезной проблемой с третьим вариантом, который вы представляете, который выглядит следующим образом:

Document.copy(fromPath, toPath)