<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Multiple Inheritance and Mixins</title>
	<atom:link href="http://elegantcode.com/2007/12/02/multiple-inheritance-and-mixins/feed/" rel="self" type="application/rss+xml" />
	<link>http://elegantcode.com/2007/12/02/multiple-inheritance-and-mixins/</link>
	<description></description>
	<lastBuildDate>Wed, 17 Mar 2010 08:54:42 -0500</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.6</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Sean Timm</title>
		<link>http://elegantcode.com/2007/12/02/multiple-inheritance-and-mixins/comment-page-1/#comment-29564</link>
		<dc:creator>Sean Timm</dc:creator>
		<pubDate>Mon, 11 Aug 2008 19:06:23 +0000</pubDate>
		<guid isPermaLink="false">http://elegantcode.com/2007/12/02/multiple-inheritance-and-mixins/#comment-29564</guid>
		<description>Mixins give the opportunity to achieve various design patterns in a more compositional (rather than inheritance-based way).  Take a look at a design pattern involving inheritance and think about how you could break up the inheritance chain and solve the problem via mixins.  It gets pretty interesting...</description>
		<content:encoded><![CDATA[<p>Mixins give the opportunity to achieve various design patterns in a more compositional (rather than inheritance-based way).  Take a look at a design pattern involving inheritance and think about how you could break up the inheritance chain and solve the problem via mixins.  It gets pretty interesting&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joshua</title>
		<link>http://elegantcode.com/2007/12/02/multiple-inheritance-and-mixins/comment-page-1/#comment-22010</link>
		<dc:creator>Joshua</dc:creator>
		<pubDate>Tue, 27 May 2008 19:32:39 +0000</pubDate>
		<guid isPermaLink="false">http://elegantcode.com/2007/12/02/multiple-inheritance-and-mixins/#comment-22010</guid>
		<description>I use AspectJ to automate the publish and subscribe mechanisms in my Java Beans.  For example given a few annotations my aspects are able to inject code that will handle the PropertyEvent propagation (no containers needed) on bean property changes.  I can apply different annotations for different domains for which the beans are going to be deployed.  Overall I love AOP and the AspectJ project.  I hope to see a language with AOP concepts in the future.</description>
		<content:encoded><![CDATA[<p>I use AspectJ to automate the publish and subscribe mechanisms in my Java Beans.  For example given a few annotations my aspects are able to inject code that will handle the PropertyEvent propagation (no containers needed) on bean property changes.  I can apply different annotations for different domains for which the beans are going to be deployed.  Overall I love AOP and the AspectJ project.  I hope to see a language with AOP concepts in the future.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Trevor Adams</title>
		<link>http://elegantcode.com/2007/12/02/multiple-inheritance-and-mixins/comment-page-1/#comment-16326</link>
		<dc:creator>Trevor Adams</dc:creator>
		<pubDate>Tue, 04 Dec 2007 06:47:33 +0000</pubDate>
		<guid isPermaLink="false">http://elegantcode.com/2007/12/02/multiple-inheritance-and-mixins/#comment-16326</guid>
		<description>I just finished teaching a class at BSU on Aspect Priented Programming using AspectJ. While I thought it was a cool technique, I also was at a loss for a real life application of this technique that you couldn&#039;accomplish some other way. The obvious examples that you mentioned, logging/emailing sure seem powerful, but I can&#039;t help be a bit cautious of &quot;folding&quot; or &quot;mixing&quot; code into my classes at runtime.

With that said, you could use this technique to various strategy patterns or visitor patterns to perform different functionality based upon runtime conditions. I my opinion, the trick is finding functionality that would be shared among various classes or pinpoints/shared points that it would make sense. Perhaps it could be useful for creating different shippable versions of a product or functionality that could be turned on or off at runtime. 

All in all however, I can&#039;t help thinking, &quot;that&#039;s a cool tool to have in the tool chest, I wonder what I&#039;d ever use it for?&quot; Sure, it has potential for reducing duplicated code, at the same time, it has potential to proliferate bugs thoughout your application with only a few short lines of code.

Oh, I just thought of a useful case ... how about logging, or maybe sending email!  

Take care Alex, I hope all is well in your world. (I haven&#039;t forgotten, I still owe you a steak dinner!)

T-</description>
		<content:encoded><![CDATA[<p>I just finished teaching a class at BSU on Aspect Priented Programming using AspectJ. While I thought it was a cool technique, I also was at a loss for a real life application of this technique that you couldn&#8217;accomplish some other way. The obvious examples that you mentioned, logging/emailing sure seem powerful, but I can&#8217;t help be a bit cautious of &#8220;folding&#8221; or &#8220;mixing&#8221; code into my classes at runtime.</p>
<p>With that said, you could use this technique to various strategy patterns or visitor patterns to perform different functionality based upon runtime conditions. I my opinion, the trick is finding functionality that would be shared among various classes or pinpoints/shared points that it would make sense. Perhaps it could be useful for creating different shippable versions of a product or functionality that could be turned on or off at runtime. </p>
<p>All in all however, I can&#8217;t help thinking, &#8220;that&#8217;s a cool tool to have in the tool chest, I wonder what I&#8217;d ever use it for?&#8221; Sure, it has potential for reducing duplicated code, at the same time, it has potential to proliferate bugs thoughout your application with only a few short lines of code.</p>
<p>Oh, I just thought of a useful case &#8230; how about logging, or maybe sending email!  </p>
<p>Take care Alex, I hope all is well in your world. (I haven&#8217;t forgotten, I still owe you a steak dinner!)</p>
<p>T-</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alex Mueller</title>
		<link>http://elegantcode.com/2007/12/02/multiple-inheritance-and-mixins/comment-page-1/#comment-16324</link>
		<dc:creator>Alex Mueller</dc:creator>
		<pubDate>Tue, 04 Dec 2007 02:29:58 +0000</pubDate>
		<guid isPermaLink="false">http://elegantcode.com/2007/12/02/multiple-inheritance-and-mixins/#comment-16324</guid>
		<description>For example, we have an application that has any number of DAL calls, and every time we delete an object, we want to notify someone for the next week with status messages. I say for the next week because this could be temporary, and we neither have the time nor desire to modify all of our DAL&#039;s Delete methods. Adding a logging responsibility to each of our DAO classes violates SRP. Ideally, it would be great if each of our DAO classes could inherit extra functionality at runtime. 

Each time our DAO object&#039;s Delete method is called, we execute our additional functionality. Essentially, we are inheriting (mixing) functionality at runtime. Since we cannot have interfaces with implementations in C#/Java, we create an interface and an implementation, and then (using Aspect#, Spring.net, or no framework at all) we intercept calls for Delete and apply the new functionality.

Does this make sense? I can provide code if needed. The implementations between Aspect# and Sprint.net are different, and the latter would not be a quick example for a blog post.</description>
		<content:encoded><![CDATA[<p>For example, we have an application that has any number of DAL calls, and every time we delete an object, we want to notify someone for the next week with status messages. I say for the next week because this could be temporary, and we neither have the time nor desire to modify all of our DAL&#8217;s Delete methods. Adding a logging responsibility to each of our DAO classes violates SRP. Ideally, it would be great if each of our DAO classes could inherit extra functionality at runtime. </p>
<p>Each time our DAO object&#8217;s Delete method is called, we execute our additional functionality. Essentially, we are inheriting (mixing) functionality at runtime. Since we cannot have interfaces with implementations in C#/Java, we create an interface and an implementation, and then (using Aspect#, Spring.net, or no framework at all) we intercept calls for Delete and apply the new functionality.</p>
<p>Does this make sense? I can provide code if needed. The implementations between Aspect# and Sprint.net are different, and the latter would not be a quick example for a blog post.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: David Starr</title>
		<link>http://elegantcode.com/2007/12/02/multiple-inheritance-and-mixins/comment-page-1/#comment-16321</link>
		<dc:creator>David Starr</dc:creator>
		<pubDate>Mon, 03 Dec 2007 16:33:32 +0000</pubDate>
		<guid isPermaLink="false">http://elegantcode.com/2007/12/02/multiple-inheritance-and-mixins/#comment-16321</guid>
		<description>Can you give an example of an interface that would typify the Mixin technique?</description>
		<content:encoded><![CDATA[<p>Can you give an example of an interface that would typify the Mixin technique?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
