SitePoint Sponsor

User Tag List

Page 2 of 4 FirstFirst 1234 LastLast
Results 26 to 50 of 79
  1. #26
    SitePoint Addict timvw's Avatar
    Join Date
    Jan 2005
    Location
    Belgium
    Posts
    354
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Meaby it's a time to write an article 'Programmers are evil'

    I can see why it's hard to write unit-tests for code that uses singletons (eg: DI) but i'm still not sure if we should blame the singleton pattern or unit-testing for this problem...
    (To me it seems to suggest that some 'units' can be larger than a single class...)

  2. #27
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have written about the Singleton in both books and presentations. There are clear advantages:

    easy global access
    assurance the object is already instanciated before use
    easy to understand implementation and forces

    The disadvantages are basically the same as almost any global variable, particularly the hard coupling and lack of testability.

    That third advantage really is a key for inclusion of the singleton in Design Pattern literature. For example, everyone understands the desire to get at the one database connection, and everyone can easily understand the half dozen lines of code it takes to implement the pattern. I does make for a gentle introduction to patterns, but as with any code, you have to weigh the advantages and the disadvantages when deciding to use anything in your code.
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  3. #28
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by d11wtq
    I think people will always at some point down the line find a way to make something "evil". Use it correctly and it's fine.
    What did you think of the testing argument? How would you unit test that?

  4. #29
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The curious thing is - it's actually easier to replace a global than it is to replace a Singleton. I don't think globals, when used sparingly and acknowledgingly, are necessary a bad thing. But if you intend on testing - Singletons quite certainly are.

    Just to be overly verbose, compare these to:
    PHP Code:
    function foo() {
       
    $bar Bar::instance();
       
    $bar->baz();
    }
    function 
    foo() {
       
    $bar $GLOBALS['bar'];
       
    $bar->baz();

    That said, ensuring that the object is indeed instantiated is something of a liability.

  5. #30
    SitePoint Member
    Join Date
    Jan 2006
    Location
    Norway
    Posts
    18
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    Actually I would claim that neither of thoose two represent a singleton. The first is a registry and the second is a static function.
    The first is clearly a registry pattern, that is why I wrote it. I just wanted to show how I could loose one line of code when using a version of the singleton pattern instead of the registry. This is done by calling the getInstance() method in each of the static methods in the singleton class.

    So technically by definition it isn't a true singleton, but I don't really see the difference. After all a pattern isn't a scientific law, but more like a recipe.

  6. #31
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by timvw
    (To me it seems to suggest that some 'units' can be larger than a single class...)
    I often have "integration" tests, e.g. where I allow the normal database interaction to take place. But the singleton still makes it harder to allow for the case where you want to test the code in isolation.
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  7. #32
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    There are clear advantages:
    easy global access
    I'd be much, much less even-handed than Jason. Using Singletons to make something globally available is a cop out. It's not design: it merely reveals that you couldn't think how to get from A to B properly.

    The purpose of Singleton is to have a single instance of something. It's a "Singleton" not a "Globalton". Using it for example as a convenient way to make database objects global will catch up with you one day when you need a second database conn. In tests you'll always need at least two connections: one to create a fixture and one per instance of the tested class. Then there's the problem with mocking.

    If you're looking for true "Singleton" rather than "Globalton" behaviour, a database object can encapsulate a single connection with the optional new link parameter. Instantiate as many times as you need connections: each one will always be unique.

    As mentioned in the phppatterns article, Registry is a compromise but a better one than using Singletons. They really are evil.

  8. #33
    ********* 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 Fjoggen
    I think it is worse to decide on before hand: I will never use a Singleton! than to look at what does the job best in this situation.
    I was making an empirical observation. Everytime I have used a Singleton I have had to painstakingly take the damn thing out again six months later. I've learned my lesson.

    Quote Originally Posted by Fjoggen
    I and a couple of others are designing a mulitplayer logfile parser/ statistics generator, where the log files in question can be from 3KB to 1GB and bigger.
    You method invades the code with an enormous amount of clutter. You have two options...

    1) Use the hooks in Xdebug.
    2) Use the AOP techniques in the Pico, a Dependency Injection tool.

    If it's a remote host, then option 1 is ruled out unless you simulate the host on a test machine. If this is too much work, then we are on to option 2.

    If you must log stuff, at least apply the logging responsibility with a Decorator. This will keep the code clean, and make it easier to turn the logging on and off (even dynamically). By instantiating the major objects through a DI container, you move all their instantiation into one file. This means you can add and remove your tuning code just by swapping out one PHP script. The DI tool can be used to apply decorators automatically. The rest of your code base is completely unaware that the decorators have been applied.

    Not only is Singleton a poor choice here, it's one that is actually damaging the rest of your application.

    Quote Originally Posted by Fjoggen
    Not exactly something I need in my everyday php application. To be honest I am not convinced php is the right tool for the job.
    OK, I am going to be a little contraversial here. Time for the hard hat...

    Rule 1) Using a debugger is the most inefficient thing a programmer can ever do.
    Rule 2) Reading log files is even worse.

    It strikes me that you have lost control of your application when you are poking a black box with configuration files and hoping something pops out the other end. You shouldn't be restling with your code. It's too labour intensive for a start.

    If you cannot break your components down and test them individually,because they are glued together for performance reasons, then time for something radical.

    How about you write your maths routines in Fortran, write some C code that can read the Fortran calling convention and then write a PECL plug in. It's probably a day's work to get Fortran to talk to C, and a couple of days work to get a rudimentary PHP plog-in up and running. That would give you a factor of a hundred performance boost. Enough to stop you worrying about every last configuration option.

    It's usually easier to change a design decision than to hand optimise.

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

  9. #34
    Resident Code Monkey Chris Corbyn's Avatar
    Join Date
    Nov 2005
    Location
    Melbourne, Australia
    Posts
    713
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    I'd be much, much less even-handed than Jason. Using Singletons to make something globally available is a cop out. It's not design: it merely reveals that you couldn't think how to get from A to B properly.

    The purpose of Singleton is to have a single instance of something. It's a "Singleton" not a "Globalton". Using it for example as a convenient way to make database objects global will catch up with you one day when you need a second database conn. In tests you'll always need at least two connections: one to create a fixture and one per instance of the tested class. Then there's the problem with mocking.

    If you're looking for true "Singleton" rather than "Globalton" behaviour, a database object can encapsulate a single connection with the optional new link parameter. Instantiate as many times as you need connections: each one will always be unique.

    As mentioned in the phppatterns article, Registry is a compromise but a better one than using Singletons. They really are evil.
    I agree that using a registry to contain instances that are needed throught your application is a clean way to handle this. To be honest I've yet to jump on the TDD bandwagon so I can't comment in the issues it causes with testing... I'm actually about to jump in with both feet and test something that's already written -- hradly a good way to start with unit testing I'm sure but I'll use it form the outset on my next project, or when testing new plugins on this project <drifting off-topic now though...>

  10. #35
    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 Fjoggen
    So technically by definition it isn't a true singleton, but I don't really see the difference.
    To my understanding, the singleton is a description of a particular implementation. You're right that the intend of the singleton is to provide a single object globally, and as such a static class fulfills the same role. That doesn't make a static class a singleton though.

  11. #36
    SitePoint Member
    Join Date
    May 2006
    Location
    Saratov, Russia
    Posts
    13
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by d11wtq
    come on it's hardly rocket science to take out the static stuff and make the constructor public so you can use multiple instances
    Consider a class that uses a singleton instance to access the database:

    PHP Code:
    class User
    {
        var 
    $_id;
        var 
    $_name;
        var 
    $_password;
        var 
    $_group;
        var 
    $_email;
        var 
    $_joinDate;
        var 
    $_lastVisit;

        function 
    User$userId )
        {
            
    $db =& Db::getInstance();
            
    $db->query( ... );
            ...
        }

        function 
    findIdByNameAndPassword$name$password )
        {
            
    $db =& Db::getInstance();
            
    $db->query( ... );
            ...
        }

        function 
    findIdByName$name )
        {
            
    $db =& Db::getInstance();     
            
    $db->query( ... );
            ...
        }

        function 
    save()
        {
            
    $db =& Db::getInstance();
            
    $db->query( ... );
            ...
        }
      
        
    // Getters and setters go here

    Now I want to reuse the class in another application where the Front Controller creates the database connection and then passes it around. Since I want the class to use the same database connection as the whole application, I have to change all its lines accessing the singleton:

    PHP Code:
    class User
    {
        var 
    $_id;
        var 
    $_name;
        var 
    $_password;
        var 
    $_group;
        var 
    $_email;
        var 
    $_joinDate;
        var 
    $_lastVisit;
        var 
    $_db;

        function 
    User$userId null, &$db )
        {
            
    // Use application's database connection 
            // rather than a singleton instance
            
    $this->_db =& $db;
            
    $this->_db->query( ... );
            ...
        }

        function 
    findIdByNameAndPassword$name$password )
        {
            
    $this->_db->query( ... );
            ...
        }

        function 
    findIdByName$name )
        {
            
    $this->_db->query( ... );
            ...
        }

        function 
    save()
        {
            
    $this->_db->query( ... );  
            ...
        }

        
    // Getters and setters go here


  12. #37
    SitePoint Zealot DerelictMan's Avatar
    Join Date
    Oct 2005
    Posts
    123
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Question

    Quote Originally Posted by lastcraft
    OK, I am going to be a little contraversial here. Time for the hard hat...

    Rule 1) Using a debugger is the most inefficient thing a programmer can ever do.
    Rule 2) Reading log files is even worse.
    I'm curious. Have you, within the past six months, temporarily placed a print/echo statement in one of your PHP programs for the purposes of debugging a problem?

    I'm familiar with the argument that well-crafted unit tests negate the need for debuggers/logging, and I can definitely understand the theory behind it. But it seems to me that no matter how well defined and comprehensive your unit tests are you are still going to run into a case here and there where you want to print/echo out a value to see what it contains, or to trace the program flow.

    If you actually haven't had to do that within the past six months then let me say that I'm impressed. If you have had to do that, then isn't that pretty much the same thing as creating watches and setting up breakpoints in a debugger?

  13. #38
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DerelictMan
    I'm curious. Have you, within the past six months, temporarily placed a print/echo statement in one of your PHP programs for the purposes of debugging a problem?
    No, that is what $this->dump() is for in the unit test cases
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  14. #39
    SitePoint Zealot DerelictMan's Avatar
    Join Date
    Oct 2005
    Posts
    123
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    No, that is what $this->dump() is for in the unit test cases
    Wink acknowledged, but seriously, that is just print/echo in disguise, so therefore anyone who would claim that using a debugger is evil but not have any issue with $this->dump() is being a bit inconsistent...

    Isn't the existence of dump() a tacit acknowledgement that sometimes the quickest way to troubleshoot certain types of problems is to just see what a particular variable contains? And isn't that, among other things, what a debugger is designed for?

  15. #40
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Off Topic:

    Quote Originally Posted by DerelictMan
    Wink acknowledged, but seriously, that is just print/echo in disguise, so therefore anyone who would claim that using a debugger is evil but not have any issue with $this->dump() is being a bit inconsistent...

    Isn't the existence of dump() a tacit acknowledgement that sometimes the quickest way to troubleshoot certain types of problems is to just see what a particular variable contains? And isn't that, among other things, what a debugger is designed for?
    This is starting to go off topic for this thread, but I think the crux of this issue is more where you are inspecting the information. The fact that you are doing this inside of the test case is good because:
    a) it shows you are actually testing
    b) you are not invading your actual code with debugging logic
    c) you are testing the public interface, helping you to concentrate on interface and interaction (the part of TDD which elevates the practice to the design level)
    d) when you remove the $this->dump(), you still have the rest of the test case, and the consequece that it will continue to run each time you run the test suite, unlink the print/var_dump style where you would have to identify the bug, and then invade your code again to figure out what is going on.
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  16. #41
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It is debugging but on a very small scale. With everything parcelled up into classes and unit tests methodically checking detailed behaviour, the focus is very narrow and controlled. Ideally a failing test will tell you exactly what went wrong but OK you might need the odd dump() now and again. It's not really the same as wading through pages of debugger info - you won't need to do that.

  17. #42
    SitePoint Zealot DerelictMan's Avatar
    Join Date
    Oct 2005
    Posts
    123
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    This is starting to go off topic for this thread, but I think the crux of this issue is more where you are inspecting the information.
    That's fine, but you can easily use a debugger inside a test case, just like you can use dump(). Debuggers and a well designed test suite aren't mutually exclusive.

    b) you are not invading your actual code with debugging logic
    ...
    d) when you remove the $this->dump(), you still have the rest of the test case, and the consequece that it will continue to run each time you run the test suite, unlink the print/var_dump style where you would have to identify the bug, and then invade your code again to figure out what is going on.
    I wasn't advocating the use of print/echo/var_dump debug statements; quite the contrary. I am saying that there is nothing wrong with occasionally using a debugger to take a quick peek under the hood, and I have found it more efficient to do so than to place print/echo statements inside my code.

    In fact, the last time I used a debugger was while working on a Java project, and it was inside a JUnit test method. My point is, I didn't use the debugger in lieu of unit testing; I used it as a complement to unit testing. Of course it helps that it is so easy to do this within a decent IDE. I don't use debuggers in PHP because it's not exactly convenient to do so...

    Quote Originally Posted by McGruff
    It is debugging but on a very small scale. [...] It's not really the same as wading through pages of debugger info - you won't need to do that.
    I agree, and I wasn't claiming that was a good idea. But lastcraft didn't say that "debugging on a large scale" or "debugging on any scale other than very small" was the most inefficient thing a programmer can ever do. He said "using a debugger" is. That's the problem with broad unqualified generalizations...

    I think the knee-jerk anti-debugger stance is probably a reaction to the tendency of a lot of programmers to use debuggers to the exclusion of all other approaches. (It's probably true that most people who use debuggers also don't unit test.) I would agree that if it were an either/or proposition then unit testing wins over using a debugger. My claim is that debuggers, used in moderation and along with a comprehensive and well designed test suite, can be quite useful tools.

    Sorry for dragging the thread OT...

  18. #43
    SitePoint Zealot
    Join Date
    Oct 2004
    Location
    Worcester
    Posts
    138
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I've noticed that my need for a debugger/dump() is directly proportional to the size of the change I'm making to the code. If I'm making a fairly large change, I'm much more likely to need to dump() out stuff to find out what's happened when it doesn't work.

    I suspect that Marcus is better at making the correct size of code change than I am and hence doesn't need echo much

    Regards,

    Rob...

  19. #44
    Non-Member coo_t2's Avatar
    Join Date
    Feb 2003
    Location
    Dog Street
    Posts
    1,819
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by sweatje
    The main problem I have with them is like any other global variable, they make testing much harder. The problem is that of Dependency Injection. If the code creates the object you are using by using the hard coded singleton factory, then how to you get a mock object in place of the singleton resource?
    Quote Originally Posted by McGruff
    Then there's the problem with mocking.

    I don't understand what it is about singletons that makes them harder to mock than a normal aggregated object.
    Can't you just create a creation method in the class being tested, subclass it to a test version,
    and set a mock on the creation method's return value? I'm sure you guys have done this before so
    I guess there must be something about a singleton's behavior that makes this
    an undoable option -- something that I'm not seeing. I guess I just need a code example.

  20. #45
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by coo_t2
    I don't understand what it is about singletons that makes them harder to mock than a normal aggregated object.
    Can't you just create a creation method in the class being tested, subclass it to a test version,
    and set a mock on the creation method's return value? I'm sure you guys have done this before so
    I guess there must be something about a singleton's behavior that makes this
    an undoable option -- something that I'm not seeing. I guess I just need a code example.
    All of that is true, but a heck of a lot more work than just allowing for propper DI and passing in the Mock Object. IMHO
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  21. #46
    Non-Member coo_t2's Avatar
    Join Date
    Feb 2003
    Location
    Dog Street
    Posts
    1,819
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by sweatje
    All of that is true, but a heck of a lot more work than just allowing for propper DI and passing in the Mock Object. IMHO
    Off Topic:


    Ah. Well, I don't wanna take the thread off topic, but just a quick question: Are you moving away from aggregation in general?


  22. #47
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by coo_t2
    Off Topic:


    Ah. Well, I don't wanna take the thread off topic, but just a quick question: Are you moving away from aggregation in general?

    I am just happier doing:

    PHP Code:
    class Model {
      protected 
    $db;
      function 
    __construct($db) {
        
    $this->db $db;
      }
      function 
    someMethod() {
        
    $this->db->exec(...);
      }

    Than I am with:
    PHP Code:
    class Model {
      protected 
    $db;
      function 
    __construct() {
        
    $this->db $this->getDb();
      }
      protected function 
    getDb() {
        return 
    DB::getInstance();
      }
      function 
    someMethod() {
        
    $this->db->exec(...);
      }

    and going through the motions of creating a partial mock object for Model and knocking out the getDb method every time I want to inject the db connection.

    I believe that most people head down the path towards a Singleton to avoid the headache of passing the object into the relevant objects which require the connection, when in fact in most cases it is easier to just take the bull by the horns and actually do this.

    I recall a story (sorry, source escapes me at the moment, though I am thinking perhaps it was Fowler in Refactoring) of a Accounting system with multiple currencies. Their initial approach was to use a MoneyExchanger singleton. This was a thorn in their side from a testing perspective until they finally bit the bullet and passed it in everywhere required. It turns out the conversion was not anywhere near as painful at they thought, and in one afternoon they had more flexible and easily testable code.

    Perhaps to some extend you have to already have drank the "testing" kool-aid, but in the end doing TDD religiously leads to highly cohesive, loosely coupled systems, and the Singleton pattern is a drag on the "loosely coupled" part of that goal.
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

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

    Yes I was overgeneralising, but why crab a good story .

    Quote Originally Posted by DerelictMan
    I'm curious. Have you, within the past six months, temporarily placed a print/echo statement in one of your PHP programs for the purposes of debugging a problem?
    I tend to use the SimpleTest dump() method more often, but yes. That print never stays in for more than about ten seconds though. If it takes longer, I roll back the chages in my editor and have another go. It's there to catch silly typos.

    If I have to go to the effort of firing up the debugger (frankly I don't even know how they work anymore) then I've lost productivity. Probably my code is unclear and needs a rethink, and that will be time better spent. This is the same for C code as well as PHP or Ruby.

    I never type more than a few lines of code between tests though.

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

  24. #49
    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 sweatje
    I am just happier doing:

    PHP Code:
    class Model {
      protected 
    $db;
      function 
    __construct($db) {
        
    $this->db $db;
      }
      function 
    someMethod() {
        
    $this->db->exec(...);
      }

    I'm all for it, but I have ran into another problem: what if the Model has several -- say, four or five -- relations to be passed in that way?

  25. #50
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    I'm all for it, but I have ran into another problem: what if the Model has several -- say, four or five -- relations to be passed in that way?
    I assume that is a rhetorical question ?

    If things start getting messy, then simple constructor DI is probably not the answer, so it would be time to look for alternatives (in no particular order)

    • restructure the code so there are fewer dependancies (refactor)
    • pick and use a DI container to handle your wiring (Pico, Phemto)
    • Use a different pattern (pass in a registry, use a service locator)
    • switch to a different means of DI (say setter injection)
    • give up, use the Singletons, and live with the coupling and testing headaches
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.


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
  •