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

The faster you unlearn OOP, the better for you and your software

dpc.pw

Post reply on HN
Print view View original

31–40 of 252 posts

Re: The faster you unlearn OOP, the better for you and your software

#31

Post by jstimpfle »

jryan49 wrote: post #26

> The vast majority of essential code is not operating on just one object – it is actually implementing cross-cutting concerns. Example: when class Player hits() a class Monster, where exactly do we modify data? Monster's hp has to decrease by Player's attackPower, Player's xps increase by Monster's level if Monster got killed. Does it happen in Player.hits(Monster m) or Monster.isHitBy(Player p). What if there's a c…

> It does read kind of nicely IMO...

And this one line is why you're willing to setup all these crap boilerplate supporter classes and take a huge hit in runtime performance?

Re: The faster you unlearn OOP, the better for you and your software

#32

Post by tree_of_item »

eitland wrote: post #6

I read this quickly to see if this was the piece that should convince me. It was not. It is, IMO, a collection of strawmen. People have abused OOP? Yes. But - citing FizzBuzz Enterprise Edition (which is really funny even for us Java/.Net developers because it is so horribly wrong) or writing this - Because OOP requires scattering everything across many, many tiny encapsulated objects, the number of references to the…

Maybe you should go back and read it slowly, as it was a good argument.

> again IMO, demonstrate that the author never really understood OOP.

This is what they always say...strange how OOP is the one paradigm no one ever seems to understand, no matter how much is written about it. Seems to me like there isn't actually anything to understand.

Re: The faster you unlearn OOP, the better for you and your software

#33

Post by crazygringo »

jryan49 wrote: post #26

> The vast majority of essential code is not operating on just one object – it is actually implementing cross-cutting concerns. Example: when class Player hits() a class Monster, where exactly do we modify data? Monster's hp has to decrease by Player's attackPower, Player's xps increase by Monster's level if Monster got killed. Does it happen in Player.hits(Monster m) or Monster.isHitBy(Player p). What if there's a c…

Great point... but doesn't it continue to prove the author's point that this is needlessly complex?

It strikes me as bad design if something as simple as an action (hit) now needs to become it's own class that is instantiated merely to execute a single function and then have to delete itself. That just feels like insane overhead/boilerplate, no?

The argument here is that it's far better to have player and monster be simple data structures, and a single function hit(player, monster, weapon).

Re: The faster you unlearn OOP, the better for you and your software

#34

Post by Michaelanjello »

I completely agree. For a DataStore in Python, I may often use a Pandas DataFrame or such. For random label-based access it can have an index too.

Unfortunately, when asked to design an OOP architecture in a job interview, if you don't adhere to its religious enterprisy notions, you can risk failing the interview.

Re: The faster you unlearn OOP, the better for you and your software

#35

Post by DanielBMarkham »

There's something very important here. It also tends to be overstated. As a former OOP guy, I struggle with explaining what's going on with people that don't see it yet.

Perhaps beginning with praise might work best. OOA as a group analysis tool is probably one of the most powerful things coming out of computer science in the past 50 years. Oddly enough, nobody does it much. Many if the problems this author brings up with OOP actually work for the best in OOA.

It's not all bad. But there are problems with where we are. Big problems. We need to understand them.

Re: The faster you unlearn OOP, the better for you and your software

#36

Post by jryan49 »

jstimpfle wrote: post #31
jryan49 wrote: post #26

> The vast majority of essential code is not operating on just one object – it is actually implementing cross-cutting concerns. Example: when class Player hits() a class Monster, where exactly do we modify data? Monster's hp has to decrease by Player's attackPower, Player's xps increase by Monster's level if Monster got killed. Does it happen in Player.hits(Monster m) or Monster.isHitBy(Player p). What if there's a c…

> It does read kind of nicely IMO... And this one line is why you're willing to setup all these crap boilerplate supporter classes and take a huge hit in runtime performance?

A lot of languages are made for this kind of interaction and can inline stuff hopefully, but that's the job for the VM or compiler.

I didn't say it was the "right" way to do it. Also programming is the art of tradeoffs. If this does actually give bad performance, maybe it's a trade off the programmer is willing to make.

Just like the article started off with "I don't think there's a silver bullet". OOP is a tool just like any other with pluses, and minuses.

Also the Hit class may be a Singleton and only instantiated once.

Re: The faster you unlearn OOP, the better for you and your software

#37

Post by jcelerier »

jstimpfle wrote: post #31
jryan49 wrote: post #26

> The vast majority of essential code is not operating on just one object – it is actually implementing cross-cutting concerns. Example: when class Player hits() a class Monster, where exactly do we modify data? Monster's hp has to decrease by Player's attackPower, Player's xps increase by Monster's level if Monster got killed. Does it happen in Player.hits(Monster m) or Monster.isHitBy(Player p). What if there's a c…

> It does read kind of nicely IMO... And this one line is why you're willing to setup all these crap boilerplate supporter classes and take a huge hit in runtime performance?

> And this one line is why you're willing to setup all these crap boilerplate supporter classes and take a huge hit in runtime performance?

at least in C++, why would they ? it'll all gets inlined and you can do it so that there isn't any memory allocations if you know all of your cases at compile time (of course most of the time you want to be able to add new weapons, behaviours, etc, at runtime but in game engines you generally use scripting languages for this anyways).

Re: The faster you unlearn OOP, the better for you and your software

#38

Post by jryan49 »

crazygringo wrote: post #33
jryan49 wrote: post #26

> The vast majority of essential code is not operating on just one object – it is actually implementing cross-cutting concerns. Example: when class Player hits() a class Monster, where exactly do we modify data? Monster's hp has to decrease by Player's attackPower, Player's xps increase by Monster's level if Monster got killed. Does it happen in Player.hits(Monster m) or Monster.isHitBy(Player p). What if there's a c…

Great point... but doesn't it continue to prove the author's point that this is needlessly complex? It strikes me as bad design if something as simple as an action (hit) now needs to become it's own class that is instantiated merely to execute a single function and then have to delete itself. That just feels like insane overhead/boilerplate, no? The argument here is that it's far better to have player and monster be…

The Hit class may be a Singleton and only instantiated once. Creating a class is like 3 actual lines. Also at least in Java the Hit class can be an inner class of the Person class. It just feels like name spacing in that case.

It is needless complex if the code is simple.

This solution is more flexible that just a pure function. If you have different players who use different hit strategies how do you handle that with just a pure function? Lots of if statements in the function? Passing in lambdas in every case you call the function? Then you could curry the function and call it something different too and that works I guess. OOP shines when you have lots of different ways things can work in different combinations. OOP is a tool like other programming paradigms, you use it when it solves your problem better than the other ways.

Re: The faster you unlearn OOP, the better for you and your software

#39

Post by itronitron »

eitland wrote: post #6

I read this quickly to see if this was the piece that should convince me. It was not. It is, IMO, a collection of strawmen. People have abused OOP? Yes. But - citing FizzBuzz Enterprise Edition (which is really funny even for us Java/.Net developers because it is so horribly wrong) or writing this - Because OOP requires scattering everything across many, many tiny encapsulated objects, the number of references to the…

Yes, people have abused OOP and every other programming paradigm or tool as well. It's probably a necessary aspect to learning something new... do something contrived, atrocious, and trivial in order to understand the concepts.

The OOP naysayers seem to often knock the textbook examples, but there are a lot of creative things that can be done with OOP that get around the criticisms.

Re: The faster you unlearn OOP, the better for you and your software

#40

Post by ced »

I've never liked classical OOP much, but multiple dispatch is a lovely paradigm. One doesn't define _classes_ per se, but rather just plain old boring structs.

   struct Player
       xp::Int
   end

   struct Monster
       hp::Int
   end

   function hit(p::Player, m::Monster)
       p.xp += 10
       m.hp -= 20
   end
The nicest thing is how one one doesn't need inheritance to "add a method" to an object. One just defines my_function(s::String) to be whatever, and it doesn't interfere with anyone else's code.
Post reply on HN