The use of ‘class’ for things that should be simple free functions (2020)

One thing I'd add over the 'screwed industry', at least in the java,model era is that the more they added, the more "tools" they needed and it was seen as a quality. Basically quadratic complexity at the cultural level..

ps: as usual, https://duckduckgo.com/?q=stop+writing+classes+pycon&t=ffab&...

https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

Things like this:

   static final int INT_1 = 1;

   static final string HTTPS = "https";

   static final string COLON = ":";

   static final string SLASH = "/";

Minimalism can bite you, too. We have around 30 microservices written in Go, each one one of them living in their own repository (separate codebases owned by different teams). Initially we followed Go's idiom "a little copying is better than a little dependency". So every team simply was borrowing code snippets from other microservices' codebases without creating a common shared library, because those snippets were "trivial". Then it hit production and we found that under load/diverse user input many of those trivial functions were quite buggy or inefficient with edge cases. Since those functions/classes were copypasted over multiple codebases, now you had to contact owners of 30 repositories and coordinate bugfixing in all of them, which is slow and painful. Now we're back to having a shared library of common functions, because it's well tested and it's easy to fix bugs by just upgrading. Often what seems trivial is not trivial at all.

And did you solved the problem "properly"?

Odds are you did not.

I mean, it's terribly easy to come up with all sorts of two-liners if you just ignore all requirements and constraints, and don't pay attention to usecases.

This is a major problem plaguing software development. Plenty of people act like they have to carry the burden of being the only competent and smart individual in a sea of fools, and proceed to criticize everything that everyone around them does, for the sin of not doing something that exactly matches your personal opinions and tastes.

If his solution doesn't work with arbitrary number-like objects (matrices at the very least), doesn't support voice input, can't send results via email and can't seamlessy resume the calculations after a hardware failure, it's far from overengineered.

Should have used TDD/BDD, developed some Gherkin test cases, and used those to develop some JUnit automated tests before starting on the implementation. Oh, and each class -- for the solver, coefficients, variables, etc. -- needs to leverage dependency injection so they can be properly mocked in the tests...

I'm reminded of a story about Kent Beck or somebody, one of the big TDD gurus, who wanted to get a microcontroller to draw something on the screen or something. So he first wrote the program in Java, being sure to employ proper TDD principles, and then hand-translated the Java code to microcontroller assembly or something. But this was feted as a win for TDD and evidence that TDD can be used for anything and therefore should be used for everything. The details of the story are vague, and I can't source it right now, but I know it exists. Some Hackernews is bound to dig up a link, they usually do when I make an obscure reference.

I don't know how your two liner worked nor why it was deemed improper. I don't know whether it solved all special cases. But it in fact failed your political goal.

But the 80-20 principle still holds true for many things — the rare edge cases may indeed bring a whole lot of complexity with themselves. They can easily be a difference between an O(n) algorithm and an NP one.

Minimalism is okay (in that we should strive to decrease the accidental complexity), but I found that some people overdo it to such a naive and frankly, dumb levels that it is actively harmful.

To me, this reads like a requirement, can you really blame them for respecting what you asked for?

I struggle with that all the time. Libraries always tend to accumulate such trivia. My litmus test for it is if the documentation has more lines than the code.

I hate libraries that are a mile wide and an inch deep.

One such case I was permitted to write about (most of my work is under NDA), I can't believe it's already been 8 years since then:

https://jacquesmattheij.com/saving-a-project-and-a-company/

I am especially frustrated by Uncle Bob suggested refactoring of long pure function into a class with private fields. You had a function you could not call wrongly and now you have internal state, race conditions, lifecycles. Good job.

Fair enough but it does suck that it has to be that way. But yeah, fair enough.

> Classes allow namespacing

This is the same mode of issue as the above: when your language doesn’t support arbitrary namespacing or (hello Python, hello Java) then yes classes can get used as namespaces in disguise. It sucks that it has to be this way in these languages, but we play the hand we’re dealt. Great point

> My colleagues have stylistic preferences

I’m struggling to understand this one. Are you saying that your colleagues prefer instantiating classes over functions, just because, or is there a technical reason for that convention?

You're always free to use a final class with a private constructor as a namespace for static methods. Many classes in the standard library are of this kind, including `Math`. It's not ideal (see my next point), but it's a far cry from adding extra object instantiations everywhere.

> E.g. in python functions from imported modules easily litter your namespace

I think this is more a problem with the modularity features in a language than free functions themselves. In Python, Haskell, and Agda, I make sure that every symbol I use is explicitly imported (or defined in the same file). This makes it way easier to trace where each symbol I use is defined.

You're basically forced to do this in Java, too, with exception of wildcard static imports, which I very rarely use.

> if I have a python module universe my colleagues hate it if I import the module and call a function like universe.create() [instead of Universe().create()]

They hate it? I can understand if your colleagues aren't developers by trade, but I expect anyone who maintains code for a living to understand the language they're using. There will always be dark corners, but this ain't one.

In Java, not the JVM. Some JVM languages like Kotlin and Clojure allow for classless functions.

You could argue that it still gets compiled to bytecode with classes, but then that bytecode gets JIT'd to not have classes again anyway so it's kind of a meaningless distinction.

This sounds like a bit of a weird argument to me. Of course convoluted or strange solutions should be avoided, but `import universe; universe.create()` doesn't sound particularly strange in Python, and it's hard to see how there could be a problem reading it unless it's simply due to being used to a different style. People being used to a particular style could be seen as an argument for that style if that style is indeed a common convention in the language, but if `Universe().create()` is the style they're used to, that sounds more idiosyncratic than idiomatic in Python to me. Do your colleagues perhaps have a background in a different language?

Local conventions at a particular organization may of course also be valuable to follow even if they're not global conventions for the language. But that doesn't really change what is and isn't a good style more generally.

(`from universe import Universe; Universe.create()` would sound like a typical style to me if a class for universes were warranted in the first place, but in that case the class isn't unneeded.)

`import *` isn't recommended. I only use it in `__init__.py` when I want a flat package that exposes symbols implemented in multiple submodules.

This would be really depressing for me but ultimately team limitations sometimes win out. If your team can only "understand" code that looks like Java, then maybe all code has to look like Java.

In white collar environments, "don't understand" can be a sneaky, faux-polite way of saying "don't like and refuse to be open to". But it might add up to the same thing in the end.

And for your last example did you mean `Universe.create()`? It should be a static or class method. Those are perfectly fine when they're closely related to the class itself, as with factory methods.

    // Greeter.zig
    const std = @import("std");
    const Self = @This();

    name: []const u8,

    pub fn greet(self: *Self) void {
        std.debug.print("hello {s}!\n", .{self.name});
    }

    pub const Greeter = struct {
        name: []const u8,

        pub fn greeter(self: *Greeter) void {
            std.debug.print("hello {s}!\n", .{self.name});
        }
    };

    // main.zig
    const Greeter = @import("Greeter.zig");
    const greeter1 = Greeter{
        .name = "Joe",
    };
    const greeter2 = Greeter{
        .name = "Sue",
    };

    pub fn main() !void {
        greeter1.greet();
        greeter2.greet();
    }

EDIT for comparison, a non-standalone version would be written like this:

    // greeter-nonstandalone.zig:
    const std = @import("std");

    pub var name: []const u8 = "nobody";

    pub fn greet() void {
        std.debug.print("hello {s}!\n", .{name});
    }

    // main-nonstandalone.zig
    const greeter = @import("greeter-nonstandalone.zig");
    
    pub fn main() !void  {
        greeter.name = "Joe";
        greeter.greet();
    }

$f = fn($x) => f($x, …$deps);

Then I can pass $f to whatever function with its dependencies satisfied.

Edit: fixed example

The decision of what goes where must be made somehow. So you either do it through the type (eg. `@inject(MySuperSpecificServiceThatOnlyExistsOnceAnyways.self)`), or write provider functions.

Isn't the second solution basically the same thing as doing it manually?

Dependency injection in that sense is only used in the "impure" parts, at the edge of your program, to build up application state.

A popular approach is using something like integrant, which describes dependencies as a plain data structure, which gets resolved as a dependency graph and calls into multimethods (polymorphic functions) that you provide to start/stop individual services or what have you.

Another popular approach is to use something like mount, which is basically just a macro which you use to describe how a service is started or stopped. All the dependency stuff is simply resolved via Clojure namespaces.

Both of these (and others) are done in a way so you can start/stop your whole app or parts of it, or just individual services in a REPL. Most of your code doesn't interact with these services, but gets called from them (functional core), so you typically don't need mocks or other such things in testing as your domain logic doesn't know anything about application state.

    from functools import partial 
    new_function = partial(yourfunction, the_injected_dep=the_value)

https://en.wikipedia.org/wiki/Closure_(computer_programming)

In cases like this, I still use a top-level free function, but it just instantiates a (private) class and invokes those (private) subfunctions itself. There's usually no need to leak the implementation's strategy for managing complexity to callers.

Of course, if your computation required interactivity with the caller, then it's not a one-and-done batch deal anyway, so free functions would not have been as appropriate in the first place.

Namespaces are stateless, they don't contain variables, they contain just functions.

Which of these classes are antipatterns?

Observer

FileManager

HTTPServer

CircuitBreaker

ObjectBuilder

ServiceProvider

SchemaValidator

StringTranslator

Vector

    var f = x -> x + 2;

Another option would also be to just pass a struct:

struct dimensions dim = { .width = 4, .height = 7}; countDominoTiling(dim);

My C++ is rusty so this might not compile but you get the idea.

There isn't a big difference with just one simple thing, but when you're having 10 of these things, with some classes having classes in themselves, it quickly becomes a mess.

the number of 1000 LoC solutions for 100 LoC problems I saw in open source projects fills me with dread