Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Case Against OOP Is Wildly Overstated

medium.com

Post reply on HN
Print view View original

61–70 of 312 posts

Re: The Case Against OOP Is Wildly Overstated

#61

Post by grugagag »

api wrote: post #48
grugagag wrote: post #14

Earlier quoted context omitted.

> I think it's safe to say that there is no "one language to rule them all" or "one programming paradigm to rule them all. Absolutely! But when OOP was initially sold to the masses it was marketed to be that one solution to rule them all, OOP was the buzzword of the day and it stayed like that for some time to come. It is only fair that the king was dethroned to make room for equally good/competing paradigms. I don't…

I agree about OOP being marketed that way. I remember that time. Rejecting it utterly and making it an "anti-buzzword" is equally irrational. It's a tool. Use it when appropriate.

> It's a tool. Use it when appropriate.

I agree it is a tool but since its definition (or multiple definitions because it appears there are many conflicted OOP philosophies out there) is not very clear and it leads to a lot of needlessly confused ways of using it.

If it weren't so hyped in the first place maybe it would have evolved in a more harmonious way and it wouldn't be the subject to bashing now. I personally can use it for my projects, but I am in no way inclined to save it from bashing, it did bit me multiple times when my intuition was telling me otherwise. I guess what goes around comes around.

Re: The Case Against OOP Is Wildly Overstated

#62

Post by spanhandler »

I think React's decision, when faced with a desire to track state alongside code, to partially reimplement objects inside of functions rather than just saying "know what, this new feature requires class syntax, deal with it" (and in fact excluding class-style syntax from the new features) is the perfect sign of where the functions-vs-OO pendulum is.

Re: The Case Against OOP Is Wildly Overstated

#63

Post by garethrowlands »

lgessler wrote: post #4

This doesn't speak to what I consider some of the most dangerous parts of OOP, which include the assumptions that tightly binding data and code is helpful, and that statefulness is fine to freely sprinkle throughout your program.

A typical microservice tightly binds code and data, and it communicates via messages. So when a microservice is useful, it's an example of binding data and code being useful.

Though when a microservice mutates something, it's typically persisted in a database or similar (and, you'd hope, not sprinkled throughout its code). But, yeah, a bunch of communicating microservices are a lot like communicating objects - for better or worse. Same with Erlang-style actors.

Re: The Case Against OOP Is Wildly Overstated

#65

Post by jeffffff »

api wrote: post #3
Kapura wrote: post #2

In summary, "Object Oriented Programming is good when you don't orient your program around objects."

That sounds snarky. Not sure if that was intended or not, but regardless I read your comment as: "OOP is good when you use the object oriented structure as a tool to organize your code and data to solve a problem, but not when you try to wrap your solution or your conception of the problem itself around OOP." It's 2020, and after 50+ years of programming language research I think it's safe to say that there is no "on…

i would make a distinction that data and state are two different things and argue that a lot of the mess people create with OOP is due to confusing the two. data is what exists externally to your program while state is strictly internal to your program. inputs and outputs of your program are data and not state by definition. applying OOP principles to data is an unmitigated disaster and is the source of most of the problems associated with bad OOP design. data should be modelled as plain structs and arrays. data should be trivially convertable to and from json. there should be no object/relational impedance mismatch because objects are not data. data should not be bundled with code. there should be no hidden information in data. there should be no inheritance in data (use composition instead). on the other hand, many of these principles are quite useful for encapsulating state in order to provide higher level abstractions. it makes sense to hide the internal implementation details of containers, synchronization constructs, database client libraries, and other abstractions, and to allow for multiple implementations of those abstractions which can be swapped out for different purposes. introducing a new abstraction should not be taken lightly and the vast majority of programs should not be introducing their own abstractions. if the abstraction isn't something you would put in a library and make use of in several other programs, it probably shouldn't exist. in this sense, i think it is fair to say that the article author's stance is that "OOP isn't bad but you probably shouldn't be using it", and that this is a perfectly reasonable statement to make. a lot of die-hard OOP fans would argue that this is not "real OOP" but ironically their dogmatism and inability to deal with ambiguity has done more to fuel the anti-OOP movement than anything else.

Re: The Case Against OOP Is Wildly Overstated

#66

Post by jayd16 »

lgessler wrote: post #4

This doesn't speak to what I consider some of the most dangerous parts of OOP, which include the assumptions that tightly binding data and code is helpful, and that statefulness is fine to freely sprinkle throughout your program.

Objects are essentially structs with namespaces and methods with implicit this params. If you can't have state then you throw structs out too.

If you're going this far, you're essentially throwing away typing as well.

Are you actually just opposed to private fields?

Re: The Case Against OOP Is Wildly Overstated

#67

Post by mpweiher »

clktmr wrote: post #27

> The solution to the fragile base class problem and other inheritance hangovers is surprisingly simple — don’t use it If OOP provides the footgun to shoot yourself, OOP is at fault. Overall the article reads as "OOP has no problems if is used correctly". Of course that's true. I have seen well designed OOP programs, but the majority was not. The author should ask the question, why OOP is applied the wrong way so oft…

Sure 90% of OOP is crap, that's because 90% of everything is crap.

https://en.wikipedia.org/wiki/Sturgeon%27s_law

Re: The Case Against OOP Is Wildly Overstated

#68

Post by jayd16 »

tempodox wrote: post #18

IMO, OOP just puts too many footguns at your disposal, the most dangerous one being mutability (how normal is it that our methods mutate instance variables?). The larger a system grows the more mutability will make it even harder to understand and control. It may be tolerable in small-scale embedded software, but outside of that we should make use of the better alternatives that modern hardware affords us.

Calling mutability an OOP issue doesn't make sense to me. You could certainly have immutable objects. You can event have immutable object inheritance. Maybe you just want a language where fields are immutable by default.

If you're just passing around raw structs or arrays, it's way harder to manage blocks of data.

Re: The Case Against OOP Is Wildly Overstated

#69

Post by skrtskrt »

dionian wrote: post #45
skrtskrt wrote: post #8

The author is right about ORMs. They are ridiculously over engineered solutions. (My experience is largely with Django and SQLAlchemy ORMs) As soon as you want to do something that's not already perfectly built in, everything becomes a mess of impenetrable hacks. Autogenerated Django migrations are unstable and often need to be edited to to be correct or make any damn sense. It also encourages to people to blur or ju…

But that is the tradeoff of ORMs. Black box with free stuff but more complexity. Sometimes (usually?) it does not make sense to use them.

Of course the biggest gain of ORMs is initial dev speed.

If you're going to stand up a business in a week or a month, Django ORM and its migrations are going to get you a pretty darn good solution without spending hours and hours thinking about your RDB design and handling many-to-many relationships "by hand".

Re: The Case Against OOP Is Wildly Overstated

#70

Post by beaker52 »

Rickasaurus wrote: post #31
clktmr wrote: post #27

> The solution to the fragile base class problem and other inheritance hangovers is surprisingly simple — don’t use it If OOP provides the footgun to shoot yourself, OOP is at fault. Overall the article reads as "OOP has no problems if is used correctly". Of course that's true. I have seen well designed OOP programs, but the majority was not. The author should ask the question, why OOP is applied the wrong way so oft…

The term we like to use is "the pit of success". It shouldn't be hard to do it the right way.

"The pit of success" is a great guiding principle when it comes to the design of codebases. Forget about "design patterns" and just focus on _how do I allow developers to focus on creating things that are adding value, rather than faffing around with extraneous things_.

I can't tell you how many times I've seen a project go full onion-pattern with a web service that basically just recieves HTTP requests and makes a few itself and returns some data. Instead of a HTTP request handler that fetches data, perhaps does some mutation and returns it, there's a whole "service layer", a domain model, data fetching abstraction. To change something you have to navigate the winding dependency graph and fight off all the deamons. That's not the pit of success, they're the catacombs of failure.

We should design codebases so that future developers fall into the pit of success, even if it means we haven't been able to show off our knowledge of software architecture etc. The best pattern you can ever apply, is the one that makes change easiest. If you make change hard, the code becomes artificially stale -- I call it 'calcified'. Coupling makes code hard to change.

Thinking about problems through objects, in my experience, encourages people to make 'one model to rule them all', for example in a retail app, you might have a "Product" which ends up having product information, media assets, pricing, promotions, retail and stock keeping information etc which in a peice of software undergoing 'rapid development', multiplies the likelihood of coupling. Which is where Domain Driven Design steps in and tries to preach. Thinking about your problem in terms of data, or events can often help you find the right concepts to create your abstractions around. Another good heuristic is to think about caching, can you cache pricing for the same length of time you can cache product information, for example?

Bit of a ramble, but explains why I tend to shy away from objects, except for where I have a bonafide business problem that needs to be modelled -- with this, the models are only used to make the code make sense to developers and help arrive at the result they produce, rather than the models being the result themselves.

Post reply on HN