[изменить]
Мой оригинальный вопрос: "Зачем выбирать между статическими и нестационарными? Оба делают то же самое..."
К сожалению, он был отредактирован на вопрос, связанный с С#, чего я действительно хотел избежать.
Итак, позвольте мне сделать несколько дополнений:
Когда я говорю интерфейс, я не имею в виду интерфейс С# -keyword, но я понимаю что-то вроде С++-интерфейса: набор хорошо определенных функций для работы с моим объектом. Когда я говорю об ослаблении интерфейса, я имею в виду, что у меня разные функции (статические/нестатические), которые делают то же самое. Мой интерфейс больше не определен, когда есть разные функции, чтобы сделать то же самое.
Итак, как написал Bob Janitor, я могу реализовать функцию Validate() -
Document.Validate(myDocumentObject);
но также
myConcreteDocumentObject.Validate();
Чтобы вернуться к моему экземпляру Copy(), можно реализовать Copy(), например
myConcreteDocument.Copy(toPath);
но также
Document.Copy(myConcreteDocumentObject, toPath)
или
Document.Copy(fromPath, toPath)
когда я думаю о папке, содержащей все файлы, принадлежащие моему документу (в этом случае я не зависим от конкретного экземпляра, но я зависим от других вещей:)).
В общем, я говорю о статических методах, а не статических классах (извините, если я забыл растянуть).
Но, как сказал Антон Гоголев, я считаю, что мой класс Document не является хорошим примером и не очень хорошо разработан, поэтому я думаю, что мне нужно взглянуть на принцип единой ответственности.
Я мог бы также реализовать какой-то менеджер ClassClass, который работает с моим DocumentClass:
Например:
myDocumentManagerObject.Copy(myConcreteDocumentObject, toPath);
или
myDocumentManagerObject.Copy(myConcreteDocumentObject, toPath);
но если я обращусь к подходу 1), я бы хотел создавать объекты, которые выполняют свои задачи сами, а не другие объекты (DocumentManager), которые что-то делают с моим DocumentObject.
(Я надеюсь, что это не будет направлено на религиозную дискуссию об ООП;).
[/EDIT]
Старая версия:
Сначала это, по-видимому, очень простой вопрос, как "когда использовать статические методы и когда нет", но это то, с чем я сталкиваюсь время от времени (и мне сложно описать, какова реальная проблема; это просто чтобы получить причины, почему (не) использовать 1) или почему (не) использовать 2)).
(Хотя я использую С# -Syntax, это не проблема с С#)
В ООП существуют два подхода (среди прочих) работы с объектами:
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) и придерживайтесь его, чтобы не ослабить интерфейс моего документа-класса?
При обсуждении обоих подходов я пришел к выводу, что (теоретически) можно реализовать любую функцию как статическую функцию:
Class.Function(aConcreteClassObject, parameters);
но также нестатический:
aConcreteObject.DoSomething(parameters);
Чтобы дать реальный пример:
[EDIT (добавлен параметр fromPath "Извините, я забыл" )]
//----- 2) static approach ----------------------------
File.Copy(fromPath, toPath); // .Net-Framework-like
[/EDIT]
но также:
//----- 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, так как это более общий вопрос о хорошем дизайне классов.)