I have accomplished what I needed by borrowing from the Singleton idea, my
pattern being
http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns.html
I have a private variable called instance, a public getInstance() method
that checks whether it's instantiated and returns it, and the constructors
are now protected.
But it's not a true Singleton because the descendants (PageDrawer,
PDFTextStripper, etc.) still have public constructors.
In a single-threaded environment, I don't think that matters. I think it is
practically a singleton in those situations.
But what about a multi-threaded environment?
class AlmostSingleton{
private static AlmostSingleton instance;
protected AlmostSingleton(){
instance = this;
}
public AlmostSingleton getInstance(){
if (instance == null) instance = new AlmostSingleton();
return instance;
}
}
class Child1 extends AlmostSingleton{
public Child1() {
//do whatever in constructor
}
}
Now ... if 2 different threads instantiate Child1 and call getInstance(),
are they looking at the same instance or different ones?
If the same, my static getInstance() causes a real problem.
Making the descendants of PDFStreamEngine have private / protected
constructors would break a lot of client applications. Obviously we can't
go there.
On Thu, Apr 23, 2009 at 2:10 PM, Daniel Wilson <
[email protected]> wrote:
> I am working through the implementation details of making PDFStreamEngine a
> singleton.
>
> I would like to do so because I need for the PDXObjectImage to be able to
> get the current nonstroking colorspace.
>
> The call
> *CS =
> PDFStreamEngine.getInstance().getGraphicsState().getNonStrokingColorSpace();
> *
> would solve this very nicely.
>
> My understanding is that there is really only one PDFStreamEngine (or
> descendant thereof) in existence (within a particular thread's context)
> anyway.
>
> Does anyone see a problem with making PDFStreamEngine a singleton? A big
> theoretical problem, a reason it should not be attempted?
>
> I think I can work through the implementation details, as I said. And I
> will certainly run the junit tests to make sure the thing behaves in all our
> defined scenarios.
>
> Thanks!
>
> Daniel Wilson
>
