classes objects

[richcash]

Could someone tell me how classes can be useful. I know that they can interact with each other and all but what does that mean, and when does it become useful.
I learned classes from F10 Help (how horrible it is, I only learned the syntax) and from what I can see there is no situation to use a class where a simple module can't be used instead. I know now that classes are much more powerful, but how and when? As far as I knew objects are just modules (of a class). So, what's the difference? Why will I learn to LOVE classes?

[richcash]

Alright, it seems like part II and part III of Cervantes class tutorials is what I'm looking for. I'm okay now. However, if anyone wants to just give a brief idea of why objects are better/different than modules than it would still be appreciated. I'll add any help I need while reading to this thread, so it's not completely useless!

[Delos]

I'm assuming you've read Cervantes' authoritative tutorial on Classes. If not, then go do so now. Then, read wtd's Relfections on OOP. Don't fret if you don't understand any of the syntax (or musings for that matter), the point is simply to prime yourself.

Let's take a simple example. Say you wanted to make a simple particle engine. I did say simple right ^_^.
Here's a brief description of what's going on:
- create a programme that will manipulate a variable number of graphical points on a screen. The programme must be able to move these, change their colour, shape, and path.

Simple enough? Take a look at [Gandalf]'s Fireworks [FP] for an example of a particle engine if you're still a little confused.
Now on to the discussion.

There are two ways of approach this, or at least two ways that we'll discuss. The first would be to do this in a modular fashion, the other woudl be in an object oriented fashion. Granted some will consider modules objects, but for the sake of argument we'll considering these two in terms of their paradigm.

MODULAR APPROACH
In this approach, we create a Module of Particles. This will be the 'engine' as it were, that controls each of the particles. The particles themselves will be a sub-aspect of the Module itself. You could envision it thusly:

pseudo:

module Particle_Engine    export init, move, draw    type particle :      record      end    var les_particles : array [] of particle        proc init (in_particle_ref, in_x, in_y, in_size : int)    end    proc move (in_particle_ref, in_dX, in_dY : int)    end move    proc draw (in_particle_ref : int)    end draw end

Simply read, this is a stub of a module that will allow one to initialize a set of particles, to draw them, and to move them. Active syntax would look something like this:

pseudo:

for i : 1 .. 100    Particle_Engine.init (i, 100, 100, 100)      // Let's say this creates 100 particles all at the same place, and size. end Particle_Engine.draw (1)                            // Draw the first particle. Particle_Engine.move (1, -3, -3)  // Move a specific particle a bit. Particle_Engine.draw (1)

This works perfectly well for our simple purposes. Adding all the other flare would be simply a case of improving upon our existing code. As it stands, we have a good ground work upon which to build our particle engine.

OOP APPROACH
In this approach, we create a set of objects. Each object will be attributed to a particular class, which means that we'll be able to tell it how to behave. Here, the particles are effectively independant entities each and of themselves.
A possible outline:

pseudo:

class Particle    export init, move, draw    // some pertinent variables are declared here.  Or perhaps a type as above.    proc init (in_x, in_y, in_size : int)    end    proc move (in_x, in_y : int)    end    proc draw ()    end draw end

Now, the active syntax looks like:

pseudo:

var some_particles : array 1..100 of pointers to Particle   // Pointers!  Yes. for i : 1..upper (some_particles)    new Particle, some_particles (i)      // See note on Pointers. end some_particles (1) -> init (100, 100, 100)         // initialize a particle some_particles (1) -> draw () some_particles (1) -> move (-3, -3) some_particles (1) -> draw ()

This syntax works just as well as the Modular approach. But wait, there's a significant difference here! Instead of an engine controlling the movement of a bunch of implicit parts (les_particles in this case), we have a set of explicit objects (some_particles) whom we can actively manipulate instead. This is a subtle point that might be considered stylistic until fully understood - would you rather have a chunk of code completely in charge of your objects (Modules) or would you rather have your objects in charge of themselves (OOP)? This, is the beginnings of what is OOP. Notice how in the active code it's the objects themselves that have the arguments passed to them, while in the Modular approach it was this giant hulking (or invigoratingly vibrant) control that did things to its sub-parts.

I've structured this discussion so that one can see some blatant similarities between the two approaches well at the same time hopefully spotting some nifty differences. I will own right now that I haven't the background to make a more convincing case - I'm not a CompSci major, but I have a fairly well-grounded understanding of what I do know. There will, no doubt, be a host of others dropping by here explaining to you the more intricate details of why OOP is such an applicable and effective art.

Note on Pointers: See above note. I couldn't explain them to you if I tried, so I won't ^_^.

[Cervantes]

Classes and modules are not the same. You use classes to create objects. Objects are instances of a class.

So you could create an object from a Unit class, and that object would have all sorts of internal data. If you were to try to use a module for this, aside from just not making logical and intuitive sense, you could only have one Unit.

If you wanted more Units and wanted to use modules, you'd have to hack something ugly together. Let's see what that might look like. First, we need to create a type to store the units data:

code:

type Unit_T :     record         % stuff     end record

Next, we create our module to store all the methods our Units will need:

code:

module Unit     % define methods end Unit

So this module will contain all the methods we need. Every method will have to take at one parameter to represent the Unit we are performing this method on, in addition to any other parameters they might take.

Is this looking ugly? Maybe not, if you haven't seen the beauty of OOP.

Using OOP, we package all this, data and methods, into a single object. (Actually, the methods aren't located with the objects, but it seems that way to the programmer. This is just a speed optimization.)

code:

class Unit     % internal state -- variables     % define methods end Unit % Now lets create a slew of Units var my_units : array 1 .. 10 of ^Unit for i : 1 .. 10     new Unit, my_units (i) end for

Then things get even more beautiful when you start considering inheritance and polymorphism, which allow us to considerably reduce the amount of code we write by enforcing the DRY (Don't Repeat Yourself) principle. If an object is the same as another existing object but with a few modifications, there's no need to rewrite the whole class for that modified object; just have that class inherit from the other class and change what you need to.

Then there's the idea of data hiding. It doesn't make sense to let everyone read (and worse, manipulate!) the internal state of an object. Some things just need to be kept hidden. Like my credit card PIN. Using OOP allows us to hide certain data. This is more than just a security thing. It allows us to regulate what other parts of our own program can modify. We get another layer of control, and thereby make debugging easier.

Have you read the tutorials here at CompSci.ca? They're far better than the articles in the Turing Help Manual, if I do say so myself.

[richcash]

Thanks for clearing everything up Delos and Cervantes! After reading the tutorials, I think I'm finally good on object oriented programming, and it's way better than procedural programming in most cases!!! Now I just need to gain some experience with it!

Quote:

Have you read the tutorials here at CompSci.ca? They're far better than the articles in the Turing Help Manual, if I do say so myself.

Yes, they are by infinity!!! Mentioning Cervantes' tutorials on classes and Turing Reference's classes in the same sentence should be outlawed.