I'm honestly impressed. After more than 20 years programming and reading about programs, this is the first time that I find such a thing: a concise and well-written description of the <i>exact opposite</i> of everything that I believe in. It's like the author was reading my mind and applied a NOT filter before writing it back.
I don't think I agree with using objects as the public interface to an algorithm, especially if its primary purpose is to apply some transformation over the input (i.e. a natural fit for a function). The examples given have a bit of a two-phase initialization smell: initialize some internal state, then run the algorithm: steps that are never performed separately.<p>Objects as an algorithm internal state might be a better approach: the caller doesn't have to worry about the algorithm's internal state, they only need to call the external function entry point (and you'll destroy or otherwise forget the internal state at the end of the function, rather than putting the burden on the caller).
<i>”It’s impossible for a client to call the wrong function; there’s only one way of doing things.<p><pre><code> my_algorithm = MyAlgorithmClass()
results = my_algorithm.run()</code></pre>
“</i><p>Only one? That API opens the door for<p><pre><code> my_algorithm = MyAlgorithmClass()
results = my_algorithm.run()
more_results = algorithm.run()
</code></pre>
, which, hopefully, resets exactly the right amount of state to work just fine.<p>There’s also the ‘fun’ of sharing an ‘algorithm’ between threads. That will teach you that this ‘algorithm’ is more a set combining function arguments with function state, and a method that uses them to compute a result. Next, if you’re smart, you’ll separate the arguments from the state.<p>⇒ if you do something like this, use that builder pattern.
i really don't see how<p><pre><code> AlgorithmClass().WithXValue(10.0)
.WithYValue(20.0)
.WithEtc(...)
.Run();
</code></pre>
is any better than<p><pre><code> Algorithm(x=10.0, y=20.0, etc=...)
</code></pre>
the argument that text books teach us algorithms in form of single function with inputs and outputs is quite weak, there's a very simple solution - break up the large function into smaller functions.<p>i'll always prefer a set of isolated functions with explicit argument and return declarations over a class implementation with methods because:<p>- argument list tells me immediately what is required and what are possible additional options as opposed to having to scan the method list for methods matching `WithFooBar` names<p>- methods become coupled to internal state of the algorithm object because let's face it - code rots, maintainers take shortcuts, state proliferates, everything that is allowed by a compiler/interpreter will eventually make it into the codebase; it's much more preferable to avoid/diminish most of these problems by writing isolated functions<p>- explicit arg/return declarations help with default static analysis/checks, much harder to do that with classes and internal state
I stopped reading here:<p>It’s fine for the algorithm to have separate logical parts, but in a function this is a violation of the single responsibility principle.<p>If it's contained inside the algorithm, and never done elsewhere, then it's still following the SRP to have the algorithm as a single function. This is just someone who learned a new set of principles and over applies them.
I sometimes wonder if people like Bob Martin aka "Uncle Bob" and Martin Fowler have done more damage than good with their arbitrary rules. Or maybe people are too blindly following their rules in every aspect of software design.
The traversal example is a bit weird. There's a simple solution to what the author wanted. Replace `print(root.value)` with `yield root.value`. Now you've got a simple algorithm where the caller can decide what to do with the values. And it nicely resembles every kind of iterating things in python. Instead, the object idea makes the algorithm specific to one single use case.<p>Same with the second example: You can write this as a filter on a function which reads the data. You get a generic reader and a generic filter which can be tested separately.<p>Twisting the code to fit it into the strategy pattern and preserving some hidden state just to make that possible seems silly to me. Is the class really worth writing instead of composable / reusable / testable / streamable:<p><pre><code> def data_reader(fin):
fin.readline()
for line in fin:
yield [int(val) for val in line.split()]
def fill_zero(source):
last_day = 0
for next_day, value in source:
while last_day < next_day - 1:
yield 0
last_day += 1
yield value
last_day = next_day</code></pre>
The start of the article is a very compelling description of why you should split your code into smaller components instead of just having a single structured procedure. Levels of abstraction, testability, etc. - Pretty basic stuff I think.<p>I don't know where he took the leap to consider objects those components though. You can perfectly expose a function that is internally split without making it public in the public interface. And you certainly don't want to deal with the extra problems of having shared state...<p>Object-oriented is not an antonym of monolithic. In fact, I'd say they tend to end up being related terms, rather than opposed.
Pendulum is slowly turning back to "Everything's an Object". Time to decorate Jabba sections in that CV and remember to drop in an obvious reference to GoF/Fowler/UncleBob writeups.
This is a reasonable pattern commonly used to implement recursive-descent parsers, where you have a parsing function for each language construct but they all need to access common state (such as the lexer and the error output). Passing this common state as separate parameters becomes tedious, so it makes sense to group them into a struct.<p>It's not all that well-motivated in the article, though, since helper functions aren't in themselves a code smell. You can just make them private. It's also not strictly necessary to convert the helper functions into methods on the object holding the state, though this can be convenient.<p>Also, the state object is an implementation detail and should usually be private. The public API of of the parser can be a pure function.