[Editar

Minha pergunta original era "Por que decidir entre estático e não estático? Ambos fazem o mesmo ..."

Infelizmente, foi editado para uma pergunta específica em C # o que eu realmente queria evita

Então, deixe-me fazer algumas adições:

Quando digo interface, não me refiro à interface de palavras-chave em C #, mas ao que entendo algo como uma interface em C ++: um conjunto de funções bem definidas para operar com meu objeto. Ao dizer enfraquecer minha interface, quero dizer que tenho funções diferentes (estáticas / não estáticas) que fazem a mesma coisa. Minha interface não está mais bem definida quando há funções diferentes para fazer a mesma cois

ntão, como Bob o zelador postou, eu posso implementar uma função Validate () -

Document.Validate(myDocumentObject);    

mas també

myConcreteDocumentObject.Validate();

Para voltar ao meu Copy () - exemplo, poderia-se implementar Copy () como

myConcreteDocument.Copy(toPath);

mas també

Document.Copy(myConcreteDocumentObject, toPath)

o

Document.Copy(fromPath, toPath)

quando penso em uma pasta que contém todos os arquivos pertencentes ao meu documento (neste caso, não sou dependente de uma instância concreta - mas sou dependente de outras coisas:)

Em geral, estou falando de métodos estáticos e não de classes estáticas (desculpe, se eu esqueci a menstruação

Mas como Anton Gogolev disse que acho que minha classe Document não é um bom exemplo e não é bem projetada, então acho que terei que dar uma olhada no Princípio de Responsabilidade Únic

Eu também poderia implementar algum tipo de ManagerClass que opera com o meu DocumentClass:

Por exemplo

myDocumentManagerObject.Copy(myConcreteDocumentObject, toPath);

o

myDocumentManagerObject.Copy(myConcreteDocumentObject, toPath);

mas se eu me referir à abordagem 1) eu tenderia a criar objetos que executam suas tarefas por si mesmos, em vez de outros objetos (DocumentManager) que fazem algoco meu DocumentObject.

(Espero que isso não leve a direção de uma discussão religiosa sobre OOP;).)

[/EDITAR

Versão antiga

No começo, isso parece ser uma pergunta muito básica, como "quando usar métodos estáticos e quando não", mas isso é algo que sou confrontado de vez em quando (e tenho dificuldades para descrever qual é o verdadeiro problema; talvez seja apenas para obter razões pelas quais (não) use 1) ou porque (não) use 2)).

(Embora eu esteja usando sintaxe C #, este não é um problema restrito em C #)

o POO existem duas abordagens (entre outras) de trabalho com objeto

1) Se eu quiser que meu objeto faça alguma coisa, basta que ele faça:

myConcreteObject.DoSomething();

É como falar com um objeto.

2) Ou se você é fã de métodos estáticos:

ObjectClass.JustDoIt();

De alguma forma, acho que as funções estáticas apenas "se sentem" melhor. Portanto, costumo usar métodos estáticos com muita frequência (para ser independente de uma instância concreta - a independência é sempre uma coisa boa

ntão, ao projetar uma classe, muitas vezes tenho que decidir se adotar a abordagem 1) ou a abordagem 2

Imagine que você tem uma classe "Documento" que deve representar um documento que deve ser salvo em um banco de dados:

Um document

onsiste em um ou mais arquivos de imagem do sistema de arquivos (eles se tornam as páginas únicas do document tem algo como uma bibliografia - campos aos quais o usuário pode adicionar informações sobre o documento - que são salvas em um arquivo extra e deve ter algumas operações como Copy (), AddPage (), RemovePage () etc.

gora, sou confrontado com várias maneiras de criar esta class

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

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

Eu gosto disso: digo ao documento para se copiar no banco de dados xo objeto faz isso sozinho. Agradável

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

Por que não? Também é bom, é muito útil ...

Então, qual implementar? Ambos? Ou colocando a abordagem estática em um tipo de classe auxiliar? Ou escolha a abordagem 1) e continue com ela para não enfraquecer a interface da minha classe Documen

uando pensamos em ambas as abordagens, chego à conclusão de que (em teoria) alguém poderia implementar qualquer função como uma função estátic

Class.Function(aConcreteClassObject, parameters);

mas também não estático:

aConcreteObject.DoSomething(parameters);

Para dar um exemplo do mundo real:

[EDIT (Adicionado parâmetro de Path "Desculpe, esqueci")]

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

[/EDITAR

mas também

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

ou mesmo (tipo de OOP-Overkill):

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

Então, por que (não) usar 1) ou por que (não) usar 2

(Eu não me concentraria muito no exemplo da classe Document, pois é mais uma pergunta geral sobre o bom design da classe.)