11–20 of 557 posts
How I've seen OOP work at big tech is the following: 1. New code base is needed 2. Some developer comes up with the master oop abstraction to solve the problem 3. Years of dev effort spent with the abstraction at the core 4. Dev on step 2 is now the expert in some overly convoluted complex system 5. Is determined a genius since new comers cant easily grasp the complexity, gets promoted to a high ranking dev job My nu…
Pretty tangled read. This seems to be an example of write-only code, but applied to essays. It appears the author is in favor of OOP but it's a little hard to tell.
It could have been a single Python file using Pandas to build a DataFrame and this change would have been so much easier. And I'm saying that as someone with at least 10x more Java development than Python development.
In accordance with this view, I think project architecture should be approached with an emphasis around how much state is necessary for it to run. This is why simulations like say someone making a game or simcity with like relatively independent entities that map to something in real life use OOP. If you're writing a service doing requests, you want as minimal state as possible. Singletons are state. Initialized/non-static objects are state. The smaller amount you have the easier it is to reason about the system.
As I write this however, I worry a little that my view is overly simplistic, or maybe applicable only to domains that I have worked in. If anyone wouldn't mind poking holes in this argument or offering examples I would appreciate it.
How I've seen OOP work at big tech is the following: 1. New code base is needed 2. Some developer comes up with the master oop abstraction to solve the problem 3. Years of dev effort spent with the abstraction at the core 4. Dev on step 2 is now the expert in some overly convoluted complex system 5. Is determined a genius since new comers cant easily grasp the complexity, gets promoted to a high ranking dev job My nu…
It'd be like carpenters saying "spruce is terrible if you make anything from spruce its fucked, you have to use oak." ; A good carpenter will be able to make something amazing from spruce.
Like carpentry, metalworking etc. the quality of the product of programming is heavily based on the skill of the tradesman.
I just wish Julia had a succinct way of saying "This object needs to have implementations for functions X,Y,Z", rather than duck typing everything and just seeing if it works. Maybe it isn't too bad in practice I just don't like it when a function can fail because the implementation changed even though the type signature didn't.
Anyway at the very least the approach of keeping methods separate helps to prevent objects that do not have any state and do not in fact represent any entity at all. Seriously who came up with naming a class "MyObjectHelper"? What on earth is it? It could represent literally anything. Does it even have state? And why?
They guy who hammers nails all day thinks screwdrivers are worthless.
In my mind, state is the real enemy impacting: comprehension, brittleness towards making changes, and the surface area exposed to potential bugs. OOP as frequently implemented, while claiming to encapsulate state, ends up creating so much more. In accordance with this view, I think project architecture should be approached with an emphasis around how much state is necessary for it to run. This is why simulations like…
Regardless, the true weak point of OOP is arguably implementation inheritance, which just doesn't leave you with a consistent semantics that's open to extension and changes in the basic/derived classes (that is, the well-known "fragile base class" problem is still a showstopper). But that has always been a pretty ad-hoc feature anyway. The other components of what people call "OOP", including encapsulation and interface inheritance. are all pretty well defined and not as prone to misuse.