<?xml version="1.0"?>
<rss version="2.0">
  <channel>
    <title>PHPDeveloper.org</title>
    <link>http://www.phpdeveloper.org</link>
    <description>Up-to-the Minute PHP News, views and community</description>
    <language>en-us</language>
    <pubDate>Tue, 21 May 2013 17:31:56 -0500</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[Chris Hartjes' Blog: Monkey-patching Is for Closers]]></title>
      <guid>http://www.phpdeveloper.org/news/18227</guid>
      <link>http://www.phpdeveloper.org/news/18227</link>
      <description><![CDATA[<p>
In <a href="http://www.littlehart.net/atthekeyboard/2012/07/13/monkey-patching-is-for-closers/">this new post</a> to his blog <i>Chris Hartjes</i> looks at why "<a href="http://en.wikipedia.org/wiki/Monkey_patch">monkey patching</a> is for closers" - how it should be avoided in favor of making the code itself more testable rather than "hack" with the patching.
</p>
<blockquote>
The use of monkey-patching is extremely prevalent in the Ruby community and also to a certain extent in Python usage. I'm not going to go into length about their use of it except to say that it seems quite common and I think most developers are using it as a shortcut to counter what might be poor code architecture decisions. 
</blockquote>
<p>
He includes some example code, excerpted from a blogging system where <a href="http://php.net/manual/en/book.runkit.php">runkit</a> was originally use to test its functionally. He shows how some simple refactoring (adding input parameters, replacing a static method call, etc) makes it easier to unit test. Comments to the post include further refactoring ideas as well as a response from the <a href="http://antecedent.github.com/a-time-and-place-for-monkey-patching.html">original "offender"</a> whose post sparked <i>Chris'</i> response.
</p>]]></description>
      <pubDate>Mon, 16 Jul 2012 09:09:51 -0500</pubDate>
    </item>
  </channel>
</rss>
