title: How to decide between C# static and non-static methods?
body: <p>[Edit]</p>
  
  <p>My original-question was "Why to decide between static and non-static? Both do the same..."</p>
  
  <p>Unfortunately it was edited to a C#-specific question what I really wanted to avoid.</p>
  
  <p>So, let me do some additions:</p>
  
  <p>When I say interface, I don't mean the C#-keyword-interface but what I understand something like a C++-interface: A set of well defined functions to operate with my object.
  When saying weaken my interface, I mean I have different functions (static/non-static) that do the same thing. My interface is not well defined anymore when there are different functions to do the same thing.</p>
  
  <p>So, as Bob the Janitor posted, I can implement a Validate()-function</p>
  
  <pre><code>Document.Validate(myDocumentObject);    
  </code></pre>
  
  <p>but also</p>
  
  <pre><code>myConcreteDocumentObject.Validate();
  </code></pre>
  
  <p>To get back to my Copy()-example one could implement Copy() like</p>
  
  <pre><code>myConcreteDocument.Copy(toPath);
  </code></pre>
  
  <p>but also</p>
  
  <pre><code>Document.Copy(myConcreteDocumentObject, toPath)
  </code></pre>
  
  <p>or</p>
  
  <pre><code>Document.Copy(fromPath, toPath)
  </code></pre>
  
  <p>when I think of a folder that contains all the files belonging to my Document (in this case I'm not dependent of a concrete instance - but I'm dependent from other things :)).</p>
  
  <p>In general I'm talking about static methods not static classes (sorry, if I forgot to mension).</p>
  
  <p>But as Anton Gogolev said I think my Document class is not a good example and not well designed so I think I will have to have a look at the Single Responsibility Principle.</p>
  
  <p>I could also implement some kind of ManagerClass that operates with my DocumentClass:</p>
  
  <p>For example:</p>
  
  <pre><code>myDocumentManagerObject.Copy(myConcreteDocumentObject, toPath);
  </code></pre>
  
  <p>or</p>
  
  <pre><code>myDocumentManagerObject.Copy(myConcreteDocumentObject, toPath);
  </code></pre>
  
  <p>but if I refer to approach 1) I would tend to create objects that perform their tasks by themself rather than other objects (DocumentManager) that do something <em>with</em> my DocumentObject.</p>
  
  <p>(I hope this will not take the direction of a religious discussion about OOP ;).)</p>
  
  <p>[/EDIT]</p>
  
  <hr>
  
  <h2>Old Version:</h2>
  
  <p>At first this seems to be a very basic question like "when to use static methods and when not" but this is something I'm confronted every now and then (and I have difficulties to describe what the real problem is; perhaps it's just to get reasons why (not) to use 1) or why (not) to use 2)).</p>
  
  <p>(Although I'm using C#-Syntax this is not a C#-restricted problem)</p>
  
  <p>In OOP there are two approaches (amongst others) of working with objects:</p>
  
  <p>1) If I want my object to do something, I just tell him to do so:</p>
  
  <pre><code>myConcreteObject.DoSomething();
  </code></pre>
  
  <p>It's just like talking to an object.</p>
  
  <p>2) Or if you're a fan of static methods:</p>
  
  <pre><code>ObjectClass.JustDoIt();
  </code></pre>
  
  <p>In some way I think static functions just "feel" better. So I tend to use static methods very often (to be independent from a concrete instance - independency is always good thing).</p>
  
  <p>So, when designing a class I often have to decide if I take approach 1) or approach 2):</p>
  
  <p>Imagine you have a class "Document" which should stand for a document that should be saved into a database:</p>
  
  <p>A Document</p>
  
  <ul>
  <li>consists of one or more image files from filesystem (these become the single document pages)</li>
  <li>has something like a bibliography - fields the user can add information about the document to - which is saved to an extra file</li>
  <li>and should have some operations like Copy(), AddPage(), RemovePage() etc.</li>
  </ul>
  
  <p>Now I'm confrontated with several ways to create this class:</p>
  
  <pre><code>//----- 1) non static approach/talking to objects -----
  Document newDocument = new Document();
  
  // Copy document to x (another database, for example)
  newDocument.Copy(toPath);
  </code></pre>
  
  <p>I like this: I tell the document to copy itself to database x and the object does so by itself. Nice.</p>
  
  <pre><code>//----- 2) static approach ----------------------------
  Document.Copy(myDocumentObject, toPath);
  </code></pre>
  
  <p>Why not? Also nice, feels very handy...</p>
  
  <p>So, which one to implement? Both? Or putting the static approach to a kind of helper class? Or choose approach 1) and stick with it to not weaken the interface of my Document-class?</p>
  
  <p>When thinking about both approaches I come to the conclusion that (in theory) one could implement any function as a static function:</p>
  
  <pre><code>Class.Function(aConcreteClassObject, parameters);
  </code></pre>
  
  <p>but also non-static:</p>
  
  <pre><code>aConcreteObject.DoSomething(parameters);
  </code></pre>
  
  <p>To give a real-world example:</p>
  
  <p>[EDIT(Added parameter fromPath "Sorry, I forgot")]</p>
  
  <pre><code>//----- 2) static approach ----------------------------
  File.Copy(fromPath, toPath);    // .Net-Framework-like
  </code></pre>
  
  <p>[/EDIT]</p>
  
  <p>but also:</p>
  
  <pre><code>//----- 1) non static approach ------------------------
  ExampeFileClass fileObject = new ExampleFileClass();
  fileObject.Copy(toPath);
  </code></pre>
  
  <p>or even (kind of OOP-Overkill):</p>
  
  <pre><code>//----- 1) non static approach, too -------------------
  fileObject.ToPath = @"C:\Test\file.txt";     // property of fileObject
  fileObject.Copy();                           // copy to toPath
  </code></pre>
  
  <p>So, why (not) to use 1) or why (not) to use 2)?</p>
  
  <p>(I would not concentrate on the Document class example too much, since it's more a general question about good class design.)</p>