Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
*TRUE* OOP and Other Paradigms
#1
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). So the discussion went on for a couple of posts, until one came up and said "but that's only because what you use is not "TRUE" OOP. That was when I thought that maybe I'd be talking out of turn if I continue arguing any further.

So yes, what is true OOP anyway? 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?

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'm quite surprised to see people trying to enforce sticking to one style throughout. Why not mix as necessary?
[Image: signature.png]
A-Engine: A new beat em up game engine inspired by LF2. Coming soon

A-Engine Dev Blog - Update #8: Timeout

Reply
Thanks given by:
#2
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.
Ultimately, my constant dissatisfaction with the way things are becomes the driving force behind everything I do.
[Image: sigline.png]
LF2 IDE - Advanced visual data changer featuring instant data loader
LF2 Sprite Sheet Generator - Template based sprite sheet generator based on Gad's method
[Image: sigline.png]
There is no perfect language, but C++ is the worst.
Reply
Thanks given by: A-Man
#3
(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 :D
Age ratings for movies and games (and similar) have never been a good idea.
One can learn a lot from reinventing wheels.
An unsound argument is not the same as an invalid one.
volatile in C++ does not mean thread-safe.
Do not make APIs unnecessarily asynchronous.
Make C++ operator > again
Trump is an idiot.
Reply
Thanks given by: A-Man , kairunotabi
#4
Quote: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 admit I was one of those who thought OOP is the "professional" way of doing it, and I still haven't truly played with it enough yet. It's just that every time I'd come to search for documentation/tutorials..etc on a subject matter, I'd always see it done with classes. It's similar to how I feel now about C++'s generic template programming when all you find on google is templated funclets calling each other, so feel free to correct me if I'm wrong :P.

Quote: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?
The thing is that what a responsibility means can be broken down too much. For instance, this guy makes a "toss a coin" game where he actually writes a class for the coin (methods are bool isHeads() and void flip()).

Edit: Also, Getters or public member variables?
[Image: signature.png]
A-Engine: A new beat em up game engine inspired by LF2. Coming soon

A-Engine Dev Blog - Update #8: Timeout

Reply
Thanks given by:
#5
(04-02-2016, 08:59 PM)A-Man Wrote:  Edit: Also, Getters or public member variables?

So you're finding it impractical to use getter/setter meanwhile a public variable just works?
Most of the time yes, you don't need it and C++ surprisingly does not have accessor methods (or syntactic sugars for getter/setter functions) so it actually is kind of ugly. But:
Why Use Getters and Setters

"Procedural code gets information then makes decisions. Object-oriented code tells objects to do things."
— Alec Sharp
Ultimately, my constant dissatisfaction with the way things are becomes the driving force behind everything I do.
[Image: sigline.png]
LF2 IDE - Advanced visual data changer featuring instant data loader
LF2 Sprite Sheet Generator - Template based sprite sheet generator based on Gad's method
[Image: sigline.png]
There is no perfect language, but C++ is the worst.
Reply
Thanks given by: A-Man
#6
Ah, very good reasons there for using the former. But note that I never said getters/setters are impractical; I use them myself all the time. I was just asking for your opinion/opening it up for discussion. The point about being able to add an error checking layer later sold me.
[Image: signature.png]
A-Engine: A new beat em up game engine inspired by LF2. Coming soon

A-Engine Dev Blog - Update #8: Timeout

Reply
Thanks given by:
#7
Setters are often a sign of a poorly designed interface, because values are usually related (length of a dynamic array is related to the data in the array), so allowing them to be modified in isolation can often cause bugs, and many properties that really can be changed in isolation are often set once when the object is created and then never changed again (color of a label for example), so allowing the value to be arbitrarily changed at runtime is a terrific way to waste memory.
Sometimes of course the above does not apply (or you don't care about memory wastage), and in that case setters are a fine thing to use, but it is worth thinking twice about your decision.

Other than that I find it is usually easier to develop an idea when I have access to everything, so I often start out with simply writing a regular struct, and then add member functions to it over time, and eventually, when I have a good idea of what the interface should be, I can then make the member variables private.
Age ratings for movies and games (and similar) have never been a good idea.
One can learn a lot from reinventing wheels.
An unsound argument is not the same as an invalid one.
volatile in C++ does not mean thread-safe.
Do not make APIs unnecessarily asynchronous.
Make C++ operator > again
Trump is an idiot.
Reply
Thanks given by:
#8
(04-03-2016, 09:24 PM)Someone else Wrote:  Setters are often a sign of a poorly designed interface, because values are usually related (length of a dynamic array is related to the data in the array), so allowing them to be modified in isolation can often cause bugs, and many properties that really can be changed in isolation are often set once when the object is created and then never changed again (color of a label for example), so allowing the value to be arbitrarily changed at runtime is a terrific way to waste memory.
I completely disagree. Setters are not often poor design. Sometimes they are, but it's rare and not hard to notice (like your length example). The real problem is public variables, they are head to head against encapsulation.
Also, your label color example is horrible. Why would I waste memory for assigning color a different value? Why on earth color of a label is not changed in runtime? And why should it be immutable?
Ultimately, my constant dissatisfaction with the way things are becomes the driving force behind everything I do.
[Image: sigline.png]
LF2 IDE - Advanced visual data changer featuring instant data loader
LF2 Sprite Sheet Generator - Template based sprite sheet generator based on Gad's method
[Image: sigline.png]
There is no perfect language, but C++ is the worst.
Reply
Thanks given by:
#9
(04-04-2016, 03:54 PM)Nightmarex1337 Wrote:  Also, your label color example is horrible. Why would I waste memory for assigning color a different value?
Because the color needs to be stored once per label, but if it is the same for many labels it only needs to be stored once for each.

(04-04-2016, 03:54 PM)Nightmarex1337 Wrote:  Why on earth color of a label is not changed in runtime?
Only a small minority of labels need to have their color changed at runtime, so enforcing that every label might have its color changed is wasteful and completely unnecessary.
Take a look at the settings menu I wrote for my LiveSplit plugin (Click to View)
None of the labels need to change color. They all have the exact same color, only one label needs to change its text, and other than that changing text is done with text boxes.
Actually the only things that needs to have their color changed are the boxes specifically for selecting a color.

Allowing every label to dynamically change its color is wasteful. Some programs might not care (for example the program I wrote above) and the simplicity of having just a single do-it-all label might make it worth the waste, but the programmer should at least be aware that what he/she is doing is inefficient.

(04-04-2016, 03:54 PM)Nightmarex1337 Wrote:  And why should it be immutable?
If it doesn't change, then I assume we both agree that ideally it should be immutable. As above the simplicity might be worth the waste, but the programmer should at least be aware that it is wasteful.
Age ratings for movies and games (and similar) have never been a good idea.
One can learn a lot from reinventing wheels.
An unsound argument is not the same as an invalid one.
volatile in C++ does not mean thread-safe.
Do not make APIs unnecessarily asynchronous.
Make C++ operator > again
Trump is an idiot.
Reply
Thanks given by:
#10
So it's performance vs memory. But the latter is usually way more abundant, so storage is what I'd try to stick with as well.

Quote:The real problem is public variables, they are head to head against encapsulation.
In the presence of automatic hooking of members assignment to setter functions, or in case one happens to be so sure he'll only need to set one variable, and only set that one variable, there wouldn't be a difference (besides using a pair of brackets instead of '=').

What do you think of friends? Now that and encapsulation would be head-to-head in a way.
[Image: signature.png]
A-Engine: A new beat em up game engine inspired by LF2. Coming soon

A-Engine Dev Blog - Update #8: Timeout

Reply
Thanks given by:




Users browsing this thread: 2 Guest(s)