81–90 of 252 posts
Earlier quoted context omitted.
> What probably is true however is that a lot of people should unlearn the OOP they learned in school. Can you provide references for proper OOP?
The Java Swing API is a good example of OOP done well.
If there was a worse example of over-engineering and crappy difficult to use API that would be Swing.
Here's another bit of food for thought along those lines, though: If you take all the elements of what's typically considered to be good object-oriented design to their logical extremes, you end up with a bunch of objects that each have exactly one operation, and are configured at construction time. They may have some very simple internal state (think counters and caches), but you probably want to keep that to a minimum.
The end result starts to look very, very similar to functional programming. An interface with one method is essentially a function. Constructor arguments do basically the same job as closures. Etc.
When you're looking at things from that perspective, the big difference is that functional languages almost force you to work that way, whereas it takes consistent, conscious effort to do it in OOP.
Earlier quoted context omitted.
Over-optimizing as in, write the one obvious line instead of 15 lines of crap that are also slower?
Until you get a decent combat system in and now your hit has to go through 30+ calculations. It's almost never as simple as "monster.HP - damage". Besides, if we really want to be snarky, why haven't you wrote it in assembly for performance?
Why not in assembly? Because it's not worth the effort. You won't notice any difference in speed. Be pragmatic.
Earlier quoted context omitted.
The Hit class may be a Singleton and only instantiated once. Creating a class is like 3 actual lines. Also at least in Java the Hit class can be an inner class of the Person class. It just feels like name spacing in that case. It is needless complex if the code is simple. This solution is more flexible that just a pure function. If you have different players who use different hit strategies how do you handle that wit…
Languages that force you to use the singleton pattern really ought to just let you write A FUNCTION
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,…
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…
>Because it's easy
There are lots of cases when forcing yourself to stick to OOP styles or programming is much less easy. You could look at various comparisons of code line counts of equivalent programs between C# and F# code as some basic examples.
I don't mind having classes that can inherit available in a language, but languages like Java and C# that force you to use only those things leads to a lot of unecessary boilerplate. You can work around this with static classes full of static functions that you can treat as 'modules' full of free functions. Which, is what I do a lot :D
But I wish I didn't have to bother with that workaround.
> 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…
This does read nicely in most cases. There are minor issues when you venture off and decide that it would be cool if a monsters could damage your weapon. Something like Monster.hits(Weapon).with(Weapon). You'll start wondering if Weapon should inherit from the player base class. If not, you'll spend time wondering how to share the code to keep things dry. Obviously there are many solutions even within OOP, but one mi…
Probably not. If you want to do that, they should both implement an interface (and perhaps share some code through composition) but code inheritance is likely not the right approach here.
Earlier quoted context omitted.
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…
The Hit class may be a Singleton and only instantiated once. Creating a class is like 3 actual lines. Also at least in Java the Hit class can be an inner class of the Person class. It just feels like name spacing in that case. It is needless complex if the code is simple. This solution is more flexible that just a pure function. If you have different players who use different hit strategies how do you handle that wit…
I'll list a few strategies I've seen in different contexts:
1) Clojure has "protocols", which is a strategy of doing polymorphism where the verb is charge instead of the noun.
2) Rust has trait objects, where you have to implement the polymorphic behavior you want for a separate player type but the data is separate from the behavior and not interlinked or owned by the class. You can implement the behavior in the scope of the module where it is used.
3) You already mentioned this, but lambdas in Javascript or functors in C++ satisfy a lot of specialization requirements.
All 3 of these approaches are different ways of approaching the problem of different behavior on the same data. The key thing with them is that it allows domain specific behavior to be decoupled from an owning object. There may be reasons that OO is more suited to a problem (as you mention), but I tend to agree with the author's post around the dogma of using OO everywhere.
In the article, the author also mentions a quote around encapsulation
> Encapsulation is an object-oriented programming concept that binds together the data and functions that manipulate the data, and that keeps both safe from outside interference and misuse.
In my opinion, this view of binding the data and behavior together stems from an idea that data is scary and can be changed at any time. In an immutable, pass-by-value, functional world, those getters and setters and indirection is just another thing in my way from composing the data together with collections tools I am very familiar with. I think it was Neal Ford who said that "OO encapsulates moving parts, whereas functional programming removes moving parts." I think that's very appropriate in this context. In a data-first view, you model what properties and data shapes you care about in your records, and then you create little functions that connect those things together; in OO, you create the links first through methods (even if those have interfaces), and you're stuck with those connections anywhere you want to pass the object.
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…
Should be pointed out that this refers to C++/Java/Ruby/python style objects, and not smalltalk/erlang style objects, which is a message passing model for data storage.
Could someone enlighten me as to how Java style OOP differs from Smalltalk's variant? I've read the Alan Kay quote on how he's sorry for focusing on objects instead of message passing but I'm still unsure on how Smalltalk is so much better not having used it.