Why is OOP so strict
Author
Almost everyone uses OOP (me included) but it seems like some people will avoid perfectly reasonable sollutions to a problem just because it isn't OOP. This doesn't quite make sence to me because often it is waste of time and enery to implement an OOP compliant method. I often see in posts or articles "It is generally not good OOP practice" or "this is frownd upon in OOP". Why?
thx for any explenation. I wish to cause no unfriendly opposition with this post just answers
[grin]
That has nothing to do with OOP and plenty to do with people who are dogmatic and (correspondingly) intellectually lazy. OOP is a useful abstraction mechanism which helps us decompose and deal with large problems. Magic bullet, however, it is not.
Could you give an example. Some people think that if they put everything in classes they are writing OOP code, I have seen code like this:
And yes they did actually use "2", not "To". In that case namespaces would be just as good, actually better since in the example you can create objects of type StringUtil which probably isn't a good idea.
So when people talk about OOP don't always listen, at least think about what they say, don't just assume it is correct.
class StringUtil{public: static void WStr2Str(std::string& pDest,const std::wstring pSrc); static void Str2WStr(std::wstring& pDest,const std::string pSrc);};And yes they did actually use "2", not "To". In that case namespaces would be just as good, actually better since in the example you can create objects of type StringUtil which probably isn't a good idea.
So when people talk about OOP don't always listen, at least think about what they say, don't just assume it is correct.
OOP has a place and time, but panacea is not what it is. I use OOP where I feel it would help me have a clearer, or easier to use design and implementation, I don't slather it everywhere just for the hell of it. Take my sub-system design as an example. Because of the way everything is supposed to be uncoupled, I ended up with a very procedural interface between systems, with functions in namespaces, with classes barely involved in the interactions. This probably could have been done with objects and classes, but it would have been dim, and hard to use, as well as being obtuse.
The gist of that ramble is, OOP, like everything in life, has a time and a place. Use it where you see fit, and don't hesitate to use some other way of dealing with problems if it's better/easier/clearer.
The gist of that ramble is, OOP, like everything in life, has a time and a place. Use it where you see fit, and don't hesitate to use some other way of dealing with problems if it's better/easier/clearer.
Just as the response has been, don't make OOP the hole through which everything must pass. When you start making round about code just to make it "OOP", you've lost sight of the purpose of OOP to make code easier to develop, maintain and scale (just as high level procedural programming did the same over assembly programming).
A good way to learn this is to download the Java SDK and docs. It's a freely available OOP language with a large amount of support (tutorials) available on the web. Learn how Java handles various programming concepts, see how the Java standard library uses OOP principles to accomplish various tasks, then do exactly the opposite and you'll be fine.
A good way to learn this is to download the Java SDK and docs. It's a freely available OOP language with a large amount of support (tutorials) available on the web. Learn how Java handles various programming concepts, see how the Java standard library uses OOP principles to accomplish various tasks, then do exactly the opposite and you'll be fine.
Hey, that's not fair. Java has at least three classes in their API that are actually sensible OOP practice... [lol]
You have to keep in mind that the Java library was started upon basically by a bunch of C++ programmers back in the days before the last C++ standardization (think no std namespace, little community understanding of what classes can do for you etc.) - so it's not surprising that they didn't necessarily get how to design good OO stuff properly - not to mention that the standard library has to be widely applicable.
Not withstanding that - OOP guidelines exist for a reason: they generally help with the task of keeping code *organized*, avoiding redundancy (IMHO the root of most if not all coding evil) and creating meaningful abstractions that make it easier to think about what you're doing (that in turn leads to not writing bugs by having to switch between seeing the forest and the trees and back again).
BUT - simple guidelines lead to simple understanding - which is often *wrong* understanding. "Think" is not a four letter word, and OOP is not a be-all and end-all. And life's too short to worry about ideals anyway.
OOP is useful for modelling things, in the same way that functional programming is good for describing algorithms, and procedural (imperative) programming is good for gluing useful bits together.
Not withstanding that - OOP guidelines exist for a reason: they generally help with the task of keeping code *organized*, avoiding redundancy (IMHO the root of most if not all coding evil) and creating meaningful abstractions that make it easier to think about what you're doing (that in turn leads to not writing bugs by having to switch between seeing the forest and the trees and back again).
BUT - simple guidelines lead to simple understanding - which is often *wrong* understanding. "Think" is not a four letter word, and OOP is not a be-all and end-all. And life's too short to worry about ideals anyway.
OOP is useful for modelling things, in the same way that functional programming is good for describing algorithms, and procedural (imperative) programming is good for gluing useful bits together.
Quote:Original post by raptorstrike
I often see in posts or articles "It is generally not good OOP practice" or "this is frownd upon in OOP". Why?
Because a lot of people have already tried it and found it to be a bad idea.
Quote:
BUT - simple guidelines lead to simple understanding - which is often *wrong* understanding. "Think" is not a four letter word, and OOP is not a be-all and end-all. And life's too short to worry about ideals anyway.
That link reminds me of a quote I thought up in art class during high school.
A good artist knows the work is never completed. A great artist knows when to quit.
It's been something of a motto for me to keep my head straight through the years. [grin]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement