5 ms·
I find the hardest part about OO is that a lot of people don't know what good OO looks like. Most new developers fall into the pragmatic trap and shy away from
by waheoo 6y ago
I find the hardest part about OO is that a lot of people don't know what good OO looks like. Most new developers fall into the pragmatic trap and shy away from refactoring because of startup culture cargo culting.
Good OO requires large refractors on the regular, and with a good design, refractors like this are low cost high return, but failing to do them results in mud eventually.
I used to shy away from it "because nobody can do OO so it's better if we just don't".
Writing everything in procedural and functional is quite productive, but it too requires adherence to rules and avoidance of mutable state.
Once I realised, there are no shortcuts, you just have to learn what works and what gets you into trouble later I tried OO again, only now I use it sparingly and tend to mix procedural, functional, and OO depend on the task at hand. One of the amazing things about PHP is that you can do this easily and clearly. Things like go, java, or even JS these days tend to force you into one way or the other.
Earlier on I aimed for plain objects / structs for information, grouped state passing but I realised these often lead to smells that are hard to clean up. Now I limit their usage to the edges and opt for objects instead. Passing implementations along with the state really cleans things up in coherent ways.
I think one of the scariest things about good OO is that it looks like bad code to me. It looks "not dry". It looks, untidy, lots of state sharing and member variables to track things. From a functional perspective that stuff gets you into trouble. But from OO perspective its what works. The trick is keeping classes small enough to be aware of all the member variables when reading any member function. You shouldn't get blindsided by random state changes elsewhere, that is a sign there is more than one thing being done by that class.
- jordan_curve 6y ago> Earlier on I aimed for plain objects / structs for information, grouped state passing I’m a relatively junior dev and I believe this is a pattern I use a lot. Would you be willing to elaborate on what you mean by it and what some common pitfalls are?
- waheoo 6y agoIt's probably my default "get things done" style of code so I don't want to suggest it's something you want to actively avoid. Plain objects have the benefit of OO in that you have a bunch of normal friendly objects that map well to a database record. But they tend to be treated more like variables. They work well for groups of functions that need a lot of the same parameters but you don't quite want to lock in an object boundary. Often I'll start with a plain object or plain functions, then once I can see the seams I'll form objects. Sometimes you can see these up front as obvious, I still try to hold off. The longer you wait the better and more concise your objects will be. You want you objects to look more like behaviors than records. (Though there is heavy cross over, plain objects / structs make good records and you can easily consume them in objects.) The big pitfalls: Mutation, avoid it where possible, mutation is a sign you need an object. Immutable structs are bliss to use, they're easy to reason about. Mutable structs are basically impossible to reason about, never know what's in there. Using an object to pass a single variable to a function. Using an object to pass a single variable / subset to a sub function call. Basically, try to terminate plain objects at boundary edges like you would nullable variables. There isn't anything wrong with passing an object around for one variable, its just a bit messy and creates a bigger dependency than required. It makes it hard to refactor your plain object out later because you can't tell what is actually depended on down in the stack.
- coldtea 6y ago>I find the hardest part about OO is that a lot of people don't know what good OO looks like. Aside from Bjarne Stroustrup, is there any computer science major figure, great dev, etc., that thinks there is such a thing as "good OO"?
- pjmlp 6y agoPlenty of books to read from, but I guess many don't remeber that thing exists, just read a couple of Medium blog posts as learning process.
- coldtea 6y agoNot sure what is meant here. That there are plenty of books teaching OO programming? Sure. Is there any major CS figure / language developer etc that thinks OO is a good idea in 2021 was the question. Not whether some O'Reilly or Manning or whatever author has some book about it...
- pjmlp 6y agoI don't know, Anders Hejlsberg, Yukihiro Matsumoto, Guido van Rossum, Brian Goetz, Mads Torgersen come to mind. And even the cool kids that got two releases yesterday, Rust and Julia, do support OOP, so I guess we can include their core design teams as well.
- coldtea 6y agoWell, I'll give you Guido and Matz, which started their languages in early 90s when OO was all the rage and stuck with it. Anders, Goetz, and Torgensen on recent years have all talked about the need to add functional features into the languages that started as OOP (and is what they have been doing with C#, TypeScript, and Java since 1.6 or so). One also suspects they made them OOP because they did them on comission and the goal (of Sun, MS, etc.) was to attract devs with what was considered hot at the time... But neither Rust nor Julia support inheritance, so if their style can even be called OOP, it's not the OOP of the kind that Joe talked about where you "get a gorilla holding the banana and the entire jungle", and which most devs know from C++, Java, and yes, Python and Ruby.