<?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>Wed, 19 Jun 2013 18:51:19 -0500</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[thePHP.cc: Software Development Fluxx]]></title>
      <guid>http://www.phpdeveloper.org/news/19186</guid>
      <link>http://www.phpdeveloper.org/news/19186</link>
      <description><![CDATA[<p>
If you've ever played the card game "Fluxx" (or are familiar with the ever changing rules behind software development) you can release to <a href="http://thephp.cc/viewpoints/blog/2013/02/software-development-fluxx">this new article</a> from <i>Sebastian Bergmann</i>. He makes a link between the "Star Fluxx" card game and how OOP and encapsulation help make changing things easier.
</p>
<blockquote>
Star Fluxx is a science-fiction-themed version of Fluxx, "a card game [that] is different from most other card games, in that the rules and the conditions for winning are altered throughout the game, via cards played by the players." (Wikipedia) When I heard the description of the game on the aforementioned episode of TableTop it reminded me of software development projects. Changing business rules and requirements (rules and the conditions for winning), probably sounds familiar to you, too.
</blockquote>
<p>
He talks about how the game could be implemented effectively in OOP classes and interfaces - and how this structure would make it easier to make changes. A largely procedural codebase, however, would make the task much more challenging. The analogy breaks down a bit when it gets to the competitive nature of the game and how software development should be collaborative instead, but it's still effective.
</p>]]></description>
      <pubDate>Fri, 15 Feb 2013 09:06:57 -0600</pubDate>
    </item>
    <item>
      <title><![CDATA[PHPMaster.com: Practical Code Refactoring, Part 3 - Extensibility]]></title>
      <guid>http://www.phpdeveloper.org/news/18655</guid>
      <link>http://www.phpdeveloper.org/news/18655</link>
      <description><![CDATA[<p>
PHPMaster.com has posted the third part in their "Practical Code Refactoring" series - this time with a <a href="http://phpmaster.com/practical-code-refactoring-3/">focus on Extensibility</a>. (<a href="http://phpmaster.com/practical-refactoring-1/">Part 1</a>, <a href="http://phpmaster.com/practical-code-refactoring-2/">Part 2</a>).
</p>
<blockquote>
Extensible code is a piece of code which follows re-usable, logical, well-known patterns, be it standard design patterns, or normal logical flow. Modular code tends to be highly extensible and monolithic code tends to be non-extensible, but monolithic code might be more efficient, so to solve this conundrum some practices allow developing in a modular way and deploying in a monolithic way so we can get the best of both worlds. The major aspects which we are to discuss with regard to extensible code are: logical extensibility (normal logical flow and design patterns), modular design, and decoupling and encapsulation.
</blockquote>
<p>
He goes through each of the sections - logical extensibility, modular design and decoupling/encapsulation - and for each provides some questions to ask to help you whip your code into shape.
</p>]]></description>
      <pubDate>Thu, 25 Oct 2012 09:22:05 -0500</pubDate>
    </item>
    <item>
      <title><![CDATA[Wes Shell's Blog: Encapsulation in PHP]]></title>
      <guid>http://www.phpdeveloper.org/news/13378</guid>
      <link>http://www.phpdeveloper.org/news/13378</link>
      <description><![CDATA[<p>
<i>Wes Shell</i> has <a href="http://wshell.wordpress.com/2009/10/12/encapsulation-in-php/">posted a new tutorial</a> to his blog today looking at encapsulation in PHP development - containing parts of the script to make them easier to work with as a whole.
</p>
<blockquote>
In order to understand the purpose of encapsulation you first need to  understand the purpose of classes. [...] In order for them to be used properly as they were designed, you will need to limit how users of the class can interact with those characteristics and functionality.
</blockquote>
<p>
He looks at the visibility modifiers (public/private/protected), interface functions and some sample code showing how to use them in a simple class to work with a Person's set of data.
</p>]]></description>
      <pubDate>Tue, 13 Oct 2009 09:05:16 -0500</pubDate>
    </item>
    <item>
      <title><![CDATA[Blue Parabola Blog: Objectively Oriented]]></title>
      <guid>http://www.phpdeveloper.org/news/11971</guid>
      <link>http://www.phpdeveloper.org/news/11971</link>
      <description><![CDATA[<p>
On the Blue Parabola blog, <i>Matthew Turland</i> <a href="http://blueparabola.com/blog/objectively-oriented">takes a look</a> at object-oriented programming and what core concepts lie at its heart.
</p>
<blockquote>
What is <a href="http://en.wikipedia.org/wiki/Object-oriented_programming">object-oriented programming</a>? The acronym OOP has become a bit of a buzzword in the <a href="http://en.wikipedia.org/wiki/History_of_programming_languages#The_1990s:_the_Internet_age">current age of programming</a>, to the point where the waters of its definition have become rather murky. [...] PHP <a href="http://michaelkimsal.com/blog/php-is-not-object-oriented/">may not be object-oriented</a>, but from a purist perspective, neither is Java. What do I mean by "purist perspective?" Plain and simple: everything is either an <a href="http://en.wikipedia.org/wiki/Object_(computing)#Objects_in_object-oriented_programming">object</a> or a <a href="http://en.wikipedia.org/wiki/Message_passing">message</a> being passed between objects (where message parameters are also objects). 
</blockquote>
<p>
He mentions one of the first languages to support objects (<a href="http://en.wikipedia.org/wiki/Simula">Simula</a>) and the four fundamental concepts that would make a language truly OOP - abstraction, inheritance, encapsulation, polymorphism. Its his opinion, though, that while its good for languages to adhere to these four principles as much as they can, discussions about how well they adhere to them is usually just "spinning your wheels" and don't have much use.
</p>]]></description>
      <pubDate>Wed, 18 Feb 2009 09:31:30 -0600</pubDate>
    </item>
    <item>
      <title><![CDATA[Alex Netkachov's Blog: Are setters evil?]]></title>
      <guid>http://www.phpdeveloper.org/news/10425</guid>
      <link>http://www.phpdeveloper.org/news/10425</link>
      <description><![CDATA[<p>
<i>Alex Netkachov</i> has posted his <a href="http://www.alexatnet.com/node/151">own response</a> to <a href="http://www.phpdeveloper.org/news/10420">this opinion</a> on the Typical Programmer on getters and setters in object-oriented applications.
</p>
<blockquote>
"Do not use getters and setters" looks like a hastily advise, but its meaning is very important and it is "do not break encapsulation", which moves us to the question what the encapsulation is.
</blockquote>
<p>
He notes that encapsulation is, in essence, hiding parts of the code away so that the user/other coders only see a little bit of the magic that happens. He argues that getters and setters are a valid part of the encapsulation process and that designing a good, easy to use system almost requires them.
</p>]]></description>
      <pubDate>Tue, 17 Jun 2008 09:36:03 -0500</pubDate>
    </item>
    <item>
      <title><![CDATA[Typical Programmer Blog: Doing it wrong: getters and setters]]></title>
      <guid>http://www.phpdeveloper.org/news/10420</guid>
      <link>http://www.phpdeveloper.org/news/10420</link>
      <description><![CDATA[<p>
According to <a href="http://typicalprogrammer.com/?p=23">this new post</a> on the Typical Programmer blog, using getters and setters in your scripts only adds in a bit of unnecessary coupling and complexity to your scripts that you just don't need.
</p>
<blockquote>
Today most of the popular programming languages support objects, limiting scope, modularity, passing by value, and sophisticated built-in types. There should be no reason to deliberately expose an object's data to the rest of the code because the language can enforce encapsulation and data hiding.
</blockquote>
<p>
While not specific to PHP, <a href="http://typicalprogrammer.com/?p=23">the post</a> does recommend against them because of one simple reason common to all languages that make them possible - they "break the encapsulation OOP offers". For them, they're like a cheat to get around bad coding practices and are not needed to make a successful application work.
</p>]]></description>
      <pubDate>Mon, 16 Jun 2008 11:19:17 -0500</pubDate>
    </item>
  </channel>
</rss>
