6 ms·
It's the same pattern that repeats itself all over the place. We've seen it with Java, with Ruby, heck, even with PHP. And now with JS: As applications grow, we
by pilif 13y ago
It's the same pattern that repeats itself all over the place. We've seen it with Java, with Ruby, heck, even with PHP. And now with JS: As applications grow, we tend to search for tools to help us cope with the growth.
After doing similar (but still slightly different) things over and over, we start building abstractions and with every thing our abstraction can't deal with, we make them more complicated.
Whether you use the official name of your thing ("factory") or you just run with your own idea and term - the outcome is always the same.
As a library, you feel the need to be abstract enough to cope with every feature request ever asked from your library and there will be tons of feature requests and tons of little parts people want to customize.
And honestly, don't we all prefer using some public API of a self-contained library to patching said library (think of the maintenance as that library gets updated)?
This isn't about ruining a language. This is about making the right choice of library or about the decision of building your own little customized thing that exactly fulfills your requirements (and nothing else), but as your requirements change, you're going to add abstractions yourself and suddenly you're back at the AbstractSingletonProxyFactoryBean, though you might have chosen a different name that nobody but your team understands.
As a library author, try to resist the feature creep; try to be opinionated ("I'm really sorry, but logging isn't pluggable. You want to log to your XML based logging server? That's fine, but you'll have to build your own thing or use a different framework") then you remain accessible and buzzword-free, even though that might cost you some users in the short term.
Language has nothing to do with this.
- anon4 13y agoAn abstraction is not useful, in fact it's downright harmful, if it does exactly the same thing as what it abstracts over, but more verbosely. A lot of these patterns you're used to seeing in Java stem from Java's static nature. Here's a car factory in javascript: function makeCar(dealerName) { return new Car(dealerName); } And here's a configured car factory: var myCarProvider = makeCar.bind(null, "my dealer"); It makes precisely zero sense to create abstractions that reimplement core language features. That would be like writing a C function to add two uint8_ts, or a macro that expands to inline assembly to convert a float to an int32_t. You already have these things built-in, you don't need a gorillion enterprisey patterns.
- rafekett 13y agoi don't think you actually understand these patterns or how they're used. it's useful when you have multiple implementations of `Car` that you want to use under different circumstances. Or when `Car` is dependent on static configuration that might depend on the host it's running on, or might be different in development/testing/production.
- tomp 13y agoI don't think you understand functional programming. function makeAppropriateCar(cargo) { if(cargo == "people") return new Automobile(); else if(cargo == "boxes") return new Truck; else ... } function makeLocalCar(settings) { var car = new Car({'color': settings.get('new_car_color')}); car.set_origin(settings.get_hostname()); return car; } function makeDebuggingCar() { if(global_settings.DEBUG && !global_settings.PRODUCTION) return new Car({'loglevel': LOGLEVEL_DEBUG}); else if(global_settings.DEBUG && global_settings.PRODUCTION) // testing return new Car({'loglevel': LOGLEVEL_INFO}); else // production return new Car({'loglevel': LOGLEVEL_WARNING}); }
- rafekett 13y agoOk, now try maintaining that when there are 15 types of cars and cars are used in dozens of services. You're imperatively expressing a dependency graph that you could (and would benefit from) defining declaratively at a larger scale. I'd recommend reading the user guide for Guice for balance before you respond. It's worth seeing how nice DI can be.
- zoomerang 13y agoWhat does your example have to do with functional programming? You've written two factories, pretty much exactly how AngularJS uses them, in an imperative style. Regardless of which, this doesn't in any way solve the issue Angular Services are designed to solve (IoC).
- yesiamyourdad 13y ago
- rbanffy 13y ago> As applications grow, we tend to search for tools to help us cope with the growth. Actually, we tend to search for tools to help us not learn another language better suited to the domain we found ourselves in. The point that JavaScript is prototype-based and, therefore, some of these patterns make little or no sense (or could be expressed in much simpler terms) appears to be lost.
- badman_ting 13y ago"Language has nothing to do with this." Great, thanks. Hey, by any chance do you think there's no single greatest language, and that people should use the right tool for the job? Terrific, me too. Saying "language has nothing to do with this" misses the point of this post entirely. It's about how people bring the same unwieldy practices wherever they go regardless of the language.
- pilif 13y agoThe title of the post was "you have ruined javascript" and I maintain that JS has in-fact not been ruined just the same as all other languages haven't. Abstraction bloat in libraries is not something that's specific to languages and a language can't be ruined by libraries suffering from abstraction bloat (unless all of them suffer cough java cough)