<?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, 22 May 2012 13:39:38 -0500</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[Evert Pot's Blog: Dangers of mutual dependencies]]></title>
      <guid>http://www.phpdeveloper.org/news/12084</guid>
      <link>http://www.phpdeveloper.org/news/12084</link>
      <description><![CDATA[<p>
In a <a href="http://www.rooftopsolutions.nl/article/228">recent post</a> to his blog <i>Evert Pot</i> warns against some of the issues that mutual dependencies in your applications.
</p>
<blockquote>
Much like most people, I try work out my class dependencies through a top-down 'waterfall'-ish approach. By attempting this, I think allows me to keep the structure very clear and understandable. [...] I try to apply the same model to instantiated objects and packages (groups of classes). When an object encapsulates another object, I attempt to make sure the sub-object object is not aware of the parent. When I design packages, I attempt to make sure 2 packages don't require 'each other'.
</blockquote>
<p>
He gives an example of where this could cause problems - a Database logger that has three types of logging included: file, syslog and database. Obviously the last of the three requires the Database class so they must always be used/included together.
</p>
<blockquote>
As a bonus a database-error could occur while logging, resulting in an endless loop (or segmentation fault if you're using PHP). [...] However, these types of situations are sometimes simply unavoidable (that's why we have include_once). When they are needed, they should be implemented with care and consideration.
</blockquote>]]></description>
      <pubDate>Fri, 06 Mar 2009 13:42:40 -0600</pubDate>
    </item>
  </channel>
</rss>

