Encapsulation never was my favorite aspect of OOP too, in fact I always try to create different classes for data and code - it brings in a lot of benefits. But OOP patterns described by GoF are brilliant things in terms of code reuse and maintenance costs.
The faster you unlearn OOP, the better for you and your software
151–160 of 252 posts
Re: The faster you unlearn OOP, the better for you and your software
#152I'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…
It's not OOP that's the problem, but your mental model. There's no OOP language that says a car has to have one color.
You can define an object to have more than one color, or maybe instead of having a color have a color pattern. How creative is your imagination? If you use a tuple of (r, g, b) to represent color in a functional language, you will still have the same problem when you realize you can have multiple colors or design patterns. if your mental model has a mismatch with the real world, you will have problem at some point.
Re: The faster you unlearn OOP, the better for you and your software
#153Some things never die. comp.object on usenet (15+ years ago) had a regular 'guest' explaining why table-oriented programming is better than OOP: http://www.oocities.org/tablizer/top.htm
In the context of creating a formal model for decision-making, yes table-oriented design can be a superior choice.
Re: The faster you unlearn OOP, the better for you and your software
#154I'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…
New to OOP programming. Could you explain what sort of arguments are presented against using OOP? I am genuinely curious.
The best arguments against OOP, as it is done in most languages today, are made by Alan Kay, the creator of Smalltalk and the term "object-oriented". Alan should have used the term "message passing" so people wouldn't miss this component of Smalltalk that made it so great.
"I invented the term object-oriented, and I can tell you that C++ wasn't what I had in mind." - Alan Kay, Source: https://youtube.com/watch?v=oKg1hTOQXoY&t=634s
Re: The faster you unlearn OOP, the better for you and your software
#155This has been shared on HN many years ago, but I'm linking again in case there are younger engineers who might be unaware of this classic rant: Execution in the Kingdom of Nouns : https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...
Java type system is nominal not structural.
While this rant rung a bell at that time, i've always found that this rant was too easy. Java had non public class, annonymous class and import static at that time.
Nowadays, the Javaland has steal lambda and var from Scala, moving away from a real kingdom of nouns (partially, you still need those pesky functional interfaces).
Re: The faster you unlearn OOP, the better for you and your software
#156> Object-oriented programming is an exceptionally bad idea which could only have originated in California.
> — Edsger W. Dijkstra
I don't understand why Dijkstra gets quoted so often when he has been demonstrably wrong on so many topics (see his opinion on BASIC too) and he was such a dogmatic and unreasonable person overall.
Re: The faster you unlearn OOP, the better for you and your software
#157> 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…
"Then Hit reaches into said objects and deals with changing the HP, and XP."
This is not essentially different from what happens in non-OO code. OO purists would probably object to this as a violation of encapsulation, and would insist on objects receiving a hit performing the update to their state themselves.
Stepping back from this example and considering transactions in general, it is often the case that there are certain constraints to be observed, and in such cases, it is easier to verify the solution if it is done compactly in one function. In such cases, creating a class and instantiating it just to have that function would be pointlessly excessive obeisance to a principle, and making it a singleton would only underscore that point.
Re: The faster you unlearn OOP, the better for you and your software
#158I'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…
[deleted]
Re: The faster you unlearn OOP, the better for you and your software
#159Earlier quoted context omitted.
> 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…
Why is color of a car an issue with OOP? Without knowing your the use cases, neither of us will model it correctly for the job at hand. A car obviously has multiple colors. It has at least two: exterior and interior. Quite often there are two-tone colors. But as a manufacturer, I'm going to guess that each interior and exterior color scheme has an ID. If you are a car manufacturer, the interior and exterior color sch…
car -> list of parts -> part.color
Although in fact you should probably allow for composite parts with multiple sub-colors, where each part supports its own enumerated list of possible colors.
In spite of appearances, it's not a completely trivial problem.
Maybe OP meant that to someone doing naive modelling, defining a car class and then giving it a single color property is going to cause problems. Which of course it is.
And maybe also that OOP encourages this kind of superficial thinking. Initial ignorance - and initial assumptions - about the problem domain get baked into the architecture. It becomes increasingly hard to change them as time passes and code grows around them.
Essentially, OOP mixes up data schema and software architecture in a brittle way. Of course you can build abstract classes for variable schemas, but then you're really doing meta-OOP, and there are probably better options.
OOP isn't the only paradigm that does this, but the brittleness seems to be characteristic. If you keep your schemas separate and explicit it's not usually all that difficult to extend/change them. If they're buried in class definitions and you don't have a dependency map to see which part of the schema is used in which part of the code, non-trivial refactoring can become a complete nightmare.
Re: The faster you unlearn OOP, the better for you and your software
#160“OOP apologists will respond that it's a matter of developer skill, to keep abstractions in check.” In my experience, the proliferation and use of ORMs makes keeping abstractions in check nearly impossible... in fact, I see ORM use as the primary design decision leading to the bastardization and convolution of sound OOP design.
The conversion is about OOP, not ORM