Hacker News Reader

Comment by FourthProtocol | Hacker News Reader

Took me a long time to grok OOP and OOD (was introduced to OOP in '91). At first I thought I knew it, and then realized I didn't.

Plane into the side of the mountain, no survivors, call off the search. Which is when I really started to learn (around '96/97). And now I love it.

Until I come across people who always start by defining an interface first and then think about what might follow. And dependency injection. Holy priceless collection of Etruscan snoods DI makes me want to gouge out my eyeballs with a rusty cork screw.

Like I said though I love it and today my happy land is about 80% OOP and 20% everything else.

View on HN

The thing I love about OOA/D/P is that it is a useful and productive way of thinking about things. It's probably even the most natural and intuitive way of thinking about them. Plato wasn't a C++ programmer, but classes and interfaces are direct descendants of his work 2k+ years ago.

When I first fell in love with OO there was a time that I felt that there wasn't a problem in the world I couldn't solve using it. That moment it finally "clicked", and all the lights came on? Wow! One of the best intellectual experiences of my life. It changed everything.

I was right about being able to do anything with it. What I was wrong about was how some things are more difficult than others. Rules-based systems, for instance, get abstracted away into a sort of gobbledygook in OO. Scripting is uglier than it should be.

Then I had a similar realization about FP. It took much, much longer and there was no dramatic moment, but the impact was just as huge. It was a new way of thinking about and solving problems. It has it's own edge cases and antipatterns, of course, just like OO.

I wonder what the next A-Ha! change will be? TLA+? Is there a system of thinking around morals and values as it applies to problem solving, as Kant and others thought? Beats me. I hope I get to find out.

Data flow. Closely related to functional programming, and also relational algebra. Different variants, whether reactive, push vs pull, streaming vs batch, restartable, etc.

DI is bad, what? So how are you writing tests then.

I always though dependency injection was an inevitable product of over zealous testing. As soon as someone says we need to test 100% of the code in our UI that is where you end up.

No it's just an inevitable product of 'testing'. It's a simple way to enable and disable dependencies. There is literally no better way, apart from not having any dependencies in the first place of course.

Like in procedural languages I write my own harnesses as needed. Because DI adds complexity. And for testing all DI does is make testing easier. You end up shipping all that complexity or you refactor your ship code. To be fair that might be acceptable to many in a typical corporate environment.

What do you mean by DI? I find DI is an overloaded term.

In this context I believe he is referring to dependency injection.

I guess I meant to ask what they mean by dependency injection. A bare version is just passing dependencies as arguments and I can't imagine what is so egregious about that. Maybe they mean something more complicated?

Given "I write my own harnesses as needed", I read the parent as talking about DI frameworks, not the general concept of DI. https://en.wikipedia.org/wiki/Dependency_injection#Dependenc...

Well you are going to need to deal with your dependencies eventually. Unless you are just end2end testing, and not doing any unit tests. In that case good luck finding your bugs when they appear. Or perhaps you write 'if (mode == "test")' everywhere :)

By letting the application load all required components into memory before running the test(s). If Component A needs Component B which needs Component C, they all get loaded as they would in production (ie. without mocks). If this means that almost the whole application gets loaded to run a single test, so be it.

The only time this approach is really a problem is when doing slow calls such as I/O - eg. writing to the database. In such cases you can easily switch to an in-memory database or use a factory pattern (which is kind of like a hand-rolled mock).

It's true that an error in say Component C may generate many failures in test of for other components, but in practice that's not really a problem. Just pick one of the test failures and drill down until you find the root cause - fixing that cause will magically fix the other 55 test failures.

DI is an essential feature of functional programming, and it's incredibly simple to understand. You're real issue is that OOP is a terrible, broken model that can only model a pattern like DI with a high degree of complexity.

Reply on news.ycombinator.com