ES6 classes
Opened this issue · 1 comments
would be better than setting prototype functions, as part of new major release (#20)
I would personally favor a more functional approach, should be possible to make it more functional in a followup stage.
I think an OO approach would better, and I'll explain the rationale:
-
Project appears to be already fairly OO (that is you have a method that returns something an instance of an object, in which you can call methods on)
-
Regardless of the paradigm chosen, holding and managing state will be required (the project data). In a functional approach, this is usually done by either by passing some kind of context object around to functions, or having a function with data encapsulated via a closure, where dynamically allocated methods can have access to (and often return itself so that you can chain methods). I don't really see this very extendable.
The OO approach, which doesn't need to be complicated, that is I don't think we don't need builders or any other fancy design patterns. We just need a class that can be instantiated to encapsulate the project data and provide methods to manipulate the data, which like a functional approach can be changed by simply returning the instance, if desired.
-
For unit testing purposes, it makes it easier to spy on as the jasmine spyOn feature expects an object, and a string as the member function spy on.
-
If we make a move to TypeScript, (which I would also favour eventually) it's easier to manage a single class type rather than series of function types, and having to expose an internal state type. Every function will still have a type declared naturally when authoring a class signature, but the consuming applications/libraries does not need to explicitly import all of these function types.