3 ms·

A plain function has a uniform interface too: just calling it.

by _dain_ 5y ago

Jtsummers 5y ago
True, but that doesn't help you with encapsulation or the other (potential) benefits of using classes like inheritance.
- Too 5y ago
  Local variables inside a function are very much encapsulated. Unless you need to keep state between two distinct actions on the same object, but in that case a single run() entry point will not be sufficient anyway. Inheritance can be replaced by just calling a common function. There are many “what if” here, which will likely never happen and until they do it’s premature abstraction. Most likely some other abstraction is needed by the time script grows.
- _dain_ 5y ago
  "Lots of times people think they might need something later. You don't. Or you can just do it later if it comes up." https://youtu.be/o9pEzgHorH0?t=339 https://youtu.be/o9pEzgHorH0?t=339 For glue code scripts like this you usually don't end up using encapsulation and inheritance or any other fancy OOP design patterns. It's usually grungy IO-bound procedural code, the sort of thing you'd write in bash if bash weren't terrible for long scripts. Don't burden it with premature abstractions. If you end up needing a class, just write the class later.
  - Jtsummers 5y ago
    It's important to remember that YAGNI is a guideline not a rule. If someone spends 10-minutes thinking about the future instead of writing code immediately, and they realize a need that introduces some extra upfront effort but reduces longterm maintenance (fewer changes in the future because it already matches the desired structure), then YAGNI doesn't apply. For standard work, this is a pretty common situation to find yourself in: Recognizing that you've done X before and it led to a particular structure, so when doing X' start with the final structure instead of insisting on 100 extra refactors along the way.
FPGAhacker 5y ago
So the idea is that eventually real work will be done, likely by adding more functions. The class provides a nice encapsulation for that future work.

A plain function has a uniform interface too: just calling it.

by _dain_ 5y ago

A plain function has a uniform interface too: just calling it.

Jtsummers 5y ago

True, but that doesn't help you with encapsulation or the other (potential) benefits of using classes like inheritance.

Too 5y ago
Local variables inside a function are very much encapsulated. Unless you need to keep state between two distinct actions on the same object, but in that case a single run() entry point will not be sufficient anyway. Inheritance can be replaced by just calling a common function. There are many “what if” here, which will likely never happen and until they do it’s premature abstraction. Most likely some other abstraction is needed by the time script grows.
_dain_ 5y ago
"Lots of times people think they might need something later. You don't. Or you can just do it later if it comes up." https://youtu.be/o9pEzgHorH0?t=339 https://youtu.be/o9pEzgHorH0?t=339 For glue code scripts like this you usually don't end up using encapsulation and inheritance or any other fancy OOP design patterns. It's usually grungy IO-bound procedural code, the sort of thing you'd write in bash if bash weren't terrible for long scripts. Don't burden it with premature abstractions. If you end up needing a class, just write the class later.
- Jtsummers 5y ago
  It's important to remember that YAGNI is a guideline not a rule. If someone spends 10-minutes thinking about the future instead of writing code immediately, and they realize a need that introduces some extra upfront effort but reduces longterm maintenance (fewer changes in the future because it already matches the desired structure), then YAGNI doesn't apply. For standard work, this is a pretty common situation to find yourself in: Recognizing that you've done X before and it led to a particular structure, so when doing X' start with the final structure instead of insisting on 100 extra refactors along the way.

FPGAhacker 5y ago

So the idea is that eventually real work will be done, likely by adding more functions. The class provides a nice encapsulation for that future work.