Jump to content
  • Advertisement
Sign in to follow this  
raptorstrike

Why is OOP so strict

This topic is 4715 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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]

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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:


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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!