You must log in or register to comment.
As a life-long developer in OOP languages (C++, Java, C#, among others) I still think OOP is quite good when used with discipline. And it pains me that there is so much misunderstood hate towards it nowdays.
Most often novice programmers try to abuse the inheritence for inpropper avoiding of duplicate code, and write themself into a horrible sphagetti of dependencies. So having a good base or design beforehand helps a lot. But building the code out of logical units with fenced responisbilities is in my opinion a good way to structure code.
Currently I’m doing a (hobby) project in Rust to get some feeling for it. And I have a hard time to wrap my mind around some design choices in the language that would have been very easily solved with a more OOP like structure. Without sacrificing the safety guarantees. But I think they’ve deliberatly avoided going in that direction. Ofcourse, my understanding of Rust is far from complete so it is probably that I missed some nuance… But still I wonder. It is a good learning experience though, a new way to look at things.
The article was not very readable on mobile for me but the examples seemed a bit contrived…
OOP is great, and can be much simpler than what you’ve seen.
It’s Java culture that’s terrible. The word “Factory” is a code smell all on its own.
Just like any tool, don’t overuse it. Don’t force extra layers of abstraction.
I’ve realized that Factories are actually kind of fine, in particular when contexualized as being the equivalent of partials from the world of functionals.
I have never seen them used well. I expect there IS some use case out there where it makes sense but I haven’t seen it yet. So many times I’ve seen factories that can only return one type. So why did you use a factory? And a factory that returns more than one type is 50/50 to be scary.
Yeah, I went through the whole shape examples thing in school. The OOP I was taught in school was bullshit.
Make it simpler. Organizing things into classes is absolutely fine. Seven layers of abstraction is typically not fine.
Consider the following: You have a class A that has a few dependencies it needs. The dependencies B and C never change, but D will generally be different for each time the class needs to be used. You also happen to be using dependency injection in this case. You could either:
- Inject the dependencies B and C for any call site where you need an instance of A and have a given D, or
- Create an AFactory, which depends on B and C, having a method create with a parameter D returning A, and then inject that for all call sites where you have a given D.
This is a stripped example, but one I personally have both seen and productively used frequently at work.
In this case the AFactory could practically be renamed PartialA and be functionally the same thing.
You could also imagine a factory that returns different implementations of a given interface based on either static (B and C in the previous example) or dynamic dependencies (D in the previous example).
Sounds easy to simplify:
Use one of: constructor
A(d), functiona(d), or methodd.a()to construct A’s.B and C never change, so I invoke YAGNI and hardcode them in this one and only place, abstracting them away entirely.
No factories, no dependency injection frameworks.
Now B and C cannot be replaced for the purposes of testing the component in isolation, though. The hardcoded dependency just increased the testing complexity by a factor of B * C.
That’s changing the goal posts to “not static”
