> It's just, well, maybe not something that the ordinary web-programmer will
> benefit much from at the beginning. Very true - I find object more scalable too, from the code itself, all the way to the size of the project. Many of my classes have started out being just 10 lines, but some have increased greatly and without classes, this would have been a nightmare to maintain. As you said: > OOP had answer to all of this. Modules that can't be touched, which exist > by themselves. You could really get a module from somebody else and put it > right into your program. The module could be full of variables that had the > same names as yours. "i, pageLength, sum". While earlier we'd have to > carefully prefix variables with something to make sure they didn't clash > this problem was gone as the variables only existed inside the module. -----Original Message----- From: Frank [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 06, 2002 11:48 AM To: [EMAIL PROTECTED] Subject: Re: [PHP] OOP .. I just don't get it. Many years ago I wrote something for newcomers into OOP. I have cut a snippet out of it and added some comments. Sorry, it became rather long. Hope it helps somebody. Frank " OOP is the art of designing "objects", then creating and killing them. An object is a box with handles. We can operate it without disturbing anything else. We can make them and kill them as needed. When the first radios were designed they were very spaghetty. Though the designer had a idea of what modules he needed he'd freely with a lot of wires interlink all over the place, simply because it was the easiest and fastest thing to do. And the radio was made and worked fine. The drawbacks: Not a single piece of work could be used in another radio unless the engineer would enjoy sorting out all the possible wires and what could happen in any part of the radio. And getting help was hard unless the helper was interested in understanding the entire construction. He could not disconnect any particular part of the radio and test it alone. Independent modules were the answer. The engineer had always had these in mind conceptually - but in his work they just happened to get mixed up with wires and as complexity grew the benefit of soldering the little extra wire from A to B were later outweighted by the costs above. So increasingly the development grew towards small units with well-defined input and output which dramatically changed the entire industry. Suddenly high complexity could be made in a module which could then be sold to many different manufacturers of radios. Programming had exactly the same problems. Though programmers were well aware - and did it well - of the importance of making modules something were missing. The ability of creating modules that could be designed so their state, data and functions existed isolated from everything else. Another problem: a customer once ordered a little program where he on the screen could build up a page for printing. I made it, it worked fine - and then he said "It would be great if I could have two pages at the same time and swap between them." Hmm. Instead of just using nLines to hold the numbers of lines of the printed page I now had to use nLines1 and nLines2. I was smart enough to make the nLines and other variable into an array nLines[1..nPages] if he should get ideas of more pages. I proudly went back to him and say "Now you can decide on your own maximum of pages needed!" Great, but would I always in the future have to use arrays instead of simple variables if somebody had the need for more "something" at the same time? I tried that. The cost was more clumsy code, slower to write and execute - and most often only one instance was ever needed. OOP had answer to all of this. Modules that can't be touched, which exist by themselves. You could really get a module from somebody else and put it right into your program. The module could be full of variables that had the same names as yours. "i, pageLength, sum". While earlier we'd have to carefully prefix variables with something to make sure they didn't clash this problem was gone as the variables only existed inside the module. The printer-page application of above - now I wouldn't have to sit and decide whether to use arrays or simple variables. I'd simply write the description of how this printer-page worked (called a "class") and then I could make and kill as many of them as I needed. class MyPrintpage { variables... functions... } This class didn't "make a page" like the old code would have done. It just described _how_ to make it. And it didn't take one bit more time to write than in the old style. To actually "create" a page we could use we wrote MyPrintpage p1; If we one day needed two we'd write MyPrintpage p1, p2; And when we didn't need it anymore we would write delete p2; and the memory was freed. An amazing difference! " (End of snippet of old article.) OOP seems to me to be in everyday programming to be a little less natural to use in PHP because of the short lifetime of the script. Imagining Windows applications programming without ability to create and destroy objects is flatly impossible in praxis. But PHP-scripts for web-pages tends to deal with one-shot functionality from a single input. Rarely much is build (though that wouldn't necessarily have to be so.) Accessing a MySQL database and fetching rows does not call for objects. Etc. In other words - OOP is not immediately pressing its way in as a necessary concept. When I did C++ I only did OOP - in PHP rarely. That is not to say that OOP is not of value in PHP. It very much is and many valuable classes have been designed where old-style design would have been senseless. It's just, well, maybe not something that the ordinary web-programmer will benefit much from at the beginning. No need to feel that you are missing out on something smart you should have done instead. I haven't checked the code in details, but I wonder if excellent PHP tools like PHPmyAdmin, Phorum etc. is using OOP at all? Learn OOP along the way. But maybe focus on good style etc. etc. in the beginning. My 0.02$ Frank -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
