4 ms·
> Same way you move on from heavy OO to dicts/lists. OO is better if the objects tell a story in a way that ProviderStrategyDataFetchers fail to do so and are
by Quarrelsome 9y ago
> Same way you move on from heavy OO to dicts/lists.
OO is better if the objects tell a story in a way that ProviderStrategyDataFetchers fail to do so and are effectively just wrappers for data structures.
If you go pure data structure without story you just end having to add comments to explain purpose. The comments are the classes.
- 3pt14159 9y agoI agree with both you and the OP. OO where necessary, lists and dicts where things are simple. You can always take a list of strings and turn it into a list of objects. But going the other way is harder because you have to refactor anything that depends on them.
- Quarrelsome 9y agoThe concern is when you encounter a list of very dense transforms between different data structures without anything informing you as to the purpose or even reason for these operations. Is it _just_ to build the output, are there critical side effects in the process? Are the apis just so bad that all these operations _need_ to be performed or is just pure 100% required processing? Method names help somewhat if people are adverse to objects. All that concerns me is that much modern functional code often becomes very dense transforms with little narrative to inform the reader.