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

221–230 of 252 posts

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

#221

Post by pas »

mannykannot wrote: post #214
bassman9000 wrote: post #202

Earlier quoted context omitted.

And you end up having functions that look like. hit(player, monster, weapon, damage_modifier, arena, previous_turn, next_turn, global_modifiers) because the author didn't like, or understood encapsulation.

In the OO version of this pathology, these arguments become the instance variables of a class introduced to do nothing more than hold them. Poor design has a way of cutting across programming paradigms, or even (in the case of inappropriate inheritance, for example) leveraging their features.

What's wrong with config/value holder objects? Most OOP languages can store them as simple structs in memory.

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

#222

Post by pas »

fenomas wrote: post #121
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…

> You end up with: > Player.hits(Monster).with(Weapon) I think games are a particularly pathological case for OOP, and as such probably not a good example for the article's case. But FWIW, the problem with what you describe (and with OOP for games generally) is that game logic tends to be way too polymorphic for code like that. That is, players don't just Hit() monsters, they also hit items, traps, breakable terrain,…

ECS https://en.wikipedia.org/wiki/Entity%E2%80%93component%E2%80... for others like me who had no clue.

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

#224

Post by lerno »

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…

Been exactly there with a game. Solution? Take a data centered approach: a command object (just a function really) updates HP, XP, triggers visual effects etc. Monster and Player classes are just thin wrappers around plain data structures.

I tried the more ”OO”-approaches for all too long thinking it would lead me right. It doesn’t.

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

#225

Post by ricardobeat »

luord wrote: post #223

Most of the problems pointed out can be reduced into "confusing indirection as abstraction", which is a sin of many OOP developers, particularly those obsessed with design patterns. IMO, OOP is not inherently any more flawed than any other paradigm.

This claim is not refuting any of the points presented.

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

#227

Post by armitron »

hota_mazi wrote: post #167
timbit42 wrote: post #147

Earlier quoted context omitted.

Smalltalk does "OOP" properly because it focuses on message passing, the real benefit of "OOP". Any OOPL that isn't based on message passing is degenerate.

Right. Because Objective C and Smalltalk are such resounding successes, uh?

Going by what you write here, we should all praise PHP and Javascript.

Popularity amongst the masses of 9-5 brogrammers who code for money and have no artistic sense when it comes to programming doesn't really imply quality. All the programming languages that are truly technically great - today - have small userbases. They're not easily digestible by mediocre coders, require some upfront effort and an open mind. Since the vast majority of professional programmers today are average at best, languages like Erlang, Haskell, Ocaml, Lisp, Smalltalk will never be popular.

It follows then that when looking for quality one should actually reverse popularity.

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

#228

Post by corebit »

matwood wrote: post #92
corebit wrote: post #74

> Data is more important than code Nope. Right there at the beginning is where the author goes off track. Computation itself is the most important aspect of computing. Code and data are just complexity to manage. > Do I have a Customer? It goes into class Customer. Do I have a rendering context? It goes into class RenderingContext. I whole heartedly agree with this. The naive approach to domain modelling is to classi…

I disagree. SICP says "“In programming, we deal with two kinds of elements: procedures and data.” If we reduce that further it is really just data.

There is no one without the other.

The data is unintelligible randomness without some algorithm to process it

The code cant exist without some data schema to reference and has no value if there's no data instances to process.

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

#229

Post by mannykannot »

pas wrote: post #221
mannykannot wrote: post #214

Earlier quoted context omitted.

In the OO version of this pathology, these arguments become the instance variables of a class introduced to do nothing more than hold them. Poor design has a way of cutting across programming paradigms, or even (in the case of inappropriate inheritance, for example) leveraging their features.

What's wrong with config/value holder objects? Most OOP languages can store them as simple structs in memory.

It has nothing to do with efficiency. Insofar as Bassman9000's example indicates a real problem (and there are a couple of ways it might do so, ultimately leading back to the poor use of abstraction and separation-of-concerns), stuffing the arguments (or any other weakly-related collection of variables) into an ad-hoc struct (or object) having no real cohesion is simply sweeping the dust under the rug, and is just as indicative of a likely design problem as are long argument lists of nominally unrelated data.

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

#230

Post by rafaelvasco »

Don't know why people keep insisting on this. OOP is a model. Functional is a model. Data oriented is a model. We as programmers just have to use them , in the most effective way possible to architect a solution to a problem. No one model of those can substitute any other. They complement themselves. There is bad OOP and effective OOP, just as there is bad Functional and effective Functional. The models are never bad by themselves. The programmers are. Any programmer that bashes OOP in favor of any other model is just making a fool of himself and exposing his ingenuity.
Post reply on HN