2 ms·
To me it seems that you (in your code example) have just split the function in two. Two thirds of the parameters are given to the constructor and the last one t
by rapala 14y ago
To me it seems that you (in your code example) have just split the function in two. Two thirds of the parameters are given to the constructor and the last one to the method. It might be what your application needs, but it seems arbitrary taken out of context.
In some other language one could implement this with a function returning a function and it would be about the same as declaring the fields in your example final:
(defn publisher [repository clock]
(fn [id]
(publish repository id (now clock))))
- lusr 14y agoYour "function returning a function" is a closure, and yup the class's instance variables act much like a (mutable) closure here. The clever bit is that the consumer (e.g. a web callback or UI event handler) of IArticleService is not the constructor of ArticleService. The consumer simply receives a reference to an IArticleService and uses it, while the constructor of the service knows how to wire things up and hand out service references to consumers that need it so that the consumers don't need to know how to do the wiring up; this is precisely what a dependency injection engine does. It's the difference between you walking to a Post Office and saying "mail(this envelope)" and you saying "mail(this envelope, put it into truck x, route it via [A, B, C, D], find it in the corner of truck D weeks later and route it through E, give it to Alice to give to Bob to place it in the customer's post office box)". Somebody constructed the Post Office with all these rules encapsulated and you just consume the service. It's the reason society can scale despite nobody knowing how everything works exactly, and the same principles apply to creating maintainable code that scales among many developers of varying degrees of skill.