[Редактировать]

Мой оригинальный вопрос был «Почему выбирать между статическим и нестатичным? Оба делают то же самое ...»

К сожалению, он был отредактирован до специфического для C # вопроса, чего я действительно хотел избежать.

Итак, позвольте мне сделать некоторые дополнения:

Когда я говорю «интерфейс», я имею в виду не интерфейс C # -ключей, а то, что я понимаю, что-то вроде интерфейса С ++: набор четко определенных функций для работы с моим объектом. Говоря об ослаблении моего интерфейса, я имею в виду разные функции (статические / нестатические), которые выполняют одно и то же. Мой интерфейс больше не определен, когда есть разные функции, которые делают одно и то же.

Итак, как написал Боб Дворник, я могу реализовать функцию Validate ()

Document.Validate(myDocumentObject);    

но и

myConcreteDocumentObject.Validate();

Чтобы вернуться к моему Copy () - пример можно реализовать Copy (), как

myConcreteDocument.Copy(toPath);

но и

Document.Copy(myConcreteDocumentObject, toPath)

или же

Document.Copy(fromPath, toPath)

когда я думаю о папке, которая содержит все файлы, принадлежащие моему Документу (в этом случае я не зависим от конкретного экземпляра - но я зависим от других вещей :)).

В общем, я говорю о статических методах, а не о статических классах (извините, если я забыл упомянуть).

Но, как сказал Антон Гоголев, я думаю, что мой класс Document не является хорошим примером и не очень хорошо продуман, поэтому я думаю, что мне придется взглянуть на принцип единой ответственности.

Я мог бы также реализовать какой-то класс ManagerClass, который работает с моим DocumentClass:

Например:

myDocumentManagerObject.Copy(myConcreteDocumentObject, toPath);

или же

myDocumentManagerObject.Copy(myConcreteDocumentObject, toPath);

но если я обращаюсь к подходу 1), я склонен создавать объекты, которые выполняют свои задачи самостоятельно, а не другие объекты (DocumentManager), которые делают что-тос участием мой DocumentObject.

(Я надеюсь, что это не пойдет на религиозную дискуссию об ООП;).)

[/РЕДАКТИРОВАТЬ]

Старая версия:

Поначалу кажется, что это очень простой вопрос, например, «когда использовать статические методы, а когда нет», но с этим я время от времени сталкиваюсь (и мне сложно описать реальную проблему; возможно, это просто получить причины, почему (не) использовать 1) или почему (не) использовать 2)).

(Хотя я использую синтаксис C #, это не проблема C #)

В ООП существует два подхода (среди прочих) к работе с объектами:

1) Если я хочу, чтобы мой объект что-то сделал, я просто говорю ему сделать это:

myConcreteObject.DoSomething();

Это как разговаривать с объектом.

2) Или, если вы поклонник статических методов:

ObjectClass.JustDoIt();

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

Итак, при разработке класса мне часто приходится решать, использовать ли мне подход 1) или подход 2):

Представьте, что у вас есть класс «Документ», который должен обозначать документ, который должен быть сохранен в базе данных:

Документ

состоит из одного или нескольких файлов изображений из файловой системы (они становятся страницами одного документа)имеет что-то вроде библиографии - поля, в которые пользователь может добавлять информацию о документе, которая сохраняется в дополнительном файлеи должен иметь некоторые операции, такие как Copy (), AddPage (), RemovePage () и т. д.

Теперь я столкнулся с несколькими способами создания этого класса:

//----- 1) non static approach/talking to objects -----
Document newDocument = new Document();

// Copy document to x (another database, for example)
newDocument.Copy(toPath);

Мне нравится это: я говорю документу скопировать себя в базу данных x, и объект делает это сам. Приятно.

//----- 2) static approach ----------------------------
Document.Copy(myDocumentObject, toPath);

Почему нет? Также хорошо, чувствует себя очень удобно ...

Итак, какой из них реализовать? Обе? Или поместить статический подход в своего рода вспомогательный класс? Или выбрать подход 1) и придерживаться его, чтобы не ослабить интерфейс моего Document-класса?

Размышляя об обоих подходах, я прихожу к выводу, что (теоретически) можно реализовать любую функцию как статическую функцию:

Class.Function(aConcreteClassObject, parameters);

но тоже нестатично:

aConcreteObject.DoSomething(parameters);

Чтобы привести пример из реальной жизни:

[EDIT (Добавлен параметр из пути "Извините, я забыл")]

//----- 2) static approach ----------------------------
File.Copy(fromPath, toPath);    // .Net-Framework-like

[/РЕДАКТИРОВАТЬ]

но и:

//----- 1) non static approach ------------------------
ExampeFileClass fileObject = new ExampleFileClass();
fileObject.Copy(toPath);

или даже (вид OOP-Overkill):

//----- 1) non static approach, too -------------------
fileObject.ToPath = @"C:\Test\file.txt";     // property of fileObject
fileObject.Copy();                           // copy to toPath

Итак, почему (не) использовать 1) или почему (не) использовать 2)?

(Я бы не стал слишком концентрироваться на примере класса Document, так как это более общий вопрос о хорошем дизайне класса.)