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…
In this post I use the word “OOP” to mean programming in statically-typed language
So Smalltalk is not object-oriented. Someone tell Alan Kay.
Yeah let’s not forget the Common Lisp Object System (CLOS) which was more full-featured of an object-oriented language than most “current” languages.
The dynamism allowed both Smalltalk and CLOS to avoid a dark corner that will confound your typical OOP’er today - the circle/ellipse modeling problem; they allow an object to “become” a different type on its own accord. Take that, Java!
You down with OOP? 🤪
In my experience, as a 25-year developer in mostly OOP languages and frameworks, is that people who attack OOP usually don’t really understand it and its usefulness.
And to be fair as it relates to attacking languages or language concepts, I attacked JavaScript without fully understanding it, many years ago. I now understand it more than I ever have in the past and it has some good qualities.
So these days it’s no longer the languages or language concepts I take issue with (though I’ll joke about JavaScript from time to time). It’s the developers who misuse or misunderstand the languages or concepts that irk me. And especially the developers who think being lazy is a virtue.
My issue isn’t any particular language but the advocates of various languages treating their language as the best hammer for every nail.
Damn good point! I feel the same way about CEOs as of late and how they think AI is going to solve everything, even problems they invent just to say they’re using AI.
Thanks. I hate it.
I’m going to spend this thread agreeing with Rust fans, and I hate that the most. (I love you all, really, but you’re fun to try to wind up.)
OOP sucks because Inheritance sucks. This person’s brief non-shitty experience doesn’t change that.
Languages built around OOP suck where they use inheritance instead of interfaces.
Inheritance is isn’t always a terrible choice. But it is a terrible choice often enough that we need to warn the next generation.
If we’re looking at it from a Rust angle anyway, I think there’s a second reason that OOP often becomes messy, but less so in Rust: Unlimited interior mutability. Rust’s borrow checker may be annoying at times, but it forces you to think about ownership and prevents you from stuffing statefulness where it shouldn’t be.
Is there any reason an OO language couldn’t have a borrow checker? Sure, it would be wildly more complex to implement but I don’t see how it’s impossible.
OO languages typically use garbage collector. The main purpose of the borrow checker is to resolve the ambiguity of who is responsible for deallocating the data.
In GC languages, there’s usually no such ambiguity. The GC takes care of it.
usually
To be fair, that’s an issue in almost every imperative language and even some functional languages. Rust, C, and C++ are the only imperative languages I know of that make a serious effort to restrict mutability.
I also love this. I don’t why but gc languages feel so incomplete to me. I like to know where the data is that I have. In c/c++ I know if I am passing data or pointer, in rust I know if it’s a reference or the data itself. Idk, allows me to think better
How do C and C++ try to restrict mutability?
constThey don’t do it well, but an attempt was made.
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.
Why is the word factory a code smell?
It means you’re compensating for the lack of optional/named parameters in your language.
Eh? How’s that work. I’m not going to sit here and say there isn’t too many factories in Java but as a concept it’s extremely useful. You hand off a “factory” to something which actually creates the object. This is really useful in for example serialization. How so? You could register factories (mapped to some sort of ID) which get passed the serialized data and return some sort of created object. Now the core serialization code doesn’t know nor care how exactly any particular type gets serialized. Pretty nifty huh?
Some languages have better ways to encapsulate this functionality but that’s what the factory concept is
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.
IMO factory functions are totally fine – I hesitate to even give them a special name b/c functions that can return an object are not special.
However I think good use cases for Factory classes (and long-lived stateful instances of) are scarce, often being better served using other constructs.
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”
I love working in OOP. It’s true that it’s not always the best solution for every project, but damn if it isn’t nice when it is.
I’ve always had an easier time jumping into an oop code base, then eg a lisp one.
I hear people when they say they don’t want their data mixed in with their logic but The pressure to structure code Is very nice.
The pressure to structure code Is very nice.
That is a great point. It’s interesting how our tools influence our designs, and OOP does force some thought to go into having an intentional structure.
