i'm with substack here. my arguments on this are:
the HOW instances are created and IF it's a singleton or not are, in fact,
implementation details and should be hidden most of the time from the user.
when i var foo = require('something') , then it's not obvious, that this is
a constructor. a factory function is in 99% of the time clear.
factory functions help to abstract away the details, so it is easier to
exchange the hidden parts. This argument is not that important in js as it
is in static typed langs, but still valid.
on the other side i also think Rick and Mikeal are right regarding style
and amount of code to maintain. a thing like that:
module.exports = function createLogger(){ return
require('customLogger').createLogger()}
is awful. a factory function should definitely do something more than just
return it's product.
and about static init, what i did about it in a lib: the main entrypoint of
the whole package was a function which took configuration and returned a
factory function. the user required the package once and re-exported the
returned factory function. usage:
reexport.js:
module.exports = require('thelib')({/*annoying options*/})
myLogic.js:
var someWorkingFunc = require('./reexport')()
the user may one or more independently configured factories of the lib and
use them in different ways. (and can wrap it's own favorite api-style
around mine for internal code.)
PS: this is also one way to do simple DI:
module.exports = function entry(preferredChannel){
preferredChannel = preferredChannel ||
fs.createWriteStream('/var/log/myapp')
return function getLogger(loggerLevel){return new
AwesomeLogger(preferredChannel, loggerLevel)}
}
Am Sonntag, 24. März 2013 07:41:13 UTC+1 schrieb substack:
>
> On Saturday, March 23, 2013 5:22:12 PM UTC-7, Rick Waldron wrote:
>
>> Why do module authors make gross factory APIs?
>>
>> Instead of wrapping the export in this icky "createLogger" method, that
>> doesn't do _anything_ (one assumes a factory exists to provide some
>> additional layer of logic over the base constructor, or else what is the
>> point?), why not export the constructor?
>>
>> var logger = new bunyan.Logger();
>>
>> Yay, much nicer.
>>
>
> It's something of an imposition on downstream consumers of a library to
> need to remember which functions return objects and which instantiate
> instances. I like it much better when modules just expose functions that
> return objects. Whether or not some "constructor" or "factory" is at work
> is not something that I as a module consumer should need to care about
> because that is an implementation detail that the module author should be
> concerned with, not me as the consumer.
>
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
