title: Why is singleton so bad in a PHP environment?
body: <blockquote>
    <p><strong>Possible Duplicate:</strong><br>
    <a href="https://stackoverflow.com/questions/4595964/who-needs-singletons">Who needs singletons?</a>  </p>
  </blockquote>
  
  
  
  <p>i was wondering, what are the drawbacks using Singletons in php scripts. I use them alot and i sometimes can't understand criticism of developers. Some examples:</p>
  
  <p><strong>I have a Request class:</strong> </p>
  
  <p>Sanitizing POST, GET, COOKIE inputdata and using it instead of the global arrays - strictly and globally. Like</p>
  
  <pre><code>$request = Request::getInstance();
  $firstname = $request-&gt;post('firstname', $additionalFilters);
  </code></pre>
  
  <p>There is always only ONE request per request. Why is using singleton in this case a bad idea?</p>
  
  <p><strong>Same for $_SESSION:</strong> </p>
  
  <p>I have a Session class (Singleton) which does represent the $_SESSION array because there is only one session and i use it globally.</p>
  
  <p><strong>Database</strong></p>
  
  <pre><code>$mysql  = DB::getInstance('mysql', 'dbname'); //pseudo
  $sqlite = DB::getInstance('sqlite', 'dbname'); //pseudo
  </code></pre>
  
  <p>For each type of database, i want only ONE object and never MORE. In my opinion there is otherwise a risk of chaos. </p>
  
  <p><strong>Unique rows</strong></p>
  
  <p>Also i often use classes to represent/use a unique row of a db table.</p>
  
  <pre><code>$article = Article::getInstance($id);
  $navigation = Navigation::getInstance($id);
  </code></pre>
  
  <p>I see only benefits doing it this way. I never want a second object representing a unique row. Why is singleton such a bad idea here?</p>
  
  <p>In fact, most (nearly all) my classes   don't have a public constructor but always a static method like getInstance($id) or create() so the class itself handles the possible instances (which doesn't mean they are all singletons by definition)</p>
  
  <p>So my question is: Are there any drawbacks i didn't realize yet. And which concrete scenario's the singleton-doubters thinking of when advise against Singletons. </p>
  
  <p><strong>Edit:</strong></p>
  
  <blockquote>
    <p>Now, you got a singleton that wraps around the $_POST, but what if you
    don't have $_POST, but want to use a file for input instead? In that
    case, it would be more convenient if you have an abstract input class,
    and instantiate a POSTInput to manage input through posted data.</p>
  </blockquote>
  
  <p>Ok, valid advantages. I didn't realized that. Especially the point regarding the Request class.</p>
  
  <p>Still i have doubts whether that approach. Assume i have a "Functionality" class which executes a concrete request (like a guestbook component). 
  Within that class i want to get a sent parameter. So i get my singleton instance of Request </p>
  
  <pre><code>$req = Request::getInstance(); 
  $message = $req-&gt;post('message');
  </code></pre>
  
  <p>This way, only my functionality object cares about a Request class. </p>
  
  <p>When i use the non-singleton approach, i need somehow an additional class/function  to manage that every request gets a valid request object. That way my Functionality class doesn't need to know about that managing class but in my opinion there still arises a dependence/problem: Everytime i create an instace of an Functionality object there is a chance that i forget to set a request object. </p>
  
  <p>Surely i can define a non-optional parameter when creating a functionality. But that leads to a parameter overkill altogether at some time. Or not?</p>