<story><title>The use of `class` for things that should be simple free functions</title><url>https://quuxplusone.github.io/blog/2020/05/28/oo-antipattern/</url></story><parent_chain><item><author>amw-zero</author><text>None of these situations require an object to do. You can always have a function that takes in an extra ‘state’ argument. You can then do everything you said by passing in the corresponding state values.</text></item><item><author>dataflow</author><text>Counter-point: while in many situations this isn&amp;#x27;t the right approach, it&amp;#x27;s worth recognizing when this &lt;i&gt;is&lt;/i&gt; the right approach, because they can look awfully similar. An example of this is graph searching, e.g. BFS or Dijkstra&amp;#x27;s algorithm. The typical implementation is a function. But if you make Dijkstra a class, with (say) a function to iterate through nodes, it lets you do several things that would be difficult with a function: (a) you can now re-use the same object for computing distances to multiple vertices, which allows incremental search, (b) you can now fork&amp;#x2F;copy the object and continue searching on &lt;i&gt;different&lt;/i&gt; extensions of the original graph, (c) you can now save &amp;amp; restore the searcher state to pause the search &amp;amp; continue it later, (d) you can do multiple searches across one or more graphs &lt;i&gt;in lockstep&lt;/i&gt;. IMHO these are very much &lt;i&gt;not&lt;/i&gt; obvious, and to someone who doesn&amp;#x27;t recognize what&amp;#x27;s going on, a class for something like BFS will look &lt;i&gt;exactly&lt;/i&gt; like an &amp;quot;OO antipattern&amp;quot;, when in reality it&amp;#x27;s actually providing significant additional functionality for more complicated situations.</text></item></parent_chain><comment><author>JoeAltmaier</author><text>Sure, you can build your own object and pass the &amp;#x27;this&amp;#x27; pointer around manually. You could use C for everything, and tediously do everything again that objects do for free.&lt;p&gt;But why?&lt;p&gt;There&amp;#x27;s a lot of object-hating going around. Its silly. Use objects to encapsulate functionality, they are good at that and everybody understands what it means.</text></comment>
<story><title>The use of `class` for things that should be simple free functions</title><url>https://quuxplusone.github.io/blog/2020/05/28/oo-antipattern/</url></story><parent_chain><item><author>amw-zero</author><text>None of these situations require an object to do. You can always have a function that takes in an extra ‘state’ argument. You can then do everything you said by passing in the corresponding state values.</text></item><item><author>dataflow</author><text>Counter-point: while in many situations this isn&amp;#x27;t the right approach, it&amp;#x27;s worth recognizing when this &lt;i&gt;is&lt;/i&gt; the right approach, because they can look awfully similar. An example of this is graph searching, e.g. BFS or Dijkstra&amp;#x27;s algorithm. The typical implementation is a function. But if you make Dijkstra a class, with (say) a function to iterate through nodes, it lets you do several things that would be difficult with a function: (a) you can now re-use the same object for computing distances to multiple vertices, which allows incremental search, (b) you can now fork&amp;#x2F;copy the object and continue searching on &lt;i&gt;different&lt;/i&gt; extensions of the original graph, (c) you can now save &amp;amp; restore the searcher state to pause the search &amp;amp; continue it later, (d) you can do multiple searches across one or more graphs &lt;i&gt;in lockstep&lt;/i&gt;. IMHO these are very much &lt;i&gt;not&lt;/i&gt; obvious, and to someone who doesn&amp;#x27;t recognize what&amp;#x27;s going on, a class for something like BFS will look &lt;i&gt;exactly&lt;/i&gt; like an &amp;quot;OO antipattern&amp;quot;, when in reality it&amp;#x27;s actually providing significant additional functionality for more complicated situations.</text></item></parent_chain><comment><author>Barrin92</author><text>If you&amp;#x27;re at the point where you&amp;#x27;d rather pass a state argument around rather than use an object you&amp;#x27;ve thrown out OO categorically and there&amp;#x27;s no point to even discuss anything. The article in question talks about when it makes sense to use functions &lt;i&gt;within&lt;/i&gt; the OO paradigm instead of classes.&lt;p&gt;Generally using classes when modelling persistent state is not an anti-pattern, because that&amp;#x27;s what classes are for.</text></comment>