101–110 of 252 posts
However I mostly am working on web apps so maybe this approach is more suitable to such apps.
When working on desktop apps, during my initial days as a programmer, I found OOP based ui systems easy to grasp, but then this could be due to lack of experience.
This is presented as a basic truth and then not really backed up, as far as I can tell. Why must I apply the order as the author believes?
>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 cl…
> 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 class Weapon involved? Do we pass it as an argument to isHitBy or does Player has a currentWeapon() getter? I don't see how this is a pr…
This is a problem because we don't just want "any old design that sorta kinda works" but a guiding principle to our design, and to find the optimal place for each action/data.
I'm always confused when people criticize OOP, because most of the time the criticisms they use are just plain bad programming. Or they're using hyperbole that isn't really useful. You want to know why OOP is useful and common? Because it's easy. Easy things allow for faster development, faster onboarding of devs. Humans need a mental models of things and OOP very explicitly gives it. But like most easy things, OOP s…
> You want to know why OOP is useful and common? Because it's easy. With as much proof as you have given, let me offer you a counterargument: it is common because academia loves OOP. It's easy to teach, it's easy to test. It is most decidedly not easy and very often not useful. My favorite example of how everything falls apart in due time is the color of a car. That's it, right? A car has a color. A Porsche Panamera…
1. communication
2. representation of concepts
1 is pretty obvious, and for a programming language this means communication between a person to a computer
2 might not be as clear, but if you know that people cannot count in languages that have no numbers, it becomes obvious. There is a tribe that only has 0, 1 and many, and guess what, they can't tell the difference between 7 and 8.
Now back to programming languages and their communication between computer and programmer: the old programming languages were very close to the computer. As languages evolved, they started to be become 'human', where it is easier for us to read and write them.
OOP in that sense leans very close to concepts of normal humans. Objects, things objects can do, objects have separate responsibilities, etc. It's easy for a human to have such a model inside his head, because we already do this every day.
Now as a programmer, most of the things that I need to do is make a representation of the real world into a program. Since the real world is made up of things that do stuff, it's easy to model it in such a concept.
Most arguments against OOP always come from either a theoretical or academic background.
But in the real world, with real companies, real problems to solve and real programmers, OOP is used. Because it lends itself really well for representing the real world in a computer model.
EDIT: not saying that anyone that doesn't use OOP isn't a real programmer. But those people are more into the algorithmic or mathematical problem space, not a problem space where a real-world concept needs to be modeled. Most software is like the latter, and therefore most programs are OO. Is it the best solution for everything? Definitely not.
Earlier quoted context omitted.
Over-optimizing as in, write the one obvious line instead of 15 lines of crap that are also slower?
These examples are supposed to be examples, not what we would actually do in this specific case. In a huge enterprise system that has 500 different ways something could be done, in which your function would have 30 million if statements, all which is dependent on runtime behavior, polymorphism can help solve that problem. Imagine there are hundreds of ways Hit can be implemented and used in different situations. That…
This is the typical argument you get to hear from OOP apologetists. And the codebase is rotting, just for concerns about hypothetical problems...
I remember one time when I was criticized for putting in too much global data and not enough classes "because what if we have two GUI instances?". The guy of course had no idea why he would want that, and how it should work.
Earlier quoted context omitted.
maybe this will then? http://www.smashcompany.com/technology/object-oriented-progr...
Unfortunately, no. While he hasa lot of good arguments, they're drowned out by his repeated use of logical fallacies to push his point across. This long, rambling piece simply comes off as him bullying the reader into agreeing with him. Note that I'm not saying he doesn't have valid points hidden in that wall of text, but he's certainly lacking the social skills and reader empathy to land a good argument, and as a re…
> Immediately comments with logical fallacy.
Earlier quoted context omitted.
Entity-Component-System, amusingly explained in this great talk from RustConf. https://www.youtube.com/watch?v=aKLntZcp27M
but... all ECS systems use classes or equivalent at some point