Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.
Chris Corbyn wrote:Too true! I'm sure you still use singletons at times (do you?)... I know I do. I always question my reasoning when I do though I'm also a lazy programmer... duh duh daahhhh!
I have used Singleton a couple of times. Every time the problem I was having was that (in code I considered properly designed) at some point in the code I was getting the wrong instance of an object -- typically an uninitialized one. By that I mean that it was just too difficult to inject the object to the right spots in the program where it was needed due to the (what I thought necessary) rest of the design requirements of the app. Using a Singleton may have been necessary or it may have been my lack of design skills -- I suspect the latter.
As I said, I think 99% of the time programmers use Singleton because they want the shortcut convenience of using a global, but want to reduce some of the side-effects. Singleton is the clever programmer's feel-good global var. Nothing wrong with that as long as you are honest with yourself.
So, in you opinion, implementing the second "pattern" I've posted it's completely silly, or not?
I think neither is a good direction to go. I would recommend trying to use a regular object that has a property to hold the connection resource. Pass it in. Or make it accessible with a Registry if you are really having a problem with multiple connections being created.
arborint wrote: Singleton is the clever programmer's feel-good global var. Nothing wrong with that as long as you are honest with yourself.
True that, once you understand the "rules" & understand why they exist you can make educated decisions about your design. If you feel uneasy / aren't sure it may be a sign you have more understanding to do, so in that case either avoid it altogether or if you want to learn 'when' to use the pattern pick up a design book, best advice I can give
= odino = wrote:I think that probably script's security is involved...
I do not know much about OOP practises, but I must say that singletons are, as the name suggests, objects that may be initialized (or instantialized, which ever is the correct word) once only. There is no security involved. Performance is one thing that is involved. Singletons consume more RAM and drop the performance, but on the other hand they may increase performance (e.g. not allowing multiple database connections). Think twice when implementing singletons. Database class is definitely one place to use singletons, in my opinion.
kaisellgren wrote:Database class is definitely one place to use singletons, in my opinion.
I haven't had any problems passing around my database connection, often in a (not singleton) registry.
You are not using a singleton design pattern for the database class?
Database is often the slowest node of the chain. Having a singleton effectively makes sure no one will ever establish multinuous connection to the database.
I have to disagree. I wrote a framework consisting of nothing BUT singletons. The performance was insane. Memory usage was very low and it was incredibly fast.
I have to disagree. I wrote a framework consisting of nothing BUT singletons. The performance was insane. Memory usage was very low and it was incredibly fast.
I guess your taste of high performance is different
The framework was built in such a way that each class represented an action rather than an object. It's unconventional. I don't use it anymore but the performance was great. Maybe in the future I will work on it more and implement MVC into it.
Anyway, I was just pointing out that performance wise, it was hella fast.
kaisellgren wrote:Having a singleton effectively makes sure no one will ever establish multinuous connection to the database.
That is true, but why would you want to write a database library that can't support multiple connections. For example one adapater for writes and another for reads, in a master-slave replication setup