Professional Web Applications Themes

using the "static" keyword to implement the Singleton pattern - PHP Development

To call I would do something like: $headline = McSelectJustOneField::callDatastore("cbHeadline"); Is this the correct use of the static keyword, to implement a Singleton design? class McSelectJustOneField extends McSelect { /** * 11-21-03 - getter * param - $infoToBeSought, in this case, is the name of the field whose contents are wanted. * returns mixed (could be string or integer or whatever was in the field) function static callDatastore($infoToBeSought) { $this->setQueryObject("GetJustOneField"); $this->setInfoToBeSought($infoToBeSought); $this->getInfo(); $row = $this->getRowAsArrayWithStringIndex($this->dsResultPointer); $field = $row[0]; return $field; } }...

  1. #1

    Default using the "static" keyword to implement the Singleton pattern

    To call I would do something like:

    $headline = McSelectJustOneField::callDatastore("cbHeadline");



    Is this the correct use of the static keyword, to implement a
    Singleton design?



    class McSelectJustOneField extends McSelect {


    /**
    * 11-21-03 - getter
    * param - $infoToBeSought, in this case, is the name of the field
    whose contents are wanted.
    * returns mixed (could be string or integer or whatever was in the
    field)
    function static callDatastore($infoToBeSought) {
    $this->setQueryObject("GetJustOneField");
    $this->setInfoToBeSought($infoToBeSought);
    $this->getInfo();
    $row = $this->getRowAsArrayWithStringIndex($this->dsResultPointer);
    $field = $row[0];
    return $field;
    }

    }
    lawrence Guest

  2. #2

    Default Re: using the "static" keyword to implement the Singleton pattern

    With total disregard for any kind of safety measures
    [email]lkrubnergeocities.com[/email] (lawrence) leapt forth and uttered:
    > To call I would do something like:
    >
    > $headline = McSelectJustOneField::callDatastore("cbHeadline");
    >
    > Is this the correct use of the static keyword, to implement a
    > Singleton design?
    >
    Pretty much, regardless of whether you're using the Singleton
    pattern, you're still calling a static method. So the 'static'
    keyword is perfectly acceptable.

    You ARE using PHP5 I assume?

    --
    There is no signature.....
    Phil Roberts Guest

  3. #3

    Default Re: using the "static" keyword to implement the Singleton pattern

    With total disregard for any kind of safety measures
    [email]lkrubnergeocities.com[/email] (lawrence) leapt forth and uttered:
    > To call I would do something like:
    >
    > $headline = McSelectJustOneField::callDatastore("cbHeadline");
    > Is this the correct use of the static keyword, to implement a
    > Singleton design?
    >
    Actually, ignore my previous follow-up. No this is not correct. In
    PHP5 the correct usage is:

    <?php
    class Foo {
    public static function aStaticMethod() {
    // ...
    }
    }

    Foo::aStaticMethod();
    ?>

    But this is only available in PHP5


    --
    There is no signature.....
    Phil Roberts Guest

  4. #4

    Default Re: using the "static" keyword to implement the Singleton pattern

    With total disregard for any kind of safety measures
    [email]lkrubnergeocities.com[/email] (lawrence) leapt forth and uttered:
    > To call I would do something like:
    >
    > $headline = McSelectJustOneField::callDatastore("cbHeadline");
    >
    > Is this the correct use of the static keyword, to implement a
    > Singleton design?
    >
    P.P.S: (sorry, I'm a dumbass and my server doesn't refresh quick
    enough), the variable $this does not exist within static methods.

    --
    There is no signature.....
    Phil Roberts Guest

  5. #5

    Default Re: using the "static" keyword to implement the Singleton pattern

    Phil Roberts <philrobHOLYflatnet.net> wrote in message news:<Xns943CD207FECphilroberts206.127.4.22>...
    > With total disregard for any kind of safety measures
    > [email]lkrubnergeocities.com[/email] (lawrence) leapt forth and uttered:
    >
    > > To call I would do something like:
    > >
    > > $headline = McSelectJustOneField::callDatastore("cbHeadline");
    > >
    > > Is this the correct use of the static keyword, to implement a
    > > Singleton design?
    > >
    >
    > Pretty much, regardless of whether you're using the Singleton
    > pattern, you're still calling a static method. So the 'static'
    > keyword is perfectly acceptable.
    >
    > You ARE using PHP5 I assume?

    No, sorry, I'm not using PHP 5. I'm trying to make this work in PHP 4.
    lawrence Guest

  6. #6

    Default Re: using the "static" keyword to implement the Singleton pattern

    Phil Roberts <philrobHOLYflatnet.net> wrote in message news:<Xns943C1736FFBphilroberts206.127.4.22>...
    > With total disregard for any kind of safety measures
    > [email]lkrubnergeocities.com[/email] (lawrence) leapt forth and uttered:
    >
    > > To call I would do something like:
    > >
    > > $headline = McSelectJustOneField::callDatastore("cbHeadline");
    > >
    > > Is this the correct use of the static keyword, to implement a
    > > Singleton design?
    > >
    >
    > P.P.S: (sorry, I'm a dumbass and my server doesn't refresh quick
    > enough), the variable $this does not exist within static methods.

    Actually, I'm using the static keyword all wrong. I looked up an old
    example that I had almost forgotten. Thank god for Google. This is
    what someone suggested to me 8 months ago. I didn't understand it at
    the time, but now that I look at it, I realize static is being used
    here in a clever way, to get around the limitations of PHP 4.


    >> All this data should only reference one single object. Having only
    one
    >> Object (called Singleton Pattern) can be done by a Mediator
    (Pattern).
    >>
    >> A mediator looks basically like this:
    >>
    >> class mediator{
    >>
    >> function &instance(){
    >>
    >> static $instance;
    >> if (!isset($instance)){
    >> $instance = new object;
    >> }
    >>
    >> return $instance;
    >> }
    >> }
    >>
    >> Which should be referenced absolutely everywhere by
    >>
    >> $ins =& mediator::instance();
    >>
    >> You will then have exactly one object always. Also, you can get rid
    of
    >> all global statements with this.
    >
    >Brilliant.
    lawrence Guest

  7. #7

    Default Re: using the "static" keyword to implement the Singleton pattern

    Hi !

    (...)
    >
    >Actually, I'm using the static keyword all wrong. I looked up an old
    >example that I had almost forgotten. Thank god for Google. This is
    >what someone suggested to me 8 months ago.
    wasn't that long ago.

    Jochen
    --
    Jochen Daum - CANS Ltd.
    PHP DB Edit Toolkit -- PHP scripts for building
    database editing interfaces.
    [url]http://sourceforge.net/projects/phpdbedittk/[/url]
    Jochen Daum Guest

  8. #8

    Default Re: using the "static" keyword to implement the Singleton pattern

    Hi...

    lawrence wrote: 

    Why do you need a singleton? Singletons are only a short step up from
    globals in causing trouble. They are a right royal pain when testing as
    one test can influence another. I wrote an article on the PHP Patterns
    site (http://www.phppatterns.com/) on how to get around this issue, and
    it involves some serious extra work.

    Can you do without it or are you just trying it out as a learning exercise?

    yours, Marcus
    --
    Marcus Baker, com, demon.co.uk

    Marcus Guest

  9. #9

    Default Re: using the "static" keyword to implement the Singleton pattern

    Marcus Baker wrote:
     

    Singletons IMHO avoid the major drawbacks of global objects (which is
    the motivation for the pattern if I remember right). They initialize
    themselves when first used and they can't be deleted or overwritten by
    accident.
     

    That depends on the design of your classes and your tests. I usually use
    a Factory Method in the client object to get the singleton instance. For
    testing I swap that Factory Method out against one that returns a mock
    of the Singleton. (I use your Partial Mocks for that.)

    Having Singletons carry data that changes after initialization to
    reflect the state of the application is indeed problematic, because it
    leeds to temporal coupling, which is near impossible to test well. I use
    Singletons mainly for "stateless" things that don't change after
    initialization. A database connection is a prime example.

    Jochen

    Jochen Guest

  10. #10

    Default Re: using the "static" keyword to implement the Singleton pattern

    Marcus Baker <com> wrote in message news:<com>... 
    >
    > Why do you need a singleton? Singletons are only a short step up from
    > globals in causing trouble. They are a right royal pain when testing as
    > one test can influence another. I wrote an article on the PHP Patterns
    > site (http://www.phppatterns.com/) on how to get around this issue, and
    > it involves some serious extra work.[/ref]

    Can you give a more specific link? Your article is no longer on the
    front page. I'd like to read it over.
    lawrence Guest

  11. #11

    Default Re: using the "static" keyword to implement the Singleton pattern

    Marcus Baker <com> wrote in message news:<com>... 
    >
    > Why do you need a singleton? Singletons are only a short step up from
    > globals in causing trouble. They are a right royal pain when testing as
    > one test can influence another. I wrote an article on the PHP Patterns
    > site (http://www.phppatterns.com/) on how to get around this issue, and
    > it involves some serious extra work.[/ref]

    What I wanted to do was this:

    $headline = McSelectJustOneField::callDatastore("cbHeadline");

    I want this mostly for convenience. I do realize it is a bit like
    having a global function. I'm aware some people criticize this kind of
    thing in Java for being "not really OO". Damned convenient though.

    Point me to your article so I can get some sense of the downside.
    lawrence Guest

  12. #12

    Default Re: using the "static" keyword to implement the Singleton pattern

    lawrence wrote: 

    This doesn't really look like a singleton to me, but rather like a class
    with static methods. But then again I don't know what
    McSelectJustOneField looks like inside. Does callDatastore() return a
    reference to the singleton object? If it does what it looks like (return
    a string?) that's not a singleton by my book...
     

    The article is on phpclasses.com in the "Design" section, entitled
    "Singleton Registry". There's also an article about the Singleton
    pattern by Harry way down on the page. Read that one first to find out
    if what you're doing is really a singleton.

    Jochen

    Jochen Guest

  13. #13

    Default Re: using the "static" keyword to implement the Singleton pattern

    Hi...

    Jochen Buennagel wrote: 

    Well I wouldn't go so far as to say they are the end of the world, and
    they do solve the initialisation problem. I even have a couple in my
    current main app (don't tell anybody). The trouble is that they can get
    damaged by any part of the code. Also if you ship some with a library,
    because of the global scope they can affect any part of that library.
    This makes understanding things just a little bit harder. It's little
    bit less encapsulation.
     

    A factory is almost always a superior approach. This is not so much a
    singleton though, as you have to get access to the holding class to call
    the factory method and, as you say, that can be mocked or switched by
    subclassing. I am not against a cached instance. That is just normal
    coding. It's the static global access and single instance in combination.

    Actually I am going off of static methods as well, but that's another
    story :).
     

    That is a common one; PEAR uses it for example. In my current main job
    (Wordtracker) we have one for the SessionPool (for PHP $_SESSION handler
    access) and a Registry class (not surprisingly). That is just under 1%
    of the total number of classes. When I see half a dozen in an
    application I see it as a symptom of possible problems.

    One that has caused me particular problems in the past is some kind of
    Singleton "Auth" class. It often means you have to log in just to run
    your tests. Given that such a class exists pretty near the top of the
    application hierarchy (unlike a database connection) there really is no
    excuse for not passing the object as a parameter.
     

    yours, Marcus

    p.s. I'll try to do some PHP::Duploc work this holiday. Not finding much
    time right now.
    --
    Marcus Baker, com, demon.co.uk

    Marcus Guest

  14. #14

    Default Re: using the "static" keyword to implement the Singleton pattern

    Marcus Baker wrote: 
    >
    > A factory is almost always a superior approach. This is not so much a
    > singleton though, as you have to get access to the holding class to call
    > the factory method and, as you say, that can be mocked or switched by
    > subclassing.[/ref]

    No, I didn't mean a factory class that returns the singleton. The
    factory method in the client object is usually private, and fetches the
    singleton only for internal use by the class. If I don't discard it
    right after use, the member variable that holds it is privat too.
     

    Funny: We have a Auth object that gets created on every page and passed
    into every object, even though there are cirstances where it will not
    be used at all. I'm now trying to convince my team that we should turn
    it into a singleton, so it will be initialized only when actually
    needed. (Auth is expensive, as our application authenticates against a
    remote SOAP service.)

    Jochen

    Jochen Guest

  15. #15

    Default Re: using the "static" keyword to implement the Singleton pattern

    Hi Jochen.

    Jochen BŁnnagel wrote: 

    No I meant factory in that sense too. To me a Singleton is a single
    instance with global access. If you can make the access non-global, you
    are in the clear in my book. I would call what you are doing as caching.
     

    Sods law you would be doing just that :).

    If efficiency is a concern you could either lazy proxy the class or the
    resources in it. The most highly factored approach would be to have a
    separate Authoriser and Authorisation. The Authoriser::login method is a
    factory for the Authorisation here. I am a big fan of factory methods
    and factory classes if you haven't already guessed.

    I read somewhere that it is advisable to separate authentication
    (identifying the user) from authorisation (handing them a set of
    permissions), but I haven't yet needed that level of sophistication.
     

    yours, Marcus
    --
    Marcus Baker, com, demon.co.uk

    Marcus Guest

Similar Threads

  1. How to implement "PostRender" event for Controls
    By DC in forum ASP.NET Building Controls
    Replies: 2
    Last Post: October 11th, 11:54 AM
  2. "Pattern" or "best practice" in security checks
    By Anders K. Jacobsen [DK] in forum ASP.NET Security
    Replies: 0
    Last Post: December 5th, 07:31 PM
  3. How to implement Drop down list in "properties" box?
    By Oleg Slyuasrchuk in forum ASP.NET Building Controls
    Replies: 2
    Last Post: December 12th, 08:54 PM
  4. Replies: 0
    Last Post: July 18th, 11:51 PM
  5. Replies: 0
    Last Post: July 10th, 10:51 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139