<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>BasePatterns.org</title>
	<atom:link href="http://basepatterns.org/feed/" rel="self" type="application/rss+xml" />
	<link>http://basepatterns.org</link>
	<description>Trends in software design</description>
	<lastBuildDate>Tue, 18 Oct 2011 03:17:34 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
		<item>
		<title>Prevent multiple instances of an application</title>
		<link>http://basepatterns.org/2011/10/prevent-multiple-instances-of-an-application/</link>
		<comments>http://basepatterns.org/2011/10/prevent-multiple-instances-of-an-application/#comments</comments>
		<pubDate>Tue, 18 Oct 2011 03:11:38 +0000</pubDate>
		<dc:creator>fortuna</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[application]]></category>
		<category><![CDATA[groovy]]></category>
		<category><![CDATA[sockets]]></category>

		<guid isPermaLink="false">http://basepatterns.org/?p=143</guid>
		<description><![CDATA[A simple way to prevent running of multiple instances of your application is to use Socket communication. For example, in Groovy the first thing you would execute is something like this: Following this, another block of code initialises the server socket to indicate an instance is running: Of course the same can be done in [...]]]></description>
		<wfw:commentRss>http://basepatterns.org/2011/10/prevent-multiple-instances-of-an-application/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Service Selector</title>
		<link>http://basepatterns.org/2009/11/service-selector/</link>
		<comments>http://basepatterns.org/2009/11/service-selector/#comments</comments>
		<pubDate>Mon, 02 Nov 2009 03:43:24 +0000</pubDate>
		<dc:creator>fortuna</dc:creator>
				<category><![CDATA[Java]]></category>
		<category><![CDATA[patterns]]></category>
		<category><![CDATA[proxy]]></category>

		<guid isPermaLink="false">http://basepatterns.org/?p=115</guid>
		<description><![CDATA[Sometimes we may have more than one implementation and/or instance of a service to which we need to route requests. Routing may be controlled by a number of different factors, such as the request type, request arguments, runtime configuration, etc.

An implementation of such routing might look something like this:

[java]
public interface SomeService {
  void someMethod();
}

public class RoutingSomeService implements SomeService {

  private Map<String, SomeService> delegates = ...

  private String activeDelegateId = ...

  public void someMethod() {
    SomeService delegate = delegates.get(activeDelegateId);
    if (delegate != null) {
      delegate.someMethod();
    }
    else {
      // XXX: throw runtime exception???
    }
  }
}
[/java]]]></description>
		<wfw:commentRss>http://basepatterns.org/2009/11/service-selector/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Uniform Caching</title>
		<link>http://basepatterns.org/2009/10/uniform-caching/</link>
		<comments>http://basepatterns.org/2009/10/uniform-caching/#comments</comments>
		<pubDate>Tue, 13 Oct 2009 01:14:42 +0000</pubDate>
		<dc:creator>fortuna</dc:creator>
				<category><![CDATA[Java]]></category>
		<category><![CDATA[adapter]]></category>
		<category><![CDATA[caching]]></category>
		<category><![CDATA[patterns]]></category>

		<guid isPermaLink="false">http://basepatterns.org/?p=101</guid>
		<description><![CDATA[Typically object caching in Java is managed by the container or framework in use. Occasionally however there is a need to manually cache domain-specific objects, whereby a java.util.Map implementation will not suffice. Using the popular ehcache framework as an example, the following pattern is typically observed: The common aspects of this pattern are as follows: [...]]]></description>
		<wfw:commentRss>http://basepatterns.org/2009/10/uniform-caching/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Whiteboard Registry</title>
		<link>http://basepatterns.org/2009/10/whiteboard-registry/</link>
		<comments>http://basepatterns.org/2009/10/whiteboard-registry/#comments</comments>
		<pubDate>Thu, 08 Oct 2009 06:59:44 +0000</pubDate>
		<dc:creator>fortuna</dc:creator>
				<category><![CDATA[Java]]></category>
		<category><![CDATA[osgi]]></category>
		<category><![CDATA[patterns]]></category>
		<category><![CDATA[registry]]></category>
		<category><![CDATA[whiteboard]]></category>

		<guid isPermaLink="false">http://basepatterns.org/?p=86</guid>
		<description><![CDATA[In OSGi using a publisher/subscriber design can be somewhat more complicated that traditional Java environments: To overcome these hurdles the Whiteboard Pattern prescribes registering listeners in the service registry as opposed to services, whereby services can publish events to available listeners at the time of the event. The problem with the Whiteboard Pattern is that [...]]]></description>
		<wfw:commentRss>http://basepatterns.org/2009/10/whiteboard-registry/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>OSGi Service Locator</title>
		<link>http://basepatterns.org/2009/09/osgi-service-locator/</link>
		<comments>http://basepatterns.org/2009/09/osgi-service-locator/#comments</comments>
		<pubDate>Wed, 30 Sep 2009 01:27:10 +0000</pubDate>
		<dc:creator>fortuna</dc:creator>
				<category><![CDATA[Java]]></category>
		<category><![CDATA[osgi]]></category>
		<category><![CDATA[patterns]]></category>
		<category><![CDATA[service locator]]></category>

		<guid isPermaLink="false">http://basepatterns.org/?p=74</guid>
		<description><![CDATA[The Service Locator pattern is a well-established mechanism for accessing local and remote services in a consistent manner: Using a structured service name interface we can improve uniformity and reduce the potential for typos: In an OSGi environment, the recommended approach for retrieving services is via the org.osgi.util.tracker.ServiceTracker class: We can combine these two patterns [...]]]></description>
		<wfw:commentRss>http://basepatterns.org/2009/09/osgi-service-locator/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Uniform Logging</title>
		<link>http://basepatterns.org/2009/09/uniform-logging/</link>
		<comments>http://basepatterns.org/2009/09/uniform-logging/#comments</comments>
		<pubDate>Fri, 25 Sep 2009 02:37:46 +0000</pubDate>
		<dc:creator>fortuna</dc:creator>
				<category><![CDATA[Java]]></category>
		<category><![CDATA[adapter]]></category>
		<category><![CDATA[logging]]></category>
		<category><![CDATA[patterns]]></category>

		<guid isPermaLink="false">http://basepatterns.org/?p=45</guid>
		<description><![CDATA[Application logging always seems to become one of those code smells, typically regarding duplication of code, or conversely, non-uniform log messages. There are many different ways to log a message in Java, but variations on the following pattern are common: The following information can be extracted from this pattern: Category &#8211; classification for log entries [...]]]></description>
		<wfw:commentRss>http://basepatterns.org/2009/09/uniform-logging/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>In the beginning..</title>
		<link>http://basepatterns.org/2008/02/in-the-beginning/</link>
		<comments>http://basepatterns.org/2008/02/in-the-beginning/#comments</comments>
		<pubDate>Sun, 17 Feb 2008 13:31:38 +0000</pubDate>
		<dc:creator>fortuna</dc:creator>
				<category><![CDATA[Design]]></category>
		<category><![CDATA[Software]]></category>

		<guid isPermaLink="false">http://blogs.modularity.net.au/thenextbigthing/?p=26</guid>
		<description><![CDATA[Ok, so it&#8217;s been a while since I paid any attention to this blog &#8211; not that I have nothing to say, but rather that I couldn&#8217;t decide what demands the most attention. I also want to ease up on the hostility expressed in a number of previous posts, as there&#8217;s probably enough people complaining [...]]]></description>
		<wfw:commentRss>http://basepatterns.org/2008/02/in-the-beginning/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>The Return of the Architect</title>
		<link>http://basepatterns.org/2007/03/dont-forget/</link>
		<comments>http://basepatterns.org/2007/03/dont-forget/#comments</comments>
		<pubDate>Fri, 23 Mar 2007 03:35:08 +0000</pubDate>
		<dc:creator>fortuna</dc:creator>
				<category><![CDATA[Design]]></category>
		<category><![CDATA[Software]]></category>

		<guid isPermaLink="false">http://blogs.modularity.net.au/thenextbigthing/?p=14</guid>
		<description><![CDATA[When designing a software architecture it is important to maintain a focus on the problem you are trying to solve. Without this focus you will most likely diverge from the original goals, resulting in a solution that may not represent the best approach to solving the problem at hand. Often is the case that JEE [...]]]></description>
		<wfw:commentRss>http://basepatterns.org/2007/03/dont-forget/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Every man and his blog</title>
		<link>http://basepatterns.org/2007/02/every-man-and-his-dog/</link>
		<comments>http://basepatterns.org/2007/02/every-man-and-his-dog/#comments</comments>
		<pubDate>Mon, 19 Feb 2007 05:15:35 +0000</pubDate>
		<dc:creator>fortuna</dc:creator>
				<category><![CDATA[Build]]></category>
		<category><![CDATA[Design]]></category>
		<category><![CDATA[Software]]></category>

		<guid isPermaLink="false">http://blogs.modularity.net.au/thenextbigthing/?p=20</guid>
		<description><![CDATA[If there is one thing in abundance in software development it is opinions. From which technology to use (languages, frameworks, libraries, etc.), to architectural design (everyone&#8217;s an architect!), to the user interface layout, it is never hard to find opinions. One thing that is rare however, is a firm grasp on reality when it comes [...]]]></description>
		<wfw:commentRss>http://basepatterns.org/2007/02/every-man-and-his-dog/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Software Longevity</title>
		<link>http://basepatterns.org/2007/02/software-immortality/</link>
		<comments>http://basepatterns.org/2007/02/software-immortality/#comments</comments>
		<pubDate>Tue, 13 Feb 2007 13:36:27 +0000</pubDate>
		<dc:creator>fortuna</dc:creator>
				<category><![CDATA[Open Source]]></category>
		<category><![CDATA[Software]]></category>

		<guid isPermaLink="false">http://blogs.modularity.net.au/thenextbigthing/?p=19</guid>
		<description><![CDATA[All software has a lifespan. The three primary factors that control this lifespan are the popularity of the software; it&#8217;s usefulness, and the lifespan of the controlling company. Whilst the first two factors are common to all software, the third is one of the primary differentiating factors between proprietary and Open Source software. A measure [...]]]></description>
		<wfw:commentRss>http://basepatterns.org/2007/02/software-immortality/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

