SitePoint Sponsor

User Tag List

Page 3 of 4 FirstFirst 1234 LastLast
Results 51 to 75 of 79
  1. #51
    SitePoint Guru
    Join Date
    Nov 2003
    Location
    Huntsville AL
    Posts
    706
    Mentioned
    4 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by timvw
    Meaby it's a time to write an article 'Programmers are evil'
    How about 'Evil is Evil'?

  2. #52
    SitePoint Zealot DerelictMan's Avatar
    Join Date
    Oct 2005
    Posts
    123
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ahundiak
    How about 'Evil is Evil'?
    Doesn't that depend on what the meaning of the word "is" is?

  3. #53
    SitePoint Guru
    Join Date
    Nov 2003
    Location
    Huntsville AL
    Posts
    706
    Mentioned
    4 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by DerelictMan
    Doesn't that depend on what the meaning of the word "is" is?
    Yeah you are right. Maybe 'Is Is Evil'?

  4. #54
    SitePoint Evangelist jplush76's Avatar
    Join Date
    Nov 2003
    Location
    Los Angeles, CA
    Posts
    460
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If you've ever had to work on a team of programmers or work with legacy PHP code you'll quickly realize a PHP debugger is the greatest invention ever!

    I wouldn't take an applicant seriously that didn't know how to use a debugger.
    My-Bic - Easiest AJAX/PHP Framework Around
    Now Debug PHP scripts with Firebug!

  5. #55
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Honestly if you're testing you won't need it. It can seem like more work to do at first but it's worth it for a whole range of reasons. I doubt if I'd still be programming without unit testing to bring code under control. Debugging is painful, frustrating experience. Life's too short.

  6. #56
    SitePoint Evangelist jplush76's Avatar
    Join Date
    Nov 2003
    Location
    Los Angeles, CA
    Posts
    460
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    not to turn this into a debugger vs non debugger debate but the reality of having to maintain 250,000 lines of the worst code devised by man (globals EVERYWHERE ) without a debugger is laughable.

    "hey boss, I know we need to get this feature out asap but can I take a few weeks to rearrange this code and write some tests for it?"

    0 chance of that happening.

    Even with using TDD I enjoy using the zend debugger if something doesn't pass when I know it should...it lets me quickly see all my variables, lets me expand all my objects and make sure all the properties get set. I've been var_dump and echo free for a long while and enjoying it
    My-Bic - Easiest AJAX/PHP Framework Around
    Now Debug PHP scripts with Firebug!

  7. #57
    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 assume that is a rhetorical question ?
    No, actually, I just wanted you to give me a nice comprehensive list like that.

  8. #58
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    > Honestly if you're testing you won't need it.

    As good as Unit Testing is, relying on tests is only as good as the actual tests themselves; In some cases the tests may be working, ie You get the green bar but just how indepth are those tests? If they're not covering every eventuality then you need another source to cover the holes.

    So, no I wouldn't go as far as to make that kind of statement, unit tests or not. Just because you are using unit tests that doesn't excuse you from using other means of quality assurance for your clients...

  9. #59
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm not sure what you know about testing but if you find a bug it would first be expressed as a new test then you code to the failing test. You can add to the specification as needed. At least you do have one to add to.

  10. #60
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well, I must admit my unit testing knowledge is no where near what you know of course, but what you've expressed is pretty much obvious, so I would agree but that's not to say that you can still ignore or avoid other means of assuring quality.

    With your statement you are basically saying that you refuse to use other means, may I say it... To back up those tests, but again some might say that you don't need that I suppose but I beg to differ; Remember unit testing is just a tool, one of many that are available...

  11. #61
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Testing can't tell you if users find your UI confusing and non-intuitive. It can't tell you if a #669 font color on a #000 background is legible. It'll work for just about everything else. It's up to you to make sure you've covered everything of interest. It doesn't matter so much if you might have missed something. You can't avoid that. The point is that you do have a formal testing framework in place commenting on the working code. It can be refined as necessary and once a new test is added for a new bug, that bug can never be reintroduced.

    A full test run for a large-ish app might make tens of thousands of individual checks at the click of a button. The only practical alternative is not to bother, at least not at this level of detail. There is no comparable tool that I am aware of. What did you have in mind?

  12. #62
    Employed Again Viflux's Avatar
    Join Date
    May 2003
    Location
    London, On.
    Posts
    1,127
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This quote is from the C2 Goto page, but I think it applies equally well to Singleton implementations.

    Quote Originally Posted by C2
    The apprentice uses it without thinking. The journeyman avoids it without thinking. The master uses it thoughtfully.
    Not the first time I've tossed that quote in this forum


    On the off-topic debate of testing...

    First, why is it that every thread on this forum (nearly) degenerates into a unit-testing vs. no-unit-testing debate? It's growing old. Not everyone is mandated to do unit-testing, not everyone wants to do unit-testing, not everyone cares for unit-testing.

    Second, why not use a debugger when it's already available and can produce quite useful information? Zend's implementation is a tad wonky (or was), but does the job.

    My main uses for a debugger at this moment (since I've decided to give this TDD a thing a try) are :
    - Catching bottlenecks in my applications before they grow too large.
    - Catching E_STRICT warnings.

    On the E_STRICT thing, I know that testing would also toss them. I've disabled that level of error_reporting while running unit tests because SimpleTest itself throws a slew of them. So this is more of a workaround that a debugger helps me with, rather than a genuine benefit, since I could also fire up the page in a browser.

  13. #63
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Isn't the whole testing vs. debugging a false dichotomy? Testing would allow you to find out that there is a problem with your code, and debugging to pinpoint exactly where and how the error is generated, allowing you to fix it. Is testing really supposed to rid you of the latter?

  14. #64
    SitePoint Evangelist jplush76's Avatar
    Join Date
    Nov 2003
    Location
    Los Angeles, CA
    Posts
    460
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ezku
    Isn't the whole testing vs. debugging a false dichotomy? Testing would allow you to find out that there is a problem with your code, and debugging to pinpoint exactly where and how the error is generated, allowing you to fix it. Is testing really supposed to rid you of the latter?
    I like to think of it that way, yes.
    They're all tools in your toolbox. A good developer has a rich toolbox and picks the right one he needs. You can rely on unit testing to find a bug in a codebase of 250,000 lines of code without a single unit test already written. Global vars all over the place, no way to mock anything out without changing the code.
    My-Bic - Easiest AJAX/PHP Framework Around
    Now Debug PHP scripts with Firebug!

  15. #65
    SitePoint Zealot
    Join Date
    Feb 2004
    Location
    Boston, MA
    Posts
    188
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Okay, a bit more on-topic, let me ask this:

    Which is better: A Singleton or Inheritance?

    Take the Database connection problem for example. Lets say instead of the User class getting a new Single instance everytime it uses the DB, it instead inherits the object for a parent class, lets say something like Object_DB, whatever.

    PHP Code:
    class Object_DB extends Object {

    protected 
    $db;

    protected function 
    __construct() {
      
    $this->db = new SuperMegaDBWrapper('server','username','password'); 
    }

    }


    class 
    User extends Object_DB {

    public function 
    __construct() {
      
    parent::__construct();
    }

    public function 
    add($someone) {
      
    $db->query("INSERT INTO users ...");
    }

    In this example, if you wanted to say have the Front Controller create a DB object, you just add it to the constructor of Object_DB, set the class var using that, and you don't have to change anything in the child classes. However, I'm sure you could argue this just creates another layer of dependency due to multiple layers of inheritance. *shrug*

  16. #66
    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)
    PHP Code:
    $this->db = new SuperMegaDBWrapper('server','username','password'); 
    is the original source of pain for all DI discussions.
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  17. #67
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    PHP Code:
    $this->db = new SuperMegaDBWrapper('server','username','password'); 
    is the original source of pain for all DI discussions.
    Pain?
    That type of statement leads to DI discussions, or causes pain for DI?

  18. #68
    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 Ren
    Pain?
    That type of statement leads to DI discussions, or causes pain for DI?
    Leads to DI. It hard codes the dependancy into the object. How can you switch out that layer for something else? Us TDD'ers will complain we can't sneak in a mock object for testing, but what about people who like brute force debugging, how do they sneak in their logging decorated database layer?
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  19. #69
    SitePoint Guru dbevfat's Avatar
    Join Date
    Dec 2004
    Location
    ljubljana, slovenia
    Posts
    684
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ezku
    Isn't the whole testing vs. debugging a false dichotomy? Testing would allow you to find out that there is a problem with your code, and debugging to pinpoint exactly where and how the error is generated, allowing you to fix it. Is testing really supposed to rid you of the latter?
    I agree. Testing and debugging cover the same area to some extent, but cannot replace each other. UT will tell you exactly ("exactly" depends on your test coverage) where the error happened and what isn't like it's supposed to be. But you still have to find the bug.

    I often use echoes (which is debugging) in the classes that I test and for which the tests fail - simply because I have to dig deeper and find out what exactly went wrong. Test fails, because array has 1 element. It should have 2. Ok, why doesn't it? Debug. Find out that I write twice in the same array position, instead of in two different positions. Testing can't cover this part. It can't go that deep.

    IMO testing and debugging are two different tools for two different jobs. I use both a lot and I couldn't do without them.

  20. #70
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by melancholic
    As I saw it, the singleton pattern was the workaround for objects that required global access such as the registry, service locator, abstraction layers and other objects of the like.
    First of all, do the objects you mention really require global access? I honestly can't think of an instance where I couldn't simply pass around the object; use of a Singleton this way is generally just a shortcut, and one that can bring about a host of issues (like hidden dependencies).

    Secondly, although global access is a characteristic of the Singleton pattern, I would say that it's an implementation side effect of the real use of Singletons, which is to guarantee a single instance of an object. That's something that is generally useful only in very specific cases, like accessing a system resource, or when creating the object is very expensive resource-wise, and there are other patterns that can be used to solve those issues.

    So really, the reason that Singletons should be considered evil is that the issues the pattern solves can all be solved in other ways which are much more flexible.

  21. #71
    SitePoint Zealot
    Join Date
    Feb 2004
    Location
    Boston, MA
    Posts
    188
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    Leads to DI. It hard codes the dependancy into the object. How can you switch out that layer for something else? Us TDD'ers will complain we can't sneak in a mock object for testing, but what about people who like brute force debugging, how do they sneak in their logging decorated database layer?
    Well, that was merely a cheap example, you could easily change it thusly:
    PHP Code:
    ...
    protected function 
    __construct($db=false) {
      if(!
    $db) {
        
    self::db = new SuperMegaDBWrapper('server','username','password');
      } else {
        
    self::db $db;
      }
    }
    ... 
    which was my point.

  22. #72
    Non-Member melancholic's Avatar
    Join Date
    Nov 2004
    Location
    Australia
    Posts
    447
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees
    First of all, do the objects you mention really require global access? I honestly can't think of an instance where I couldn't simply pass around the object; use of a Singleton this way is generally just a shortcut, and one that can bring about a host of issues (like hidden dependencies).
    You are exactly right with regards to the hidden dependencies and I've been thinking about this, but the thing is I feel uncomfortable passing tramp data around. I feel trapped. Gray areas surround me.

    Take the following implementation for example.

    I have a front controller with a method that handles requests by reading the controller parameter set up in the request object and creates an application controller which expects a request and connection object.

    The reason that the application controller expects a connection object is purely so that it can use it to pass to the model.

    The application controller has a bunch of methods that are mapped to the action parameter in the request object with a default method (index)

    Now the index method sets up a model by passing the connection and (I feel bad about this one - I may have to refactor this out somehow) the request object, and then runs a method within the model which sets its state.

    The App Controller then passes the Model to the View which sets its parameters using data accessed from the Model.

    The way I'm currently handling this is by using a registry which is a singleton. Classes access an instance of the registry and use what they need.

    I'd like to get away from this, but well, I feel nervous about passing the registry around from object to object. Would passing the registry around be considered as bad practice? Can you come up with an alternative implementation that would not be using the registry as a singleton or perhaps an alternate way of looking at this?

    I know I've probably missed something somewhere but will refactor as soon as a better idea comes along.

    --

    Quote Originally Posted by 33degrees
    Secondly, although global access is a characteristic of the Singleton pattern, I would say that it's an implementation side effect of the real use of Singletons, which is to guarantee a single instance of an object. That's something that is generally useful only in very specific cases, like accessing a system resource, or when creating the object is very expensive resource-wise, and there are other patterns that can be used to solve those issues.
    I agree with this, I've skimmed through a comment posted on this thread which stuck to my head - "Singleton not Globalton".

    But then again, I feel that it could be just in the name. It could be said that in most descriptions, a singleton is described to give a "single, global" instance.

    If it were just a single instance, then it really wouldn't be the Singleton we all know and love (or hate).

    It's a silly point I'm making, but consider if it were called a "Globalton" would you say that the single instance is just a side effect of the global instance of the pattern?

    --

    With regards to the detestable singleton debate, there was something about a "Test Safe Singleton" in the PHP patterns article that Marcus wrote.

    Would anyone consider this as a good implementation? or more of a clever work around?

    --

    hmmm after reading the article again, it's got me leaning toward passing the registry around, but I'd like to hear your thoughts on it.

    Regards,

  23. #73
    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 melancholic
    Can you come up with an alternative implementation that would not be using the registry as a singleton or perhaps an alternate way of looking at this?
    Inversion of Control but without going as far as the configurable, "intelligent" container in DI. Suppose you have a dumb Assembler class which will be responsible for instantiating pretty much everything:
    PHP Code:
      class FooAssembler {
      
          function &
    getFooController() {
              require_once(..
    etc..);
              
    $controller =& new FooController(
                  
    $this->_Quark(), 
                  
    $this->_Strangeness(), 
                  
    $this->_Charm());
          }
          function &
    _Quark() {
              require_once(..
    etc..);
              
    $quark =& new Quark(
                  
    $this->_Connection());
          }
          function &
    _Connection() {
              if( !isset(
    $this->conn)) {
                  require_once(...);
                  
    $this->conn =& new MysqlConnection(...);
              }
              return 
    $this->conn;
          }
          
    // etc
      

    A connection object can be passed to Quark without having to go through any middlemen. The Assembler class creates a kind of "global" scope where anything can be passed directly to anything else.

    IoCC emphasises "assembly" as an architectural layer in its own right. Or is that putting it too strongly?

  24. #74
    SitePoint Guru
    Join Date
    Feb 2006
    Location
    Pittsburgh, Los Angeles
    Posts
    706
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Secondly, although global access is a characteristic of the Singleton pattern, I would say that it's an implementation side effect of the real use of Singletons, which is to guarantee a single instance of an object.
    I think you hit the nail on the head with this comment. Nobody has really been talking about what the Singleton Pattern is really useful for, just its negative side: Global access. It is after all a constructional pattern.

    Also, as most of these patterns evolved in other languages it should be noted that you don't always have "global access" to the singleton in other languages, it could be for example a package private class.

  25. #75
    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 McGruff
    IoCC emphasises "assembly" as an architectural layer in its own right. Or is that putting it too strongly?
    I don't think it is. I have been thinking about the same thing recently. One of the things a Dependency Injection Container embodies, is a single place to put all the assembly logic, whereas you otherwise would have that scattered all over your application. Thinking of the assembly as a distinct layer might help to give it the emphasis that needs?


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
  •