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???
>
