SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 52

Hybrid View

  1. #1
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    When (if at all) to use static methods [new thread split off from frameworks]

    Quote Originally Posted by bhanson View Post
    Static methods should be used where ever possible as a good coding practice.
    Seriously?

  2. #2
    Use The Cloud
    Join Date
    Jan 2006
    Location
    Boise, ID
    Posts
    556
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by allspiritseve View Post
    Seriously?
    IIRC, they're about 4 times faster when declared static.

    If you don't need an instance of the object for the method to work then it should be declared static.
    Brad Hanson, Web Applications & Scalability Specialist
    ► Is your website outgrowing its current hosting solution?
    ► PM me for a FREE scalability consult!
    ► USA Based: Available by Phone, Skype, AIM, and E-mail.

  3. #3
    SitePoint Addict
    Join Date
    Feb 2007
    Posts
    251
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by bhanson View Post
    IIRC, they're about 4 times faster when declared static.

    If you don't need an instance of the object for the method to work then it should be declared static.
    Premature optimization is the root of all evil? Trading a solid OO design for a little performance gain is definitely not a good idea.

    However, I think it's okay as a rule of thumb if you're using PHP's OO features as a ghetto namespace/autoload mechanism for procedural code.

  4. #4
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by bhanson View Post
    Static methods should be used where ever possible as a good coding practice.


    Er...I think you had better explain that further.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  5. #5
    Use The Cloud
    Join Date
    Jan 2006
    Location
    Boise, ID
    Posts
    556
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft View Post
    Hi...





    Er...I think you had better explain that further.

    yours, Marcus
    It can be summed up in one simple guideline:

    If a method in your class can be declared statically, then it is probably right to do so.
    Static methods are usually very general operations that apply to the entire class. They don't need an instance of the object to function and it is pointless to require one.

    A very obvious example:

    PHP Code:
    class Test
    {
        public static function 
    factory($adapterName)
        {
            
    // ...
        
    }   
    }   

    $foo Test::factory('foo'); 
    PHP Code:
    class Test
    {
        public function 
    factory($adapterName)
        {
            
    // ...
        
    }
    }

    $test = new Test(); // ??
    $foo $test->factory('foo'); 
    Brad Hanson, Web Applications & Scalability Specialist
    ► Is your website outgrowing its current hosting solution?
    ► PM me for a FREE scalability consult!
    ► USA Based: Available by Phone, Skype, AIM, and E-mail.

  6. #6
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi..

    Quote Originally Posted by bhanson View Post
    It can be summed up in one simple guideline:
    That's just a restatement of an assertion. Why not just use the new operator?

    Quote Originally Posted by bhanson View Post
    Static methods are usually very general operations that apply to the entire class. They don't need an instance of the object to function and it is pointless to require one.
    That doesn't make them desirable. You are basically using the class as a namespace. The class already has a job to do and you've given it another one. This tension will often cause a refactoring down the line.

    PEAR caught the static method disease as a namespacing tactic, and to emulate some shortcomings in PHP4 (PEAR Error -- arghh!). It seems to have carried itself over to Zend. You've rather put me off the the Zend framework if that's really the case.

    Quote Originally Posted by bhanson View Post
    A very obvious example:
    A factory is an obvious example, but actually a poor one. The problem is that you've take a snapshot from a continuum of options:

    1) new operator
    2) Static call or global function call
    3) Factory method on another class
    4) Specialist factory class (Builder, AbstractFactory, Repository)
    5) Registry
    6) ServiceLocator
    7) DependencyInjection

    You only actually "need" option 2 over option 1 if you've too many parameter choices to the new operator, and so need multiple constructors. At that point the decision as to which constructor to use should probably have been made higher up, probably in configuring the application. It's unlikely that enough information is known locally unless it's the top level script. You probably already want option 4 at the very least.

    A static factory method is an intermediate option, and frankly a bit scripty. Certainly not "Enterprise". My real gripe with it though, is not as a design choice, but as a coding one.

    Everywhere you make that static call in this way, you've hard coded the object that will be created. At the very least, it will make testing a pain. In most cases the damage will be worse, and these calls will hinder refactoring to a more flexible pattern where objects are passed in. Creating objects is an important job and something should have responsibility for it. It shouldn't be strewn all over the code. This is why we dumped Singletons.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  7. #7
    Use The Cloud
    Join Date
    Jan 2006
    Location
    Boise, ID
    Posts
    556
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft View Post
    Hi..

    That's just a restatement of an assertion. Why not just use the new operator?
    Why force creation of an instance if it is not needed?

    Quote Originally Posted by lastcraft View Post
    That doesn't make them desirable. You are basically using the class as a namespace. The class already has a job to do and you've given it another one. This tension will often cause a refactoring down the line.
    Kind of a namespace, but that has improper connotations associated with it used in this context.

    Objects are basically models. These models sometimes need functionality directly associated with that type, but does not need an instance of the class to operate. It is in these cases where I am proposing they should be declared static. I do not see refactoring being a huge issue as unless that method's purpose and scope changes drastically, it should never need to be anything but static.


    Quote Originally Posted by lastcraft View Post
    PEAR caught the static method disease as a namespacing tactic, and to emulate some shortcomings in PHP4 (PEAR Error -- arghh!). It seems to have carried itself over to Zend. You've rather put me off the the Zend framework if that's really the case.



    A factory is an obvious example, but actually a poor one. The problem is that you've take a snapshot from a continuum of options:

    1) new operator
    2) Static call or global function call
    3) Factory method on another class
    4) Specialist factory class (Builder, AbstractFactory, Repository)
    5) Registry
    6) ServiceLocator
    7) DependencyInjection

    You only actually "need" option 2 over option 1 if you've too many parameter choices to the new operator, and so need multiple constructors. At that point the decision as to which constructor to use should probably have been made higher up, probably in configuring the application. It's unlikely that enough information is known locally unless it's the top level script. You probably already want option 4 at the very least.

    A static factory method is an intermediate option, and frankly a bit scripty. Certainly not "Enterprise". My real gripe with it though, is not as a design choice, but as a coding one.

    Everywhere you make that static call in this way, you've hard coded the object that will be created. At the very least, it will make testing a pain. In most cases the damage will be worse, and these calls will hinder refactoring to a more flexible pattern where objects are passed in. Creating objects is an important job and something should have responsibility for it. It shouldn't be strewn all over the code.
    Hard coded? The only thing you know for sure is that you will be getting back an instance of whatever type of object the factory returns to you, which is typically what you want. The specific type of object depends on the context from which it was called, as $adapterName is dynamic. How does this hinder passing objects in? The objects that would be incoming would either be derivatives of the factory or their children, in both cases I don't see an issue?


    Quote Originally Posted by lastcraft View Post
    This is why we dumped Singletons.

    yours, Marcus
    This comment has me intrigued, I must have missed the memo on foregoing Singletons. Do you completely exclude the pattern from all of your development? On what reasoning?
    Brad Hanson, Web Applications & Scalability Specialist
    ► Is your website outgrowing its current hosting solution?
    ► PM me for a FREE scalability consult!
    ► USA Based: Available by Phone, Skype, AIM, and E-mail.

  8. #8
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by bhanson View Post
    Why force creation of an instance if it is not needed?
    What compelling reason do you have not to, other than to save a line of code?

    If a method doesn't at all involve the properties or methods in a class, you should make it static. It just makes sense. If a method doesn't use those properties (directly or through another method), your method is not an OOP method and is rather a function and should be declared statically.
    Now, does that imply a singleton is necessary, or just hint that maybe you're still programming procedurally and need to rethink your design?

  9. #9
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    I agree completely with Brad on this one.

    If a method doesn't at all involve the properties or methods in a class, you should make it static. It just makes sense.

    People going on about keeping it real OOP - you are in fact missing the point of OOP entirely. OOP methods are based around the object's properties. If a method doesn't use those properties (directly or through another method), your method is not an OOP method and is rather a function and should be declared statically.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  10. #10
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    I'll make this my last comment on this thread, as the thread was about framework choices rather than an OO primer. I'm a terrible troll victim and so have to limit myself.

    Quote Originally Posted by arkinstall View Post
    If a method doesn't at all involve the properties or methods in a class, you should make it static. It just makes sense.
    If a method doesn't involve properties or methods in that class, what the heck is the method doing in that class? Move it to the caller.

    If it's duplicated in several client classes then you probably have a design problem. If it's so generic it still appears in several classes, and there is too much code to simply duplicate it (more than a one liner), you'll still probably want to have an instance. That way you can test the client code more easily.

    Quote Originally Posted by arkinstall View Post
    People going on about keeping it real OOP - you are in fact missing the point of OOP entirely.
    Uh huh...

    Quote Originally Posted by arkinstall View Post
    OOP methods are based around the object's properties. If a method doesn't use those properties (directly or through another method), your method is not an OOP method and is rather a function and should be declared statically.
    Besides the option of a free function, which loses the namespacing and it's "improper connotations" (uh?), the need for an object to have properties escapes me. I worry the "point of OO" is not widely known...

    1) From Gamma, Helm, Johnson, Vlissides we have AbstractFactory, Adapter, Bridge, Decorator, Facade, Proxy, Command and Strategy.
    2) From Eric Evans we have Services, Factories.
    3) From Rebecca Wirfs-Brock we have ServiceProvider, Coordinator, Interfacer.
    4) From Martin Fowler we have DependentMapping, Gateway, LayerSupertype, RemoteFacade, ServiceLayer, ServerStub.

    Quote Originally Posted by bhanson
    Do you completely exclude the pattern from all of your development?
    Yes.

    Quote Originally Posted by bhanson
    On what reasoning?
    Because every time in my life I've put one in, within 6 months I've had to take it out again.

    Google for "Singletons are Evil" for the full debate (long since over) or check out the 5 volume patterns catalogue edited by Kevlin Henney.

    Please guys...a lot of people read Sitepoint whilst trying to learn programming in general, and OO in particular on this forum. They need balanced advice based on experience and the existing good practice(*). They really don't need random assertions that static methods are a good thing (they are rare), or that only objects with properties are allowed (60% at most would be my rule of thumb). At least stick "IMO" at the front of it.

    yours, Marcus

    (*) 1) Design Patterns, 2) Domain Driven Design, 3) Object Design: Roles, Responsibilities and Collaborations, 4) Patterns of Enterprise Application Architecture.
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  11. #11
    Use The Cloud
    Join Date
    Jan 2006
    Location
    Boise, ID
    Posts
    556
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft View Post
    Yes.

    Because every time in my life I've put one in, within 6 months I've had to take it out again.

    Google for "Singletons are Evil" for the full debate (long since over) or check out the 5 volume patterns catalogue edited by Kevlin Henney.
    Why completely abstain from a design pattern because people like to misuse it? I agree people sometimes introduce errors when using the pattern, but it is hardly the fault of the methodology, but rather user error. Perhaps in the times you've implemented it you've fallen into the same lull for which you're arguing against?

    Quote Originally Posted by lastcraft View Post
    Please guys...a lot of people read Sitepoint whilst trying to learn programming in general, and OO in particular on this forum. They need balanced advice based on experience and the existing good practice(*). They really don't need random assertions that static methods are a good thing (they are rare), or that only objects with properties are allowed (60% at most would be my rule of thumb). At least stick "IMO" at the front of it.

    yours, Marcus

    (*) 1) Design Patterns, 2) Domain Driven Design, 3) Object Design: Roles, Responsibilities and Collaborations, 4) Patterns of Enterprise Application Architecture.
    You've yet to provide a valid argument on why static usage is bad. If a method doesn't belong in the class, that is an entirely different design issue which deserves separate attention. To me there is no "IMO" about it and to be completely honest, using static where possible seems like common sense. My argument was never that you should design around static methods but rather when a method's entire purpose can be defined statically (and that it belongs to that class), it should be, as a good design principle to not limit scope.

    This is not to say I am completely stubborn on the issue. If provided with a valid and well reasoned argument for which I have no rebuttal, then I will happily jump ship and admit fault. Until then, I have to assume that the knowledge I possess is always right until proven otherwise. Working on any other assumption is irresponsible and does nothing to promote the development of new ideas or to verify existing ones.
    Brad Hanson, Web Applications & Scalability Specialist
    ► Is your website outgrowing its current hosting solution?
    ► PM me for a FREE scalability consult!
    ► USA Based: Available by Phone, Skype, AIM, and E-mail.

  12. #12
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by bhanson View Post
    This comment has me intrigued, I must have missed the memo on foregoing Singletons. Do you completely exclude the pattern from all of your development? On what reasoning?
    http://steve.yegge.googlepages.com/s...sidered-stupid

    I wrote one too, but Steve Yegge is much more entertaining.

  13. #13
    SitePoint Enthusiast
    Join Date
    Apr 2007
    Posts
    63
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by allspiritseve
    What compelling reason do you have not to, other than to save a line of code?
    You don’t have to have a reason for not using something. If you don’t have a reason to use something, you just don’t use it.

  14. #14
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by LAMP View Post
    You donít have to have a reason for not using something. If you donít have a reason to use something, you just donít use it.
    Implementing a singleton is not "not using" anything... its a choice between two alternatives, and they both have their pros and cons. However, the person I made the reply to used the word "force" with instantiation, as if it were something to be avoided. If the sole reason for using a singleton is to not instantiate an object, I'm curious what the reasoning behind that decision is. If there wasn't a reason... did you flip a coin?

  15. #15
    SitePoint Addict Mastodont's Avatar
    Join Date
    Mar 2007
    Location
    Czech Republic
    Posts
    375
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Please differentiate between static methods and singletons.

  16. #16
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Mastodont View Post
    Please differentiate between static methods and singletons.
    I tend to band them together, but you're right in there being a difference between stateless static methods and those that implies some kind of (global) state, such as a singleton. The latter kind are bad for two reasons; They are static symbols and they are global variables. The former only scores on half of that. I still wouldn't use a static method save for a very few cases.

  17. #17
    SitePoint Enthusiast
    Join Date
    Mar 2005
    Posts
    94
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    declaring a method static removes advantages of object oriented behaviour
    like extensibility and interchangeability. what you gain is just convenience,
    imho.
    imagine 3rd party code in you application with few or many static
    methods (like Zend_Session). after a php upgrade a bug shows up
    in a static method and breaks your entire application. the only way
    to fix this, is to change all callers or the 3rd party code.
    both is ugly compared to a non static call which is fixable easily at
    a single entry point.
    it's just very hard to forecast what need to be changed, especially
    from the users point of view. wrapping md5() with a static call gives
    you (the library developer) flexibillity to easily change the hash
    algorithm but it'll probably be a problem for the library user.

  18. #18
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Now, does that imply a singleton is necessary, or just hint that maybe you're still programming procedurally and need to rethink your design?
    It implies that you need to rethink your design - but that's not the point. My point is that if a method doesn't involve the members of the object, it isn't a method and either shouldn't be in that class or should be declared static.

    But seriously, static doesn't mean singleton, and static most definitely isn't evil. If you look at the widely used libraries for fully OOP languages, you'll see static does have its place.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  19. #19
    SitePoint Wizard bronze trophy devbanana's Avatar
    Join Date
    Apr 2006
    Location
    Pennsylvania
    Posts
    1,736
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think of it like this. If a method needs to use instance data, then it is not static. Instance methods suggest that it is related to a specific object somehow.

    But what if a class can do something that is not related to a specific instance of it? The method only needs to act on the given arguments, and semantically has nothing to do with the object, but still falls under the responsibility of the class. I see nothing wrong with that.
    Laudetur Iesus Christus!
    Christ's Little Flock
    Jesus is the Good Shepherd

  20. #20
    SitePoint Addict webaddictz's Avatar
    Join Date
    Feb 2006
    Location
    Netherlands
    Posts
    295
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by devbanana View Post
    But what if a class can do something that is not related to a specific instance of it?
    Then you should wonder why you've put it in.

    Quote Originally Posted by devbanana View Post
    The method only needs to act on the given arguments, and semantically has nothing to do with the object, but still falls under the responsibility of the class. I see nothing wrong with that.
    Then you're not looking hard enough. There are numerous articles on the subject of static.

  21. #21
    SitePoint Addict Mastodont's Avatar
    Join Date
    Mar 2007
    Location
    Czech Republic
    Posts
    375
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    webaddictz
    Then you should wonder why you've put it in.

    What would you do in objects-only-language as Java?

    elias
    imagine 3rd party code in you application with few or many static methods (like Zend_Session). after a php upgrade a bug shows up in a static method and breaks your entire application. the only way to fix this, is to change all callers or the 3rd party code. both is ugly compared to a non static call which is fixable easily at a single entry point

    Do not understand. Buggy static method is to be changed in single point, body. Same applies to non-static code. Can you please elaborate on this?

  22. #22
    SitePoint Enthusiast
    Join Date
    Mar 2005
    Posts
    94
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Mastodont View Post
    Do not understand. Buggy static method is to be changed in single point, body. Same applies to non-static code. Can you please elaborate on this?
    you don't want to change the static method itself because its
    third party code. as of objects its easy to deal with it because
    you can easily extend or replace it.
    of course it is in a php world always possible to change third party
    code but it's a bad idea and not the idea of oop.

  23. #23
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Singletons are used for storing global state, and there is no need for them in languages that have a global scope, like PHP. Even in those that don't, it makes more sense to use an actual global state object as per Monostate pattern (in Python also known as Borg, as opposed to Highlander, which is their name for Singleton).

    In PHP, which does have a global scope, if it's necessary to have some global functionality I prefer to use global functions than global variables. So, instead of using the "global" keyword or $GLOBALS array, I have one or more global functions which return references to various "global" objects and data. This way, if something changes there is only one place to apply it to.

    In effect, this is exactly the same as using the Singleton pattern. An important point to consider is that most patterns were developed to resolve issues present in particular languages -- mainly C++ and Java -- and are inappropriate for some other languages. Singleton is one example, and standard Java dependency injection is another: often (though not always) there is no need in PHP for various factories and similar solutions when a simple "new $classname()" will suffice.

  24. #24
    Use The Cloud
    Join Date
    Jan 2006
    Location
    Boise, ID
    Posts
    556
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by allspiritseve View Post
    What compelling reason do you have not to, other than to save a line of code?

    Now, does that imply a singleton is necessary, or just hint that maybe you're still programming procedurally and need to rethink your design?
    It's about forcing you to do something for absolutely no good reason at all.

    How would you feel if PHP required you to prefix each variable with its type? It's a pointless exercise and requires extra code and overhead for no reason at all. This is exactly the same as not declaring static when possible.

    Quote Originally Posted by allspiritseve View Post
    Implementing a singleton is not "not using" anything... its a choice between two alternatives, and they both have their pros and cons. However, the person I made the reply to used the word "force" with instantiation, as if it were something to be avoided. If the sole reason for using a singleton is to not instantiate an object, I'm curious what the reasoning behind that decision is. If there wasn't a reason... did you flip a coin?
    The reasoning is you should not be "forced" to create an instance of the class for a method that doesn't need it. You can still execute a static method associated with an instance of the object. My point is you should not be forced to.

    It will still be correct in many cases to run the static method on an object, but when you fail to declare static you take the option away of not using the static reference anymore.

    So let me ask you, what reason do you have for forcing creation of an object for a method that has no need for it?

    Quote Originally Posted by elias View Post
    declaring a method static removes advantages of object oriented behaviour
    like extensibility and interchangeability. what you gain is just convenience,
    imho.
    imagine 3rd party code in you application with few or many static
    methods (like Zend_Session). after a php upgrade a bug shows up
    in a static method and breaks your entire application. the only way
    to fix this, is to change all callers or the 3rd party code.
    both is ugly compared to a non static call which is fixable easily at
    a single entry point.
    it's just very hard to forecast what need to be changed, especially
    from the users point of view. wrapping md5() with a static call gives
    you (the library developer) flexibillity to easily change the hash
    algorithm but it'll probably be a problem for the library user.
    See above, it takes away no such advantage.

    Quote Originally Posted by BerislavLopac View Post
    Singletons are used for storing global state, and there is no need for them in languages that have a global scope, like PHP. Even in those that don't, it makes more sense to use an actual global state object as per Monostate pattern (in Python also known as Borg, as opposed to Highlander, which is their name for Singleton).

    In PHP, which does have a global scope, if it's necessary to have some global functionality I prefer to use global functions than global variables. So, instead of using the "global" keyword or $GLOBALS array, I have one or more global functions which return references to various "global" objects and data. This way, if something changes there is only one place to apply it to.

    In effect, this is exactly the same as using the Singleton pattern. An important point to consider is that most patterns were developed to resolve issues present in particular languages -- mainly C++ and Java -- and are inappropriate for some other languages. Singleton is one example, and standard Java dependency injection is another: often (though not always) there is no need in PHP for various factories and similar solutions when a simple "new $classname()" will suffice.
    PHP has global scope, but it doesn't have namespaces. In PHP singletons help from trashing your global namespace.
    Brad Hanson, Web Applications & Scalability Specialist
    ► Is your website outgrowing its current hosting solution?
    ► PM me for a FREE scalability consult!
    ► USA Based: Available by Phone, Skype, AIM, and E-mail.

  25. #25
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by bhanson View Post
    PHP has global scope, but it doesn't have namespaces. In PHP singletons help from trashing your global namespace.
    Namespaces are overrated. What is the functional difference between, say, Namespace::function() and namespace_function()? I know that, with namespaces, you can declare the namespace you use and then call methods without declaring their namespace each time, but personally I'd always rather have the namespace explicit on each call.

    Also, OOP is all about behavior, which is implemented through instance method calls. As Marcus has said above, if method is generic enough that it doesn't use any of an instance's state, it really don't belong to that object. The point of OOP are objects -- as opposed to classes -- and their interaction; a few weeks working with Javascript will teach you that.


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
  •