SOLID principles and how I was breaking them | Hacker News Reader

SOLID principles and how I was breaking them

codersbible.com

39 pointsmdziubek5 comments

One thing that I don't fully agree with is the treatment of Dependency Inversion. As I see it, the Dependency Inversion Principle (DIP) and Dependency Injection (DI) are quite different things living in different dimensions. While DI, as he describes, might be a good candidate to implement DIP, it is IMO by no means an example of DIP (unless I get the reasoning wrong). In my understanding, DI is all about keeping objects that interact with each other on the same layer of abstraction in order to avoid a semantic impedance mismatch. The eponymous "inversion" part is about how we get objects from different domains into the same abstraction layer: by defining an interface in the language of our own module and implementing this interface in the other module (or somewhere between).

Aside from that, I really like the idea of teaching abstract stuff with examples and counterexamples.

Never been in a project that took all those rules into consideration. Usually, when pointing out the issue, it was me who was supposed to defend my point as opposed to the person who wrote the code (or my comments got ignored altogether).

Oh wow, I find this extremely relatable, I was starting to think I was the only one. I have the exact same experience, in fact, it's basically the only thing I've experienced so far in my career. I remember so few times (while at any job) where my opinion/experience/knowledge/ideas/code review/etc was ever given any weight. On the other hand, helping people out online or wherever, has always been a pretty positive experience for both of us and I've enjoyed it.

> it was me who was supposed to defend my point

Professionally, on the other hand, it feels like I'm screaming into the void, or sometimes at a brick wall. It's deeply frustrating, it's basically got to the point where I just stop trying to change anything for the better, agreeing to whatever inane changes they want to the code (even when I can see the clear disadvantages that will hurt them more than me but they want it anyway), never bothering to disagree with anyone more senior, basically being a yes man for code. I've occasionally been able to work on something brand new, where I have a little more control over the quality.

> opposed to the person who wrote the code

Getting someone to change code they "own" always seems to be impossible too, no matter how tactfully you approach it, no matter how much evidence you present that indicates a design flaw, no matter how well you explain why an alternative is better, it's just so pointless.

The stuff I work on outside of work is usually where I get to write clean code.

> (or my comments got ignored altogether)

Basically, it boils down to this. I don't know how people cope with it, at times I feel totally hopeless about it. I see people sprinting towards the cliff edge and no matter how much I try stop them, they are determined to keep going. Sometimes it feels like they double down or deliberately do the opposite of what I'm suggesting.

  Me: Hey, stop hitting yourself, that's bad.
  Them: Oh, you want me to stop hitting myself? I'm going to do it harder.

It's a totally uphill battle, some people just don't want to listen. I'm all out of answers.

For me, the most violated, and least understood principle is "Liskov Substitution Principle". How many times, I saw in a big software, inheritance used to "modify" a base class. This is terrible programming.

Nice examples.

Reply on news.ycombinator.com