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.

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.

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.

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.

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]