Hacker News new | past | comments | ask | show | jobs | submit login

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.


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.


Why is no cohesion, in, let's say a HitEvent object? This knows the target, source, method (weapon, magic, physics like falling down), etc. You can make handy helper methods and subtypes depending on important concerns.

I don't get the adhocness of the example.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: