hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ortwin Gl├╝ck <ortwin.glu...@nose.ch>
Subject Re: [PATCH]Protocol take 1
Date Mon, 16 Dec 2002 07:58:34 GMT
About my understanding of the Flyweight pattern.

I assume you all know the Singleton pattern very well; it ensures there 
is only a single instance of a class. The Flyweight pattern is very 
similar: it ensures there is only a single instance per state of a 
class. It is useful when the number of states an instance of a class can 
have is very limited. The pooled objects should be immutable.

Where the Singleton has it's instance() method, a Flyweight has it's 
getInstance(identifier) method. The identifier uniquely identifies the 
complete state of a pooled instance.

The Flyweight pattern allows you to use the (cheap) equality (==) 
operator on instances rather than a (more expensive) equals() method.

I admit this doesn't follow exactly the pattern as it was published in 
the GoF book. But I find this (simplified) variant quite useful here.

Applied to our Protocol class this means we have a Protocol 
getProtocol(String protocol) method and the Contructors are all private. 
There are only two instances of Protocol: one for HTTP and one for HTTPS.

Assotiating a protocol with a SocketFactory seems somewhat unnatural to 
me. So for this particular issue I would prefer a different solution. 
All we really need is something to get a custom SSLSocketFactory from. 
Nothing more.

I hope this clear things up a bit

Odi

Michael Becke wrote:
> I'm not sure Flyweight is appropriate here.  Perhaps I don't understand 
> it correctly, but I though it is meant to be used when there are a large 
> number of objects containing potentially the same data.


Mime
View raw message