<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xml:base="http://soa.dzone.com"  xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dz="http://www.developerzone.com/modules/dz/1.0">
<channel>
 <title>SOA Zone - Comments for &quot;Service-Orientation and Object-Orientation Part II:  A Comparison of Design Principles &quot;</title>
 <link>http://soa.dzone.com/articles/service-orientation-and-object-0</link>
 <description>Comments for &quot;Service-Orientation and Object-Orientation Part II:  A Comparison of Design Principles &quot;</description>
 <language>en</language>
<item>
 <title>Two very informative</title>
 <link>http://soa.dzone.com/articles/service-orientation-and-object-0#comment-2850</link>
 <description>&lt;!--paging_filter--&gt;&lt;p&gt;Two very informative Articles - thanks for that!&lt;/p&gt;&lt;p&gt;There&#039;s one point that comes to mind especially when considering encapsulation and message exchanging:&lt;/p&gt;&lt;p&gt;Encapsulation: &lt;/p&gt;&lt;p&gt;Classes (resp. Objects as their runtime representatives) encapsulate both state and behaviour. With the &#039;design principle&#039; TDA (Tell Don&#039;t Ask) in mind, this means that a class should also encapsulate logic that can be extracted or deduced from its state (e.g. checking if some constraints are met or aggregations based on the current state of an Object), since it is in the responsibility of the class to manage all information and actions that is related to its task.&lt;br /&gt;This will lead to a system of collaborators, where you&#039;ll only ask an Object about the needed information (or action) instead of asking for its state (data) and calculating the aggregated information for yourself (on behalf of that Object), potentially leading to code duplication (may that kind of information is needed by different collaborators) and thus violation of DRY.&lt;/p&gt;&lt;p&gt;Message Exchanging:&lt;/p&gt;&lt;p&gt;When interacting between two different collaborators in an object-oriented way, you&#039;re able to not only pass data but objects that will carry both state and behaviour (whereas you&#039;ll only pass data-centric messages without any logic in a service-oriented world). &lt;/p&gt;&lt;p&gt;I always ask myself, if this will lead to a kind of DRY violation, since the service contract (or potentially more than one service) have to provide the logic (that is normally encapsulaed within the passed object) for themselfes...&lt;/p&gt;&lt;p&gt;Greetings&lt;/p&gt;&lt;p&gt;Mario &lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;</description>
 <pubDate>Fri, 25 Apr 2008 19:20:04 -0400</pubDate>
 <dc:creator>mario.g</dc:creator>
 <guid isPermaLink="false">comment 2850 at http://soa.dzone.com</guid>
</item>
</channel>
</rss>
