Objects, classes, why?

[sKunKbad]

I've read a couple of things about objects and classes, but I can't seem to understand why they are used. The explanations are bizarre. Does anyone have a sample of some code that shows 1) standard code, then 2) improved OOP code? Just curious to learn how this can help me.

[btherl]

Objects are a convenient way of grouping data in one spot, along with the functions related to that data.  They also have features for declaring what data and functions are public and private, also for convenience.  That's all.  End of story

 

Here's an example:

 

$cat = array(
  'name' => 'Kitty',
  'food' => 'Whiskas',
  'sound' => 'Mrrow',
);

function cat_sound($cat) {
  print "{$cat['name']} goes {$cat['sound']}\n";
}

 

or..

 

class Cat {
  var $name;
  var $food;
  var $sound;

  function sound() {
    print "{$this->name} goes {$this->sound}\n";
  }
}

$kitty = new Cat();
$kitty->name = 'Kitty';
$kitty->food = 'Whiskas';
$kitty->sound = 'Mrrow';
$kitty->sound();

 

Yep, it's not all that different.  Some people like it, some people don't.  I still write traditional style code, even though I understand OO and know that it is available.

 

Serious OO programmers would provide methods for getting and setting name, food and sound, which also allows the class to decide how to process data as it goes into and out of the class.

[KevinM1]

OOP is the answer to a programming problem.  As programs grew more complex, they also grew inefficient and hard to maintain and debug.  The reason is that procedural programs tend to have a lot of coupling, where one section of code is tightly bound to another section, and a change in one necessitates changes in others.  Flexibiliy and extensibility were hard to come by in a procedural-programming-only environment.

 

The whole point of OOP is to modularize code to facilitate extensibility while reducing dependencies on the core code.  Each idea in a program is made into its own discrete system (classes and objects).  These systems can be combined in many different ways at runtime (composition), which results in a very flexible system overall.  If done correctly, addon modules can be plugged in or removed from a core program without negatively effecting the user's experience.

[btherl]

You forgot the negative aspects.. which I feel I am compelled to mention, since you claimed that "OOP is the answer"

 

- Decoupling reduces opportunities for optimization.  As a result, OO code is always slower and takes more memory than traditional code.  It's a tradeoff.  Where speed and memory are at a premium, OO code is the wrong choice.  Where speed and memory grow on trees but reliability and speed of development are critical, OO is the right choice.

- OO code is slower to develop initially, due to the overhead of the OO framework.  The tradeoff here is that OO code is easier to re-use later.

- OO taken to excess or applied inappropriately will lead to bad code.  This is true of any other programming technique of course

[448191]

- Decoupling reduces opportunities for optimization.

 

Please do explain.

 

Oh, and Nightslyr said the answer to A problem. Please don't twist peoples' words.

[btherl]

Sorry, I misread.  Nightslyr did indeed say "a programming problem".

 

To answer your question, have you seen the processor and memory requirements of Windows lately?  OO has improved its reliability greatly, but it also increased its requirements for cpu power and memory.  Most people don't notice because computers have gotten so much bigger and faster.  But here I am with 1GB of memory, and wishing I had more.

 

For a simple programming example, is it faster to have your query object fetch the data and then pass that data to the display object to display, or to simply display it directly?  The first is more flexible, the second is faster and more memory efficient.

[448191]

That is not an answer to my question. OOP, especially when thrown together quickly and with disregard of performance implications, requires more memory, and a little more processing power too. I'm talking about your statement that "Decoupling reduces opportunities for optimization". I don't think I agree with that, and I'd like to see some actual arguments to support it.

 

Yes, for a simple programming example procedural is faster and more efficient. This statement only exposes the bad scalability of procedural. If you want something remotely scalable, you'll have to use OOP.

 

On a sidenote; what you are describing is a completely different issue.

 

My take on what's (partly) the cause behind that:

 

First, programs have gotten more complex. You can point fingers at OO, but I think MANY programs would have never seen life if it wasn't for OO because they would've been unmanageable otherwise. Then there's the big conditional. Complex procedural seems to suffer from conditional mania. The scattering and mirroring of conditionals not only make complex procedural hard to manage and buggy, but also creates logical pitfalls where conditional logic is repeated. We're just trading RAM for processing power that way.

 

Secondly, developers are lazy. I think performance is more of an issue in web development than in desktop programming, because we already have network latency to deal with. Desktop programmers don't have this concern. Also because of the rising demand on system resources because of increased complexity of programs has some other lazy programmers dealing with less complexity (but possibly a very tight schedule) care less about efficiency.

 

Thirdly, developers are too lazy. Reusabilty can easily be taken too much advantage of. Harry makes one component, Sally needs something similar, though not quite the same; ah what the H, we'll just use what we need. But Harry's component is copyrighted so Sally has to load the whole thing into memory while she only needs a tiny part of it. Harry is probably lazy, and didn't optimize his component. So Sally's blindly using an unoptimized component in an inefficient way.

 

"A good programmer is lazy programmer", but there's an other side to the coin.

[sKunKbad]

Btherl, thanks for the code example.

 

I just got back from a fishing trip, and was surprised to see how far this thread has gone. From reading the thread posts I understand a little more about why classes and objects would be used.

[utexas_pjm]

If you want something remotely scalable, you'll have to use OOP.

 

I have to disagree with this statement --Linux seems to scale pretty well.

[448191]

You are right, that statement is taking things a little too far. Plenty of C examples to prove me wrong. 

[emehrkay]

If you want something remotely scalable, you'll have to use OOP.

 

I have to disagree with this statement --Linux seems to scale pretty well.

 

linux isnt oo? if not, how do they manage to keep up with the code?

[utexas_pjm]

The Linux Kernel (http://en.wikipedia.org/wiki/Linux_kernel) itself is written in C (and some assembly language) which is a procedural language.  I, personally, think it's a myth that only code which utilizes object oriented design (OOD) can be easily maintained.  I'm a huge proponent of OOD, in fact at work I'm known as an OO Purist, however I think that when people learn OOP they tend to dismiss procedural programming as a lesser, or somehow less eveolved form of development.  I've heard people say that procedural code doesn't scale, can't be maintained, and even loses portability --all of these claims, I believe, can be dispelled by citing some prominant highly scalable, maintained and portable applications; namely: Linux, Apache, MySQL and PHP.

 

Best,

 

Patrick

[448191]

Yeah, you definitely have a point, and it is easy to get carried away with OOA&D (with that I mean get a little too hung up on it).

 

OOD makes it a hell of a lot easier though, and maybe that is the point that should be brought across. Big procedural projects may be manageable with the right organization and discipline, but that very statement implies that at least for me personally, it is unmanageable. 

[btherl]

I get your point, 448191.  I agree that optimized OO objects will work well together.

 

I think I'm thinking about decoupling rather than OO itself.  Decoupling whether in traditional programming or in OO.  It's a nice idea, but so often it leaves me thinking "If only that library/object knew what I wanted to do, then it would have provided the right interface".

 

In those cases I choose development time over efficiency, as that's what business needs dictate.  Hardware is cheaper than programmers   Things remain decoupled and efficiency is lost, and we compensate with bigger and faster machines.

[448191]

I think I'm thinking about decoupling rather than OO itself.  Decoupling whether in traditional programming or in OO.  It's a nice idea, but so often it leaves me thinking "If only that library/object knew what I wanted to do, then it would have provided the right interface".

 

Then something, somewhere, is going wrong. The interface shouldn't be an issue either way though. Some structural base class will be responsible for providing the right interface to the client code. This interface should make clear what the component is capable of. Specific implementation are hidden behind this interface, so perhaps that is what you are talking about, but I still don't think this has any performance implications.

 

Within the component cohesion will be higher, operations and data clustered and focused it spots like star clusters in the universe (imaginative fellow, aren't I?  ). If anything, this will increase opportunity to optimize. It will definitely make it easier, since all related code that might be sensitive for some type of optimization is centered a single place.

 

I do see your point too though. More accurately, I think that's a possible side effect of abstraction. When something abstracted to a degree where performance will suffer, you probably have a design issue that should be solved by implementing implementation specific code, hidden behind a generic interface. The implementation specific code can still be decoupled to some degree from the generic code. 

[Jenk]

The Linux Kernel (http://en.wikipedia.org/wiki/Linux_kernel) itself is written in C (and some assembly language) which is a procedural language.  I, personally, think it's a myth that only code which utilizes object oriented design (OOD) can be easily maintained.  I'm a huge proponent of OOD, in fact at work I'm known as an OO Purist, however I think that when people learn OOP they tend to dismiss procedural programming as a lesser, or somehow less eveolved form of development.  I've heard people say that procedural code doesn't scale, can't be maintained, and even loses portability --all of these claims, I believe, can be dispelled by citing some prominant highly scalable, maintained and portable applications; namely: Linux, Apache, MySQL and PHP.

 

Best,

 

Patrick

They are ultimately more difficult to maintain, and require heavy interaction from a source controller to ensure that code is kept in relevant groups. Masses upon masses of documentation are needed for projects like Linux Kernel; variable names, references, etc. Not need in OOD due to interfacing and so forth. Most of the time you don't even need to know the class name of your object, only what interface it has. This cannot be done in Procedural; so there is precisely no polymorphism - you must explicitly know what, where and when your resources are going to be available, and must know not only what your resources are, but also what the name of the variable containing those resources are. Not so in OOD.

[utexas_pjm]

I found this site: http://www.geocities.com/tablizer/myths.htm, to be kind of interesting.  I don't agree with everything that this guy says (in fact he reminds me a lot of an older developer I work with, with whom I've argued OOP versus Procedural with countless times) --but he does raise a few interesting points and even succeeds in debunking a few myths propagated by the OO purists (of which I consider myself a member).

 

Best,

 

Patrick

[448191]

Good read, thanks for that.