(03-31-2016, 06:51 PM)A-Man Wrote: [ -> ]I'm not sure if it's just me being oblivious of this for so long until now, but lately, it seems there has been a greater number of people bashing the OOP style. I don't often involve myself into such discussion, but this one time I did say that OOP works better for games (I know because I've tried imperative for games, and things get messy rather quickly).
Imperative does not exclude object-oriented programming, nor does OOP exclude imperative programming.
(03-31-2016, 06:51 PM)A-Man Wrote: [ -> ]So yes, what is true OOP anyway?
True OOP is a myth. As with anything there are multiple definitions of what OOP entails. People typically agree on inheritance, (dynamic) polymorphism and encapsulation, and unanimously agree on objects (duh). The best definition of true OOP I can think of is relying exclusively on OOP paradigms in your programming, and if that is the definition for true OOP then it is terrible for everything.
Typically when I think of object oriented programming I think of relying on inheritance and dynamic polymorphism as a way to extend the program in the future, and you are overdoing it if that is the only thing you ever consider.
(03-31-2016, 06:51 PM)A-Man Wrote: [ -> ]What do you think of OOP in general, and what do you say of the "single responsibility principle"? The latter, in my opinion, might be sort of extreme and not practical. Would not strictly following it mean that you're not doing OOP?
Different ideas of OOP are nice, but way too many people think OOP is the only true way to program (and thus Java was born).
I am not particularly fond of dynamic polymorphism, because it is typically added in anticipation that you might want to override some functionality, but you pay the price of it even if you don't override anything, and very often problems can be solved simply through domain knowledge. Sometimes dynamic polymorphism is useful, like when you have a lot of stuff with with similar interface that may do wildly different things that has to be stored in a single container, which is rare though plugin systems come to mind.
Inheritance is typically used to enable dynamic polymorphism, for which I don't particularly like it for the same reasons I generally dislike dynamic polymorphism. For other use cases inheritance is mostly a hack, though admittedly very useful.
Encapsulation (including the single responsibility principle) is usually very nice especially for maintainability, but it is worth noting that CPU caches are not particularly fond of arrays of structs.
What are examples of where you find the single responsibility principle extreme and impractical?
It is worth noting that it can be worth doing something slow if it is not slow enough for you to care, or if you know you can fix it later if it turns out to be important that it is fast. I typically find encapsulating things
(03-31-2016, 06:51 PM)A-Man Wrote: [ -> ]What are your thoughts on functional programming, also? I like it, even though I don't see how one can write an entire program with that if the program isn't a one-liner.
I like the idea of functional programming, but it faces the issue that on all modern CPUs data is not immutable and memory is not infinite so it is fundamentally removed from the actual hardware it runs on.
(03-31-2016, 06:51 PM)A-Man Wrote: [ -> ]I'm quite surprised to see people trying to enforce sticking to one style throughout. Why not mix as necessary?
The only reason to enforce a particular set of paradigms is so all the people that work on a project only need to know a subset all possible paradigms. Other than that I agree.
(04-01-2016, 06:45 AM)Nightmarex1337 Wrote: [ -> ]I've recently seen this blog post about how bad OOP is.
I must say I completely disagree with that. I don't care about true OOP, (and I think we shouldn't) I break it where necessary and where it makes code more intuitive from my point of view.
I also don't find the article particularly convincing, as it has no concrete examples. The only thing that sort of stood out to me was the Message.send() vs Receiver.receive(), but my answer to that question is, what kinds of messages? Are we talking about a GUI? It is so abstract and removed from any real problem that it is meaningless.
So for once we agree