Sign in to follow this  

Why is OOP so strict

This topic is 4379 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
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
The OOP methodology is basically a set of guidelines to follow when you don't have the time to figure out an idea solution to the problem.

If you go outside OOP for a small part of your project, the result may not fit well with the larger part of your project.

Here's a badly thought out physical analogy: Suppose you have cause to design an electrical device, and an electrical socket to plug it into. You could make a specialised socket which is in some way enhanced for that device, but then other devices couldn't be plugged into it. You then have the bother of needing to make an adapter if you want the socket to be more generally useful.

Similarly, the rules in OOP are put in place to make it easier to piece the various components of a system together, particularly when those components aren't written by you.

What's important isn't OOP in and of itself. What's important is that OOP is a common protocol for software design which make interoperation easier. There are other such protocols, some of which overlap OOP, some of which are entirely unlike OOP, and all of which are 'good' within their sphere of influence.

Edit: Another analogy: The SI units (meters, seconds, kilograms, et al) are a common protocol for measurements. There's nothing particularly special about the SI units. Their value comes purely from the fact that lots of people use them. The international scientific community could easily use other units, and indeed they sometimes do: e.g. astronomers commonly use the AU and parsec as units of length: but geologists never do.

Most languages are designed around a particular paradigm.

Almost all languages support the procedural paradigm, which calls for processing instructions to be encapsulated into procedures/subroutines/functions.

Many support the "generalised object-oriented paradigm" (which is a phrase I just made up), which calls for data to be encapsulated into structures, and for operations upon those structures to be encapsulated into methods.

Java supports a specialised object-oriented paradigm. Some patterns which would satisfy the GOOP are disallowed in Java. Some ill-advised Java proponents would say that such patterns are "not OOP", but it would be more accurate to say they are "not Java OOP". Still, it is advisable to avoid such constructs if they can reasonably be avoided, since neither Java nor programmers who use Java exclusively are well-suited to comprehending them.

C++ sports a fairly generalised OOP, and also features a limited form of the functional paradigm. In this paradigm, functions are objects which can be manipulated and constructed by functions just as any other data can. In Java terms, functions-as-objects isn't OOP.

The keynote is to use whatever paradigm suits your language, your audience and yourself. If you have sufficient confidence in all three, you can just forget about paradigms entirely.

But if you don't, it's best to pick a paradigm and try to stick to it. If you need to skirt around OOP, use friends, protected members, or package/module-level access restrictions to provide the 'non-OOP' interface to those components that need it, but also provide an OOP interface to everybody else. e.g. Let some classes direct access to the member variable 'fooBar', but also provide methods for working with it. This will help prevent the non-OOP parts leaking into your entire program, which might lead to major headaches.

Share this post


Link to post
Share on other sites
Quote:
Original post by raptorstrike
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?


Maintenance. All object orientation ever really buys you is ease of maintenance, by keeping things well separated, by making them interchangeable, by isolating implementation from interface. Quite often, the quick and obvious fix does not hold up well when you need to change related things later.

eg. You could allow public access to an object's variables, because it's straightforward and it works. Then later, you might create a function that only works if 2 of the variables are kept in sync. However your public access may mean that you weren't doing this properly somewhere in the code, and now it breaks. If you'd stuck to the 'OOP' method in the first place, and used getter/setter functions (or properties, in languages that support them, for the best of both worlds), then this couldn't happen.

Share this post


Link to post
Share on other sites
Functions are objects, too.

The problem with most "OOP purists" is that they use languages with underdeveloped notions of "object," like C++, where it typically means "instance of a user-defined class." The use of a more robust language will quickly teach you that every construct in your language can, on some level, be considered an object, and this can free you from the rigidness of trying to create a class to represent everything. Instead you may learn to focus on leveraging many of the built-in objects and types (including functions, enumerations, scalar values, etc) to build an elegant, compact and maintainable design.

Share this post


Link to post
Share on other sites
Quote:
Original post by Oluseyi
Functions are objects, too.

Hmm, I disagree.
I'd say an object has to have a state before it can be considered an object.
A function doesn't have state (Unless you're working in C++ and add a bunch of static variables to it)

But to answer the OP's question, OOP is so strict because it's a goddamn religion. At least, that's what it is to the people who are strict about it. Some people believe that OOP should be used in its strictest, most basic sense, to solve *every* part of every problem.
They're wrong. [wink]
As Oluseyi (and most others) said, don't try to force everything into a strict OOP structure.
Plain old functions, and other not-strictly-OOP features definitely have their place as well.

Share this post


Link to post
Share on other sites
Quote:
Original post by Spoonbender
Quote:
Original post by Oluseyi
Functions are objects, too.

I'd say an object has to have a state before it can be considered an object.
A function doesn't have state


In most programming languages each value has at least one state. Some (such as functions without side-effects) have only one state. Others (integers, functions with side-effects) have more. Do you mean that objects should have at least two distinct states, and be able to go from one to the another? How does that arbitrary reduction help? Why would enum { FOO, BAR } be an object, but not enum { FOO } ?

Quote:

(Unless you're working in C++ and add a bunch of static variables to it)


Or you decide to save yourself a lot of pain and use a language that supports closures.

Share this post


Link to post
Share on other sites
I think that OOP is there to easier solve large and complex problems.
Lets say game engine. There is OOP way and non OOP way.
In non OOP way you will have a prgoram that calls a many functions that will work on mass of global variables. And OOP way is that you separate code into logical structures like Camera , Graphics , Timer , Keyboard , etc...
and then you can work one by one. So when lets say you finish Timer which measures time calculate FPS .. , and latter you see that you will need to implement various timers (lets say for unit has a 1 sec cooldown ablity) like stopwatches you could just add that to the Timer class and every other class that use Timer class will automaticaly be updated to support newly created enchantment. So this is what OOP gives to us :
1. Writting less code and
2. (more important ) Reusability

I read this somwhere today
"Good artist knows picture is never finished, best artist knows when to stop."
ill "recode" it:
Good programer knows that he/she must use OOP, best programmers knows where to not use it.

I use this rule : "use OOP only where you think it will lead you to the 1. or 2."

Happy coding !!!

Share this post


Link to post
Share on other sites
Quote:
Original post by Spoonbender
Quote:
Original post by Oluseyi
Functions are objects, too.

Hmm, I disagree.
I'd say an object has to have a state before it can be considered an object.
A function doesn't have state (Unless you're working in C++ and add a bunch of static variables to it)

Are you sure? How about functions in languages that are less rigid than C++, like LISP? Try this in the Python interpreter:

>>> def f():
... pass
>>> dir (f)
[results intentionally omitted]
>>> type (f)
[results intentionally omitted]


[smile]

Share this post


Link to post
Share on other sites
Quote:
Original post by Spoonbender
Quote:
Original post by Oluseyi
Functions are objects, too.

Hmm, I disagree.
I'd say an object has to have a state before it can be considered an object.
A function doesn't have state (Unless you're working in C++ and add a bunch of static variables to it)

But to answer the OP's question, OOP is so strict because it's a goddamn religion. At least, that's what it is to the people who are strict about it. Some people believe that OOP should be used in its strictest, most basic sense, to solve *every* part of every problem.
They're wrong. [wink]
As Oluseyi (and most others) said, don't try to force everything into a strict OOP structure.
Plain old functions, and other not-strictly-OOP features definitely have their place as well.


Object don't have to have state; some of the best design's I've seen broadly divide objects into data carrying objects (stateful) and data processing objects (stateless).

People are strict about OOP because conceptual integrity is the most important architectual characteristic of a project.

Share this post


Link to post
Share on other sites

This topic is 4379 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this