I really like the Fluent pattern as it is done in C# and Java...
I'm not sure the juice is worth the squeeze in an existing c++ library.
I do agree we should normalize our factory/builder patterns.
On Wed, Sep 6, 2017 at 12:28 PM, Jacob Barrett <jbarr...@pivotal.io> wrote:
> Mark,
>
> I believe the real issue is that we use multiple patterns and should be
> converging on one pattern. We have examples of both Factory and Builder
> models and both with and without Fluent pattern.
>
> If the Java API is tending towards Builder model with Fluent pattern then I
> am for that as long as this common practice in the C++ world. In my
> searching I don't see any strong tendency towards any one model or pattern
> in the C++ world. The only real trick to the Fluent pattern in C++ is what
> is the type of the return value? Is it &, *, or some smart pointer? I would
> expect it be a ref. My only issue with this is that if the original factory
> variable is a pointer then the operator changes, for example:
> prtToCachFactory->setSomething("arrow").setSomethingElse("dot");
>
> It also needs to be VERY clear in the docs is the builder could ever return
> something other than a reference to the original instance of the builder. I
> have seen models where it is possible so you have to do things like to
> guard against the return changing:
> auto cacheFactory = CacheFactory().setSomething().setSomethingElse();
> if (somethingMore) {
> cacheFactory = cacheFactory.setSomethingMore();
> }
> auto cache = cacheFactory.create();
>
> If you have to do that then it because less desirable to have the fluent
> pattern because it is prone to error and less readable. We should guarantee
> something like this will work:
> auto cacheFactory = CacheFactory().setSomething().setSomethingElse();
> if (somethingMore) {
> cacheFactory.setSomethingMore();
> }
> auto cache = cacheFactory.create();
>
> -Jake
>
>
>
>
> On Wed, Sep 6, 2017 at 10:38 AM Darrel Schneider <dschnei...@pivotal.io>
> wrote:
>
> > In the geode java apis you would create a CacheFactory (or
> > ClientCacheFactory), configure it fluently, and then call create at the
> > end. So even though we call them factories in the geode java apis, they
> use
> > the Builder pattern and also support the fluent model in that you could
> do
> > this:
> > ClientCache cache = new ClientCacheFactory().set("propName",
> > "propValue").addPoolLocator("addr", 10678).create();
> >
> > Also in java the DistributedSystem is hidden under the Cache. So you add
> > config to your CacheFactory and when you create it, it will also connect
> > the DistributedSystem. It used to be that in java you had to connect the
> > DistributedSystem first and then the Cache. Since the DistributedSystem
> is
> > never used apart for a Cache I think this simplification was helpful to
> > users.
> >
> > On Wed, Sep 6, 2017 at 10:13 AM, Mark Hanson <mhan...@pivotal.io> wrote:
> >
> > > Problem:
> > >
> > > To fluent and builder model or not to fluent and builder model.... In
> the
> > > native client
> > >
> > > we use the factory model of generating objects, we are wondering if a
> > move
> > > to the fluent model
> > >
> > > and the builder pattern would be better.
> > >
> > >
> > > Background:
> > >
> > > In designing the various types of allocators for our objects, we have
> > > considered
> > >
> > > whether or not use the builder and fluent patterns instead of the
> Factory
> > > pattern.
> > >
> > > The current code base is written following the factory pattern, but it
> > > seems that
> > >
> > > the Builder pattern is becoming more popular. Further, people are also
> > > using the
> > >
> > > fluent model as well.
> > >
> > > Discussion:
> > >
> > > The argument for the Builder pattern is that it allows greater
> > > specification before the actual
> > >
> > > creation of the object. For example, Factory often focuses on the
> > > attributes
> > >
> > > after the creation of the object. The Builder pattern allows one to set
> > the
> > >
> > > attributes before the creation of the object, allowing a more specific
> > > object
> > >
> > > to be generated. Currently code is written to the Factory pattern.
> > >
> > > Consider the following case of connecting to a cache.
> > >
> > > Our current pattern (Factory)
> > >
> > > CacheFactoryPtr cacheFactory = CacheFactory::createCacheFactory();
> > >
> > > CachePtr cache = cacheFactory->create();
> > >
> > > cache->getDistributedSystem().Credentials(“emma”, “pizza”);
> > >
> > > cache->getDistributedSystem().connect();
> > >
> > > API Used:
> > >
> > > bool DistributedSystem::Credentials(String, String)
> > >
> > > void DistributedSystem::connect()
> > >
> > > Cache CacheFactory::create()
> > >
> > > Builder pattern
> > >
> > > CacheFactory cf = new CacheFactory();
> > >
> > > cf.Locator(“192.168.0.5”, 10334);
> > >
> > > cf.Credentials(“emma”, “pizza”);
> > >
> > > Cache cache = cf.Connect();
> > >
> > > API Used:
> > >
> > > bool Locator(String, String)
> > >
> > > bool Credentials(String, String)
> > >
> > > Cache Connection()
> > >
> > >
> > > Next up we think the real direction lies in further incorporating the
> > > fluent model
> > >
> > >
> > >
> > > Fluent model
> > >
> > > Cache cache = new CacheFactory()->Locator(“192.168.0.5",
> > > 10334).Credentials(“emma”, “pizza”).Connect();
> > >
> > > API Used:
> > >
> > > CacheFactory Locator(String, String)
> > >
> > > CacheFactory Credentials(String, String)
> > >
> > > Cache Connection()
> > >
> > > Do people see value in heading this direction? Sufficient value to
> > rewrite
> > > the API for Geode Native for example?
> > >
> > >
> > >
> > > Conclusion
> > >
> > > We need input to decide the future direction. What do people think???
> > >
> >
>
