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

Post by theprotocol » Sun, Nov 25, 2018, 3:43 PM UTC

hliyan wrote: post #93

fermienrico wrote: post #73

Earlier quoted context omitted.

New to OOP programming. Could you explain what sort of arguments are presented against using OOP? I am genuinely curious.

I've been programming for 15 years (so I was around for the rise of OOP). There's nothing fundamentally wrong with OOP. I still write a lot of classes. But what I haven't written in a almost a decade: code with inheritance, encapsulation or polymorphism. Nothing has exploded. Also, objects are best when used to represent actual objects (i.e. collections of data rather than collections of functions). This is OK User u…

Post by leiroigh » Sun, Nov 25, 2018, 3:45 PM UTC

jcelerier wrote: post #49

ced wrote: post #40

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,…

> One doesn't define _classes_ per se, but rather just plain old boring structs. in which language are there differences between classes and structs ?

Post by fenomas » Sun, Nov 25, 2018, 3:47 PM UTC

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…

Post by jstimpfle » Sun, Nov 25, 2018, 3:49 PM UTC

matthewmacleod wrote: post #97

jstimpfle wrote: post #31

Earlier quoted context omitted.

> 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?

I'm pretty confused by how you perceive this. I don't see "crap boilerplate supporter classes" – I see objects that encapsulate events and actors for all the usual OOP reasons. I wonder if some of this disagreement is down to the way that different people abstract this problem in their heads.

   // player.hits(monster).with(weapon)

   add to class Player {
       // XXX: Bad coupling Player -> Monster
       // XXX: Bad coupling Player -> PlayerMonsterHit
       method hits(Monster monster) {
           return PlayerMonsterHit(player, monster)
       }
   }

   class PlayerMonsterHit {
       member Player player;
       member Monster monster;

       construct PlayerMonsterHit(Player player, Monster monster) {
           this.player = player;
           this.monster = monster;
       }

       method with(Weapon weapon) {
           doTheActualFrigginHit(this.player, this.monster, weapon);  // this line is all we REALLY need
       }
   }

Post by iokevins » Sun, Nov 25, 2018, 3:50 PM UTC

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…