<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.0.2" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Embedded factories</title>
	<link>http://tech.puredanger.com/2007/10/18/embedded-factories/</link>
	<description>Alex Miller's technical blog</description>
	<pubDate>Thu, 20 Nov 2008 17:18:55 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.2</generator>

	<item>
		<title>by: Bob Lee</title>
		<link>http://tech.puredanger.com/2007/10/18/embedded-factories/#comment-10993</link>
		<pubDate>Thu, 18 Oct 2007 20:50:34 +0000</pubDate>
		<guid>http://tech.puredanger.com/2007/10/18/embedded-factories/#comment-10993</guid>
					<description>Nice pattern, Alex! I've long wanted to put static factory methods on interfaces, but this is definitely a nice alternative. I don't know why I didn't think of putting nested classes in interfaces. This would work equally well for builders.

I prefer Guice generally, but this will work great in simple situations.</description>
		<content:encoded><![CDATA[<p>Nice pattern, Alex! I&#8217;ve long wanted to put static factory methods on interfaces, but this is definitely a nice alternative. I don&#8217;t know why I didn&#8217;t think of putting nested classes in interfaces. This would work equally well for builders.</p>
<p>I prefer Guice generally, but this will work great in simple situations.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Reinier Zwitserloot</title>
		<link>http://tech.puredanger.com/2007/10/18/embedded-factories/#comment-10984</link>
		<pubDate>Thu, 18 Oct 2007 19:33:37 +0000</pubDate>
		<guid>http://tech.puredanger.com/2007/10/18/embedded-factories/#comment-10984</guid>
					<description>This is useful, but on the topic of allowing static methods in interfaces, I ask: Why not.

It's very useful not just for this, but also for utility methods that are designed to operate on the interface. For example, I don't know about you, but in my book, &quot;Collections.sort(someList);&quot; is just an ugly ugly hack. List.sort(someList) would have been better. someList.sort() would have been best. But, because that last one is a lot more difficult to accomplish, List.sort(someList) seems the best for now. But you can't write that, because you can't have static methods in interfaces.

The rules would be simple:

1. static methods in interfaces -must- be defined, and

2. If there is a call ambiguity, it's a compile time error to call it at all.

#2 exists for an unfortunate coincidence: With defined methods in an interface, combined with the unfortunate rule that in java, even static methods exhibit a certain amount of inheritance (if you extend class X, where X.foobar() is a valid method, than Y.foobar() will also 'find' X.foobar), you can create multiple inheritance annoyances.

e.g:

public interface X { public static void foobar() {} }

public interface Y { public static void foobar() {} }

public class Z implements X, Y {}

Which foobar is triggered by Z.foobar()?

That's what #2 is for. It's very rare because there aren't many good reasons to call foobar by invoking Z instead of the real X or Y. It won't change depending on the runtime instance.</description>
		<content:encoded><![CDATA[<p>This is useful, but on the topic of allowing static methods in interfaces, I ask: Why not.</p>
<p>It&#8217;s very useful not just for this, but also for utility methods that are designed to operate on the interface. For example, I don&#8217;t know about you, but in my book, &#8220;Collections.sort(someList);&#8221; is just an ugly ugly hack. List.sort(someList) would have been better. someList.sort() would have been best. But, because that last one is a lot more difficult to accomplish, List.sort(someList) seems the best for now. But you can&#8217;t write that, because you can&#8217;t have static methods in interfaces.</p>
<p>The rules would be simple:</p>
<p>1. static methods in interfaces -must- be defined, and</p>
<p>2. If there is a call ambiguity, it&#8217;s a compile time error to call it at all.</p>
<p>#2 exists for an unfortunate coincidence: With defined methods in an interface, combined with the unfortunate rule that in java, even static methods exhibit a certain amount of inheritance (if you extend class X, where X.foobar() is a valid method, than Y.foobar() will also &#8216;find&#8217; X.foobar), you can create multiple inheritance annoyances.</p>
<p>e.g:</p>
<p>public interface X { public static void foobar() {} }</p>
<p>public interface Y { public static void foobar() {} }</p>
<p>public class Z implements X, Y {}</p>
<p>Which foobar is triggered by Z.foobar()?</p>
<p>That&#8217;s what #2 is for. It&#8217;s very rare because there aren&#8217;t many good reasons to call foobar by invoking Z instead of the real X or Y. It won&#8217;t change depending on the runtime instance.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Alex</title>
		<link>http://tech.puredanger.com/2007/10/18/embedded-factories/#comment-10982</link>
		<pubDate>Thu, 18 Oct 2007 18:19:09 +0000</pubDate>
		<guid>http://tech.puredanger.com/2007/10/18/embedded-factories/#comment-10982</guid>
					<description>@Ted: Can't say I like that any better than any other singleton I've ever seen... :)  

@Caoyuan: Gotcha, won't work for that.  I've been meaning to try out that ServiceLoader stuff for a while....if only I was on Java 6.</description>
		<content:encoded><![CDATA[<p>@Ted: Can&#8217;t say I like that any better than any other singleton I&#8217;ve ever seen&#8230; :)  </p>
<p>@Caoyuan: Gotcha, won&#8217;t work for that.  I&#8217;ve been meaning to try out that ServiceLoader stuff for a while&#8230;.if only I was on Java 6.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Caoyuan</title>
		<link>http://tech.puredanger.com/2007/10/18/embedded-factories/#comment-10979</link>
		<pubDate>Thu, 18 Oct 2007 17:02:09 +0000</pubDate>
		<guid>http://tech.puredanger.com/2007/10/18/embedded-factories/#comment-10979</guid>
					<description>Alex,

Your method is suitable for these singletons. What I encounter is bit a different, the interface and the implementation should be separated in different packages based on in NetBeans Module mechanism, or someting called super package, which is also under a JSP.</description>
		<content:encoded><![CDATA[<p>Alex,</p>
<p>Your method is suitable for these singletons. What I encounter is bit a different, the interface and the implementation should be separated in different packages based on in NetBeans Module mechanism, or someting called super package, which is also under a JSP.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Ted</title>
		<link>http://tech.puredanger.com/2007/10/18/embedded-factories/#comment-10977</link>
		<pubDate>Thu, 18 Oct 2007 16:07:04 +0000</pubDate>
		<guid>http://tech.puredanger.com/2007/10/18/embedded-factories/#comment-10977</guid>
					<description>This is how I've done singletons for many years:

public interface Foo
{
    // methods for interface Foo ...

    static class Singleton
    {
        private static Foo instance;

        public static void set( final Foo foo )
        {
            if( instance == null )
                instance = foo;
        }

        public static Foo get()
        {
            return instance;
        }
    }
}

Then, somewhere in bootstrapping of the app (say a ServletContextListener in a webapp):

Foo.Singleton.set( new FooImpl() );</description>
		<content:encoded><![CDATA[<p>This is how I&#8217;ve done singletons for many years:</p>
<p>public interface Foo<br />
{<br />
    // methods for interface Foo &#8230;</p>
<p>    static class Singleton<br />
    {<br />
        private static Foo instance;</p>
<p>        public static void set( final Foo foo )<br />
        {<br />
            if( instance == null )<br />
                instance = foo;<br />
        }</p>
<p>        public static Foo get()<br />
        {<br />
            return instance;<br />
        }<br />
    }<br />
}</p>
<p>Then, somewhere in bootstrapping of the app (say a ServletContextListener in a webapp):</p>
<p>Foo.Singleton.set( new FooImpl() );
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
