Live data from Hacker News

OOP Is Dead, Long Live OOP

gamedev.net

211–220 of 357 posts

Re: OOP Is Dead, Long Live OOP

#211
post #177

All my attempts to jump off OOP train break at exact same moment when I try to write a unit test. Closure: or, simply use this monstrous component pattern when 70% of your code is boilerplate or hack into namespaces and override functions in them in runtime. And don’t forget to do it in right order! JavaScript: yeah, simply re-define ‘require’ before importing dependencies in tests. Yeah, do it in right order. Recent…

Dependency injection is probably my favourite paradigm out there, especially in a statically typed language: for the reasons you mentioned, and for discoverability with an IDE (or ctags). It is also a natural fit for “OOP”, or rather: classes. In a sense, it turns non-OO code into OO simply by storing the interfaces implementing the dependencies required by your code. If that’s your only state, are you still OO? I’d…

Sometimes while reading/writing modern PHP it feels like it's more functional than OOP. It's definitely easier for your code to be pure and simple instead of becoming a stateful mess. To make it a stateful mess you'd have to go against many modern best practices. I think I don't really understand what kind of Java monsters people have worked with in the past.

I will explicitly exclude legacy code from my previous statement, where globals, static calls with side effects, stateful objects and inheritance abuse were common.

Now if only I had all the advanced type system features :/.

Re: OOP Is Dead, Long Live OOP

#212

Earlier quoted context omitted.

Except for the fact that objects can be serialized and ORM's exist to convert your data into OOP. How do you think Entity Framework works? How do you think Rails works? You can build almost an entire ORM from a database without even writing any code in Entity Framework. > And if you want to use other people's objects (say from a library) you first have to make a layer that translates them from your own objects Funny,…

> Except for the fact that objects can be serialized and ORM's exist to convert your data into OOP. How do you think Entity Framework works? How do you think Rails works? You can build almost an entire ORM from a database without even writing any code in Entity Framework. That was actually sort of my point. You need all of this extra stuff _because_ your code is all objects. Data doesn't get serialised, data just get…

>Maps can be represented 1:1 as e.g. JSON. Any JSON data is basically a big map data structure. It's one function call instead of hours of writing ORM classes or custom serialisation methods just to send some data over a wire

Again, you don't write the ORM classes, the framework does it for you.

And what you advocate is essentially sending a table over the network. So, what happens if your data within that map is complex? Are you suggesting to send every piece of a complex data type over the wire in separate chunks? If so, how do you relate it in the application? You still to make some sense of that JSON data in your application. Having it in a big map structure is akin to a god object.

I my mind all you're doing is masking objects in different concepts just because you don't like using classes.

Re: OOP Is Dead, Long Live OOP

#213

Becoming a professional Haskell and Erlang developer really shifted my view on OOP (let OOP denote class based OOP as found in Java or C++). In my view, OOP is prove a poor model for computation, and the result has been that OO code is almost always significantly more complex and error prone than an equivalent computation written in a concurrent, functional, or structured paradigm. Recent trends in language design (s…

You develop web services professionally in Haskell, Erlang and Rust, but you think that Java-style OOP is too complex?

Re: OOP Is Dead, Long Live OOP

#214
post #9

If we just had made inheritance as something to be avoided unless absolutely needed then OOP would have probably never got such a bad reputation. All the other concepts make perfect sense.

Inheritance indeed can be pinpointed as the one major problem in problematic OO code. A lot of the comments here talk about abuse and I think that hits it on the head. It’s not really a matter of knowing when to use or not use inheritance, but rather that the developers that do use it end up using it everywhere and a bad pattern proliferates into even more problematic areas, such as using inheritance for mock objects in unit tests.

Re: OOP Is Dead, Long Live OOP

#215
post #140

Earlier quoted context omitted.

I've found that inheritance is very useful in one situation, and adds nothing over mixins otherwise. If a class does two broad things simultaneously then inheritance can work great. For example, a User class that inherits from a DB mapper class. I don't want to have to tell my class how to write a record to the DB. All that code can be centralized into one thing and then relied upon for its uniformity across all my m…

> I don't want to have to tell my class how to write a record to the DB You don’t need inheritance to achieve this. Your User class contains data and probably some business logic. The fact that it’s going to be persisted in a database at some point is a detail that the class shouldn’t know. Consider using the data mapper pattern (or an ORM implementing this pattern). In this pattern, your User object doesn’t even kno…

My understanding of SRP is that the _implementation_ of those two things should be separate, not the interface.

Re: OOP Is Dead, Long Live OOP

#216

Earlier quoted context omitted.

In this context I believe he is referring to dependency injection.

I guess I meant to ask what they mean by dependency injection. A bare version is just passing dependencies as arguments and I can't imagine what is so egregious about that. Maybe they mean something more complicated?

Given "I write my own harnesses as needed", I read the parent as talking about DI frameworks, not the general concept of DI. https://en.wikipedia.org/wiki/Dependency_injection#Dependenc...

Re: OOP Is Dead, Long Live OOP

#217
post #75

Software developers are systematisers by default. We tend to value complexity for it’s own sake, hence the over-engineering common to software projects. The methodologies we use fall victim to the same tendency. We build complex, rigid rule sets that are claimed to improve software or development speed or whatever else, without any actual empirical evidence that these claims are true. All you can really do is try to…

I suppose, but to me that means we should judge methodologies or design approaches in part by evaluating their failure modes, the severity and frequency with which they occur.

This is why I have so little patience for arguments like TFA, "well of course it doesn't work if you use it wrong!" You can make this argument for anything! If the thing is being used incorrectly a majority of the time, that is valuable information; it's no good to just say "well it would work if developers weren't so dumb." The happy path is always happy, by definition.

A good methodology or design approach will understand its potential failure modes and include mitigations against them to help prevent those failures from happening.

Re: OOP Is Dead, Long Live OOP

#218
post #177

All my attempts to jump off OOP train break at exact same moment when I try to write a unit test. Closure: or, simply use this monstrous component pattern when 70% of your code is boilerplate or hack into namespaces and override functions in them in runtime. And don’t forget to do it in right order! JavaScript: yeah, simply re-define ‘require’ before importing dependencies in tests. Yeah, do it in right order. Recent…

Go interfaces, Rust traits, and Haskell typeclasses and simple parameters do exactly what you ask. In fact, it's harder to mock/stub in OOP than it is in FP by the nature of FP making all dependencies always explicit. Being able to use a 'property' in the body of the functions means you're now relying on a side effect that will have to be magically mocked. In OOP, type signatures tend to lie. Not so true for FP.

The problem with simple parameters is that I need to drag all of my low level stuff through all of the layers of the application.

I one was imagining a framework for Closure that would do something like that:

- you define a bunch of functions. Some of this functions depend on other of those functions.

- for dependent ones you define parameters and tag them somehow

- you call this functions without mentioning those tagged parameters

- during the startup the framework takes over and does partial application, generating functions with same names but without tagged parameters, so you kinda have your dependencies injected.

I don’t know if this sounds too crazy or too incorrect for Closure’s paradigm.

Re: OOP Is Dead, Long Live OOP

#219

Becoming a professional Haskell and Erlang developer really shifted my view on OOP (let OOP denote class based OOP as found in Java or C++). In my view, OOP is prove a poor model for computation, and the result has been that OO code is almost always significantly more complex and error prone than an equivalent computation written in a concurrent, functional, or structured paradigm. Recent trends in language design (s…

For some reason 'arguments' against OOP seem to follow a common pattern. You have said many things against OOP, but you haven't actually presented an argument for why it's bad. I'll present each of your assertions here individually to clarify. > OOP is prove a poor model for computation > OO code is almost always significantly more complex and error prone than an equivalent computation written in a concurrent, functi…

I upvoted you. Why OOP is bad: In 8 years professional (for money) programming experience i had zero use cases for OOP. Every time I tried to use OOP it backfired and I abandoned it. Maybe I just never really understood OOP or maybe I already use OOP all the time without calling it OOP.

Re: OOP Is Dead, Long Live OOP

#220
post #177

All my attempts to jump off OOP train break at exact same moment when I try to write a unit test. Closure: or, simply use this monstrous component pattern when 70% of your code is boilerplate or hack into namespaces and override functions in them in runtime. And don’t forget to do it in right order! JavaScript: yeah, simply re-define ‘require’ before importing dependencies in tests. Yeah, do it in right order. Recent…

The same ideas still apply. Take a look at this explanation: http://vvgomes.com/javascript-dependency-injection/ -- suggestion for after you read the post: depending on your needs I'd recommend not using the default value as, from a dependency perspective, you end up tightly coupling the two. Hope it helps!

Thanks a lot, I’ll take a look
Post reply on HN