3 ms·
I assume the point is to let any one of the steps turn into something more complex and automated, as they say, without affecting the rest of the script. If each
by dullcrisp 5y ago
I assume the point is to let any one of the steps turn into something more complex and automated, as they say, without affecting the rest of the script. If each step is its own class, that gives you a place to go in and expand any one of them without worrying about conflicting with unrelated changes.
If the idea were to leave the script as it is, then of course your way is simpler.
- geysersam 5y agoI see what you mean. But in Python a function can be turned into a full fledged callable class at a later point without any change to the rest of the script. Not that it matters much either way.
- sullyj3 5y agoSeems like premature abstraction to me. It's not difficult to make that change if you need it. In any case, I'm really struggling to envisage a scenario where you would need them to be classes - why couldn't a more automatic version still be a function? In my opinion, in order to justify instantiating an object, it should actually contain data, and that data should actually be accessed by code other than methods internal to that class. This rules out using an object to represent a procedure - regular functions subsume that functionality. Before first class functions became commonplace, it did make sense to use objects as procedures in some OO languages, to allow you to pass them around as values. Since most languages these days do have first class functions, this has become less necessary. If you want a class in order to to split the procedure into multiple methods with access to shared mutable state, that's totally fine - you can just use nested functions to do the same thing.