3 ms·
I think what you are saying is very valid. Personally, I tend to pull things out into stateful classes (e.g. CommentPoster, OrderMailer, ElephantCleaner, etc) f
by Smudge 14y ago
I think what you are saying is very valid. Personally, I tend to pull things out into stateful classes (e.g. CommentPoster, OrderMailer, ElephantCleaner, etc) for two reasons:
1. Testability. Isolating these bits of application logic and testing them on their own has proven less prone to issues than including it all in, say, controller methods or helpers, which get messy over time.
2. Swappability. Okay, sure, you may never need a second kind of CommentPoster, but you never know. Keeping things like this stateful and properly abstracted out saves me plenty of time as the app's requirements get more complex.
It's not exactly premature optimization if I always follow this pattern and know exactly how it will work. (Sometimes it's just an unused optimization.) To me, there is very little added complexity, and if anything it makes it a bit easier in the long run.
- deleted 14y ago[deleted]
- aphyr 14y ago1. Testing is easier without state. I'm trying to illustrate that state and context (and namespaces) are separable. 2. Swapping implementations is easier: would you rather pass a function, or an object with a single function? This ties back in to testing: it's easier to create a test variant of a function than it is to create a new class. Don't get me wrong: state is great, and I use it all over the place. I generally avoid it, though, unless the state is needed, simpler to understand, or more concise.