As the title of my post indicates, I'm wondering: Why use classes in programming? To put it differently, what can I do with classes that I can't otherwise, or that greatly simplifies a particular task?
I've read various explanations about this, and I understand them intellectually, but I don't just don't "get" it. I did a little bit of programming in the 80s, in languages w/o classes (BASIC, Pascal, little bit of Assembler, though this got very tedious). Since I know how to get things done by procedural coding, I wind up writing all of my Phrogram programs sans classes, too. This irks me, since I want to learn more about oop.
I've worked through various examples, like the chapter in "Phrogram Programming for the Absolute Beginner." But all those examples are -- sorry -- lame. Like I said, I understand them, but I don't see the point.
I'm currently working on a "Defender" clone, and I could incorporate classes easily enough ... for example, there could be a class "EnemyShips" which all have certain associated methods/functions (e.g., spawn, move, shoot, explode). But how is that better/easier than doing all of those things without classes?
Well, for one, I am making a class that will create two (or more) consoles, and write to them.
Cipherboy
3.14159265358979323846264338327950288419716939937510582097494459230781640628620899
Interesting battles I think - sort of along the same lines...interesting to see what others say;
Perhaps a hardware example might drive the point home....
Suppose you want to build a computer. You could start with resistors, capacitors, chips, and wire and spend the next year or so trying to wire them all together so they work as planned, or: You might go buy a motherboard, soundcard, power supply and the rest in pre-assembled packages and hook them up. First off, you'd have far fewer connections to make, and secondly, you can be reasonably certain the different subsystems work as intended.
Compare that with programming where the procedural programmer has to keep track of every variable, every array, every pixel on the screen and whatever else is used for display. Whereas the OOP programmer would have subsystems to handle windows, subsystems to handle lists and so on.
In many cases (not all) OOP makes the programmer's job easier. For a real world example, can you calculate the sin value of a given angle? If I ever knew how, I've forgotten it by now. That's why I am glad there is a Math class that has all those common functions easily available. Do you know how to get input information from the Windows mouse? If it weren't for the Mouse class, you would have to figure it all out for yourself! The same can be said for all the included classes in Phrogram. They are there to simplify your efforts in building programs.
If there is something you need that isn't supplied, you have the capablility to build it. If it is something you might use several of, then it makes sense to capture all the needed code into one module and replicate the module, rather than duplicate code hither and yon in your program. A simple button to click on, for example, might be used several times on any given display. In addition to having to draw it, the program also needs to know if the mouse has clicked on it. So a button class might have Location and Size properties as well as a Draw method and HitTest function. The programmer can then define several such buttons for use in his program, where all he need do is set the Location and Size properties and tell it to Draw. In three lines of 'main line' program code, he has a button on the screen. When he detects a mouse click he can call the HitTest to see if that was the button clicked on.
That was a simple example, and sure you can have a Draw method and HitTest function where you pass in some sort of index to an array that has location and size values for the many buttons, but the point is that rather than having the arrays and extra functions in your program code, you can define a button on one line of code and get it all.
So when wondering what classes can do, look at Phrogram's own list of classes (Colors, Sounds, Sprites, Strings, etc) and think what your program would have to include if those classes weren't available.
Thanks for the thoughtful and detailed reply, LFS! That all makes very good sense.
Still -- and the following comments are NOT intended as a flame, but just me thinking out loud -- Phrogram's own classes were the first ... and, well, ONLY ... useful application of classes that I could think of. Maybe it's because I haven't written a lot of really long programs, and, when I want to re-use code, I just cut and paste; so, it could just be inexperience talking. But even Phrogram's classes do some things that just seem cumbersome to me. To stay with the example of the mouse, for example, how does it help things along to have to say something like:
Define MyMouse as Mouse
MyMouse.X = etc...
I mean, how many mice (mouses?) are we going to have? Why not just have a "GetMouseX" function/method without the prior step?
Or, take sounds. How is it better to say:
Define Screech as Sound
Screech.Load("Screech.wav")
Screech.Play
Than something like this:
Play(Screech, "Screech.wav") {where "Screech.wav" is specified only when not already loaded}
Though I guess the extra steps would be justified if there were more functions with which to manipulate a sound (like ".volume," ".duration," ".pitch," etc.).
Maybe the answer is just consistency ... or that Phrogram is trying to get programmers to use class-based syntax. And I do, in fact, find that the more I use it, the more intuitive it is becoming. But it still seems cumbersome in some cases, particularly ones like those I mentioned above.
As you may realize, high level programming languages are merely abstractions provided to hide the minute details of machine language code. They make programming easier to understand and do, correct? You might think of OOP as another layer of abstraction for the same purpose. A mouse is an object, it has properties that indicate user input. The keyboard is another object, the same with a file, or list, or point, or any number of other things a program might use.
In fact, the number of different objects a language might provide could be in the thousands of objects. Imagine how difficult a language might be to learn if there were tens of thousands of commands. On the other hand, encapsulating functionality into classes makes the language more discoverable. Things that have to do with the mouse are all in the Mouse class. Keyboard interaction is all in the Keyboard class, and so on.
Your own programming can extend that metaphore (or not - its up to you). You already put code related to a specific task into a subroutine, and likewise, you can organize routines that belong together into classes. It is just another step up in making things a little more organized in addition to being a little more representative of the physical world. We all live in a world filled with objects. Some are more organized with the objects they posess than others, but we all deal with objects on a daily basis. Creating programs that have objects is just a natural step in transitioning the 1's and 0' of machine language into something more in line with how we think and act on a daily basis.
I hope that helps!
To address your specific cases..
The mouse class can be accessed without creating an instance of it... So you can say "CursorSprite.X = mouse.X" without having to define the mouse. Strange but true.
How is it better to say:Define Screech as SoundScreech.Load("Screech.wav")Screech.PlayThan something like this:Play(Screech, "Screech.wav") {where "Screech.wav" is specified only when not already loaded}
Performance.
If you say "Playsound("Screech.wav")", Phrogram has to stop whatever it's doing, find the sound file, load it, play it, discard it, then continue. This can take several precious milliseconds.
But if you use the Sound class, you can load the file into memory before you need to play it. When you do play it, it's already been loaded, so there's no need to take all those extra steps.
Whil you can create a scenario where performance would be affected (e.g. if you need to load once and play later) the fact is that the lines of code as written are equivalent. In fact the OO version might even be slower (though I doubt you can measure it on a modern computer) sincethere are multiple function calls.
Its really a style and abstraction thing it makes code more readable and avoid large parameter lists too. Without classes and OO you can't have inheritance either.
I personally think of it as a fail-safe. When you write procedurally, and you start using a lot of global variables that are being accessed and changed by multiple functions all over the program, errors creep in. Yes you can take some working code and cut and paste it into another program, and this will work fine for small simple programs. When you write a really large program, it is much easier to plop in a working class that protects it's own data/variables from being used incorrectly.
Phrogram doesn't force you to use get() and set() functions for class variables, so you do access the class variables anywhere in the program, but if it did, then the class variables would be protected from being fed incorrect data. Classes often contain a whole lot of error checking code, and rewriting and debugging all that error checking code over and over again seems like an awful waste of time. If you have a pre-existing class, that protects it's variables from mis-use then you never have to worry.
It also makes it much easier for you to debug your own code. You never have to look inside the Mouse class to see if the error is occuring there. You know the Mouse class does what it is supposed to do, and there should be no way for you to mis-use it.
Just a thought.
Blackmagic