4 ms·
I don't think I agree with the fact that every time you isolate a piece of logic you add a layer. But I don't think I have a solid argument for that yet :) You
by alisnic 14y ago
I don't think I agree with the fact that every time you isolate a piece of logic you add a layer. But I don't think I have a solid argument for that yet :)
You do make a good point though that in having many small objects is easy to mess with external dependencies. But in my case, the testing always suggested if I had done something like that, and I improved. If an object becomes hard to test in isolation, then something has been done wrong.
- Firehed 14y agoOh, I don't think isolating logic necessarily adds a layer, unless you go overboard with isolating it. I think we're probably caught up on the subtle differences between encapsulation and abstraction. There seems to be a point where "I can't figure out what's happening here without an IDE" starts to happen, which is a) relatively subjective and b) sometimes a necessary side-effect. I only care when it's hard to test something in isolation when it's actually used in isolation. A private method, for example, exists only to be used by another component; it often makes little sense to test independently, and when it does it's easy to wrap in a public call that asserts that it's being run by a unit test. But I think a lot of this is theoretical code purity vs prioritizing business goals. All else being equal I'd love a perfectly-factored codebase, but at the end of the day I have to target high-friction, high-confusion areas of the codebase to refactor because those are the ones that get in the way of building stuff for our customers, or cause the most production bugs.