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

161–170 of 312 posts

Re: The Case Against OOP Is Wildly Overstated

#161

Post by kqr »

dclusin wrote: post #81
beaker52 wrote: post #70

Earlier quoted context omitted.

"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 f…

For large interwoven software systems this complexity seen in the form of service layers, directory services, distributed quorums, etc. is often necessary to achieve availability guarantees. I think that the problem is that engineers are over eager to design these sorts of things and implement them before they're actually necessary. And they do it badly and make life shitty in the process because they still don't ful…

Adding on to this, there's an important distinction described by Parnas back in the 1970s as

> Software can be considered "general" if it can be used, without change, in a variety of situations. Software can be considered "flexible", if it is easily changed to be used in a variety of situations.

We frequently forget that these are both valid paths to the same end. We tend to laser-focus in on generality, at the expense of flexibility.

And for small problems like the one described, it is usually much easier to go for flexibility at the expense of generality. And I think we should.

Re: The Case Against OOP Is Wildly Overstated

#163

Post by ghayes »

AnimalMuppet wrote: post #149
keithasaurus wrote: post #130

Earlier quoted context omitted.

> "Tightly binding data and code" allows you to maintain complex invariants via code Not sure I understand what this means. Could you give an example?

I'm not the one you're asking. But... Here's a data structure that represents a bill of materials. It has a list of components, and a total cost, which is the sum of the costs of the components on the list. That's the invariant - that the total cost is the sum of the costs of the components in the list. If it's just a structure, then someone can add or remove a component, and forget to update the total cost, and the…

For what it’s worth, with ADTs and non-exposed constructors you can achieve the same result (i.e. only the creating module can actually _build_ such a list but other modules can read the data).

Re: The Case Against OOP Is Wildly Overstated

#164

Post by identity0 »

AnimalMuppet wrote: post #132
_28jh wrote: post #55

The author flatly says "do not use inheritance." Without inheritance and polymorphism, what is left in OOP? If you look at the author's 4 pillars, the only thing left is encapsulation (and "Oversimplified Hot Takes") It seems like the author himself has proven why OOP is bad. You can have encapsulation without OOP. People were doing it in C 40 years ago. And people are doing it in Go right now. No one would call Go a…

Yes, you could do encapsulation in C. You'd have a struct. But the problem is, any function in the whole program could modify the data in the struct, possibly placing it in an invalid state. When the struct wound up in an invalid state, you had to look at the entire program to find out who did it. (C++ style) OOP encapsulation is different. Only member functions can modify the "struct" (object) data (unless you did s…

I never said encapsulation was easy or obvious in C, just that it's nothing new or inherently OOP-based. I also never said that you should never use inheritance, I was just quoting the author, who, in his "defence" of OOP admits that OOP's only unique feature should not be used at all.

Re: The Case Against OOP Is Wildly Overstated

#165

Post by joshuamorton »

AnimalMuppet wrote: post #149
keithasaurus wrote: post #130

Earlier quoted context omitted.

> "Tightly binding data and code" allows you to maintain complex invariants via code Not sure I understand what this means. Could you give an example?

I'm not the one you're asking. But... Here's a data structure that represents a bill of materials. It has a list of components, and a total cost, which is the sum of the costs of the components on the list. That's the invariant - that the total cost is the sum of the costs of the components in the list. If it's just a structure, then someone can add or remove a component, and forget to update the total cost, and the…

Actually my response would be that you just have a plain-ish vanilla list of `Component`, and a function `TotalCost(List[Component]) -> float`, which is implemented as, approximately, lambda arr: sum(x.cost for x in arr). This maintains the invariant without state.

There's a potential performance cost here, but that usually doesn't matter a whole lot.

Re: The Case Against OOP Is Wildly Overstated

#166

Post by wwright »

If there is anything in CS which should be renamed simply because people have completely incorrect assumptions from the name, it's OOP. Everyone has someone different they think about it, and almost none of it has anything to do with late-binding, encapsulation, or message passing.

Re: The Case Against OOP Is Wildly Overstated

#167

Post by wwright »

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.

I think "tightly binding data and behavior" is a less-ambiguous way of phrasing the pitfall. Obviously code goes great with data; no one wants to work with strings as raw buffers all the time!

Re: The Case Against OOP Is Wildly Overstated

#168

Post by jmnicolas »

Since I accepted I was no Einstein I embraced the KISS principle.

My code became simpler, easier to understand.

Of course it wouldn't get the approval of any software architect or any design pattern fanatic, but I can take any code I wrote 3 years ago, understand it on the fly and edit it with confidence. There are few bugs and they're never a nightmare to find.

Now if I have to modify the code I was writing before my KISS revelation, when I was reading too much about OOP and design patterns then the headaches start. Often I'm left wondering why oh why I had to use so many levels of indirection to solve what is a simple problem.

Re: The Case Against OOP Is Wildly Overstated

#169

Post by C1sc0cat »

winstonewert wrote: post #25
dnautics wrote: post #16

Earlier quoted context omitted.

Always prescribing raw sql is dangerous: You typically want something managing your sql queries if there's user input because scrubbing out SQL injections is hard and it's not something you should be 'rolling your own'

I presume that when somebody says raw sql they mean are using parameters and not just building strings.

and SPROCS
Post reply on HN