As a Java engineer in the web development industry for several years now, having heard multiple times that X is good because of SOLID principles or Y is bad because it breaks SOLID principles, and having to memorize the “good” ways to do everything before an interview etc, I find it harder and harder to do when I really start to dive into the real reason I’m doing something in a particular way.

One example is creating an interface for every goddamn class I make because of “loose coupling” when in reality none of these classes are ever going to have an alternative implementation.

Also the more I get into languages like Rust, the more these doubts are increasing and leading me to believe that most of it is just dogma that has gone far beyond its initial motivations and goals and is now just a mindless OOP circlejerk.

There are definitely occasions when these principles do make sense, especially in an OOP environment, and they can also make some design patterns really satisfying and easy.

What are your opinions on this?

  • douglasg14b@lemmy.world
    link
    fedilink
    arrow-up
    2
    ·
    edit-2
    11 hours ago

    This is crazy misattribution.

    99% of code is too complicated because of inexperienced programmers making it too complicated. Not because of the principles that they mislabel and misunderstood.

    Just because I forcefully and incorrectly apply a particular pattern to a problem it is not suited to solve for doesn’t mean the pattern is the problem. In this case, I, the developer, am the problem.

    Everything has nuance and you should only use in your project the things that make sense for the problems you face.

    Crowbaring a solution to a problem a project isn’t dealing with into that project is going to lead to pain

    why this isn’t a predictable outcome baffles me. And why attribution for the problem goes to the pattern that was misapplied baffles me even further.

    • termaxima@slrpnk.net
      link
      fedilink
      arrow-up
      1
      ·
      22 minutes ago

      No. These principles are supposedly designed to help those inexperienced programmers, but in my experience, they tend to do the opposite.

      The rules are too complicated, and of dubious usefulness at best. Inexperienced programmers really need to be taught to keep things radically simple, and I don’t mean “single responsibility” or “short functions”.

      I mean “stop trying to be clever”.