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

Reply via email to