Re: static constructor
| From: | Rowan Collins | Date: | Fri, 13 Mar 2015 11:53:24 +0000 |
| Subject: | Re: static constructor | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-84676@lists.php.net to get a copy of this message | ||
Johannes Ott wrote on 13/03/2015 09:53:
Am 13.03.2015 um 01:33 schrieb Christoph Becker:Complex data structures, yes (and I see the use of __static in such cases). Architectural logic gluing one class to another (as in your Logger example), no.Johannes Ott wrote:I really do not understand why everybody here seems to try to use Singleton where ever it is possible. Indeed Singletons are a nice Design Pattern, but they are no universal remedy for every problem just for the fact you can use it there as well. Why are in your opinion static members are not allowed to hold more complexe datastructures then simple scalars?And i although see no DI or Singleton pattern to use here to get the same functionality, if you want to use like Config::getHostname() and not like Config::getInstance()->getHostname() which is really unnecessary abstraction level for nothing in my opinion!It is possible, however, to add static wrapper methods to access the singleton's methods, like public static function getHostname() {return self::getInstance()->_getHostname();}
Please give me one valid argument why I should double all of the functions in my code for a static and non-static access beside the argument that I "have to" use a Singleton.You don't need to double all the calls. In fact, the majority of your code should not even know the Singleton is there, because they should be treating it as though they have an instance. At certain key points in your code (constructors, the top of methods) you add $foo = Foo::getInstance();, then all your calls look like $foo->doBar(); That's the way I do it, anyway - treat getting the instance for a singleton like importing a variable from global scope, which is basically what it's doing. Regards, -- Rowan Collins [IMSoP]