I've been reading through the builder pattern and it's not quite clear
to me how this could be made to work. The pattern seems to assume
that the DataNode would know which kind of factory it wants first (one
using ObjectStore or one without).
Another possiblity might be adding methods like
public boolean needsObjectStore(); // recommended default is true
public boolean needsDataRowStore(); // recommended default is false
and calling the appropriate constructor.
DataContext createDataContext(QueryEngine parent);
DataContext createDataContext(QueryEngine parent, ObjectStore objectStore);
DataContext createDataContext(QueryEngine parent, DataRowStore
dataRowStore);
or maybe simply just having what's below and assuming the end-user can
figure out how to get whatever resources are necessary to create an
object store.
public boolean willProvideObjectStore()
DataContext createDataContext(QueryEngine parent);
DataContext createDataContext(QueryEngine parent, ObjectStore objectStore);
if (dataContextFactory.willProvideObjectStore()) {
context = new DataContext(this);
}
else {
context = dataContextFactory.createDataContext(this, new
ObjectStore(snapshotCache));
}
On 9/15/05, Andrus Adamchik <andru..bjectstyle.org> wrote:
> Ok, that's fine - this still leaves an option to override
> ObjectStore, so I am cool with it.
>
> Andrus
>
>
> On Sep 15, 2005, at 6:14 PM, Mike Kienenberger wrote:
>
> > Yeah, it's the " but still..." that could make it harder.
> >
> > I've committed the minimum required for an end-user to create a custom
> > DataContext.
> >
> > Most of us just want to do simple little things like store some extra
> > info in our DataContext or perform some pre- or post-checking on our
> > commitChanges methods.
> >
> > That should be possible without someone having to understand what
> > "SharedSnapshotCache" is. :)
> >
> > Maybe we could provide multiple factory constructors? Either cycle
> > through them until we get a non-null (or non-exception) status or use
> > reflection?
> >
> > Providing some kind of builder (Gee, I keep hoping I'll get a chance
> > to buy and read Design Patterns some day) or at least
> > DataDomain.createObjectStore() method would be very helpful.
> >
> > I think it's a disservice to force the average end-user to do more
> > work than they have to if there's a way to avoid it. Of course, I'm
> > biased, because I'm one of those average-end-users.
> >
> > On 9/15/05, Andrus Adamchik <andru..bjectstyle.org> wrote:
> >
> >>
> >> On Sep 15, 2005, at 5:39 PM, Mike Kienenberger wrote:
> >>
> >>
> >>> We need to support the most common use case (subclassing DataContext
> >>> and making some minor change to it) and that requires that we can
> >>> call
> >>> the same method that would have been called before. Ie,
> >>>
> >>> if (null == dataContextFactory) {
> >>> context = new DataContext(this, new ObjectStore
> >>> (snapshotCache));
> >>> }
> >>> else {
> >>> context = dataContextFactory.createDataContext(this, new
> >>> ObjectStore(snapshotCache));
> >>> }
> >>>
> >>
> >> Creating ObjectStore doesn't adds *that much* complexity to a
> >> potential custom factory, and provides a whole lot of extra
> >> flexibility. If we are going in this direction already, why stop
> >> half-
> >> way? We can post this as an example on Wiki. One extra line of code:
> >>
> >> public DataContext createDataContext(DataDomain parent) {
> >> ObjectStore os = new ObjectStore(parent.getSharedSnapshotCache
> >> ());
> >> return new MyDataContext(parent, os);
> >> }
> >>
> >> Ok, when taking shared cache flag into account, it will be a little
> >> more complex, but still...
> >>
> >>
> >>
> >>> If you want a custom ObjectStore, maybe we need an
> >>> ObjectStoreFactory too :)
> >>>
> >>
> >> Heh, then we need a "builder" object - I guess that's the pattern
> >> name for the "multi-step factory" :-)
> >>
> >> Andrus
> >>
> >>
> >>
> >
> >
>
>
This archive was generated by hypermail 2.0.0 : Thu Sep 15 2005 - 18:30:14 EDT