Learn More
Resend Email
2
jesustricks
5y

I'm starting to gain a dislike for OOP.

I think classes make it easy for me to think of the entities of a problem and translate them into code.

But when you to attempt to test classes, that's when shit hits the fan.

In my opinion, it is pointless to test classes. If you ever seen test code for a class, you'll notice that it's usually horrible and long.

The reason for this is that usually some methods depend on other methods to be called first.

This results in the usual monolithic test that calls every goddamn method on the class.

You might say "ok, break the test into smaller parts". Ok. But the result of that attempt is even worse, because you end up with several big tests cases and a lot of duplicate code, because of the dependency of some methods on others.

The real solution to this is to make the classes be just glue: they should delegate arguments onto functions that reside on its own file, and, maybe afterwards emit events if you are using events.

But they shouldn't have too much test code classes though. The test code for classes should be running a simple example flow, but never doing any assertions other than expecting no exceptions.

For the most part, you'd be relying on the unit testing that is done for each delegated function.

If you take any single function you'll see that it's extremely easy to write tests for it. In fact, you can have the test right next to the fuction, like <module>.xyz <module>.test.xyz

So I don't think classes shouldn't be used at all, they should just be glue.

As you do normal usage of this software this way, when a bug is discovered you'll notice that the fix and testing code for this bug is very usually applied to the delegated functions instead of being a problem of classes.

I think classes by themselves sound sane in paper, but in practice they turn into a huge fucking messes that become impossible to understand or test.

How can something like traditional classes not get chaotic when a single class can have x attributes and y methods. The complexity grows exponentially. And sometimes more attributes and methods are added.

Someone might say "well, it's just the nature of problems. Problems can have a lot of variables".

Yeah, but cramming all of that complexity into a single 200 lines class is insanity.

random

test

procedural

oop
Favorite
Ranter
Comments
  • 2
    5y
    Well, the whole point of classes is to limit the whole x attributes and y methods by breaking your application into smaller, organizable little boxes that you can stack and duplicate how you want to.

    However, when misused, the label on the box won't accurately reflect what is in the box, or the box will have too much in it to the point that trying to remove one thing will cause a bunch of other things in it to fail.

    Still, I would rather have a few bad boxes then have all my stuff in one big box where I can't find heads or tails of anything.
  • 1
    5y
    Classes are not namespaces. Some languages are limited though, so classes end up being used as namespaces.
  • 2
    5y
    OOP is only bad when done badly. Testing is hard as f*ck no matter what paradigm you're using. Like actual unit testing with database mocks, the whole nine yards kinda thing
  • 2
    5y
    In fact proper OOP is great for testing because the whole idea is making little, self-contained, logical boxes with a well defined interface (as in API, not interfaces). That is exactly what you want for testing
  • 0
    5y
    in this case id go with a integration test environment.
  • 2
    5y
    "I'm starting to gain a dislike for OOP.
    (...)
    In my opinion, it is pointless to test classes. If you ever seen test code for a class, you'll notice that it's usually horrible and long.

    The reason for this is that usually some methods depend on other methods to be called first."

    I think you're starting to gain a dislike for *state*.

    What you are describing is the - typical - pain of first setting up a desired state, then testing that a given method correctly mutates said state.

    While this sucks, OOP is not to blame here. State management is hard under any paradigm, which is why functional programmers love pure functions so much. Rightly so.
  • 0
    5y
    @VaderNT "functional programmers" is this now a defining attribute for a certain class of programmers? I always saw functional programming as a style with certain pros and cons, just like any number of other styles. Playing DA here, curious if this is becoming a thing in my profession.
  • 0
    5y
    @Demolishun Well, shared state is less of a pain in the ass with FP, which helps when testing because you don't have to set up many layers of related objects to initialize the proper state. On the other hand FP is a pain in the ass in every other way
  • 0
    5y
    @12bitfloat I get the shared state thing. I was honing in on the terms "functional programmers". As if it defines the whole thing a programmer does. Like if I used mixed paradigms does that make me a "mutt programmer"?
  • 2
    5y
    @Demolishun you're free to substitute it with "programmers proficient with the principles FP" or so. That is all I wanted to express. Whatever you're "honing in on", it's not there. 🤷‍♂️
  • 0
    5y
    @VaderNT That is what I was thinking you meant. Thanks for clarifying.
  • 0
    5y
    Doesn’t sound like your classes are following SOLID.
Related Rants
devRant © 2021 Hexical Labs LLC
Privacy Policy  |  Terms of Service
Add Comment