Classes, don't follow.

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
Ok I have read alot of things on, and other sites went
to the wikibooks to try to understand how to use a class.  I have this
project I want to do that I am sure would work great with a class.  I
just don't grasp the whole concept, and how to do it.

I want to make a Collectable Card Game Draft Engine...(if any of you
play VS System, LOTR, Magic: The Gathering, you know what I am talking

It would be way to complicated for just typing in regular functions and
calling em.

So this is what I've seen That I don't understand.

Say i have a database with cards that are common(c), uncommon(u),
rare(r) from 3 sets alpha(a), beta(b), unlimited(u).

I need to 1st create 24 packs that contain 11commons, 3uncommons, and
1rare each.

Bam thats a class.

would it look like this?
Class CreateDraft{
    var $set;
    var $rarity;
    function SelectRandomCard{
    //connect to database in file header
    $querycardbase = "SELECT * FROM `mtg_base` WHERE rarity = $rarity
AND set = $set LIMIT $rarity_num";//rarity and rarity_num are related
c=11,u=3,r=1, set dictates cards available.
    $querycardbase_result6 = @mysql_query ($querycardbase);
    while ($cardbaserow = @mysql_fetch_array ($querycardbase_result)) {

           $packarr = $cardbaserow[card_id]
    function InsertPack{
    $insertpack = "SQL STATEMENT INSERTING AN ARRAY";//I know, i know
its late and I just want to understand.

I guess I am asking for help.. Because I do not understand.

Re: Classes, don't follow.

First, PHP4 and PHP5 have different implementations of object oriented  
functionality. Being an optimist, I am going to assume you use PHP5.  
Please correct me if you are using PHP4.

What I see in your story is:
- You have sets and packs of cards. This may be just an array of card  
objects, or a collection class.
- You have a "generic" card object and special implementations of it.  
This suggests that the generic card is abstract, and the special(common,  
uncommon, rare) cards are extensions to that. But only if they BEHAVE  
differently (have extra methods or different implementations of some  

Best regards

Jace Benson wrote:
Quoted text here. Click to load it

Re: Classes, don't follow.

You're not exactly explaining what the problem is, and I have not a lot
of experience with PHP classes, but at first glance the
SelectRandomCard function is not so random. It will always return the
same decks for a given $set. Besides, your $packarr variable will
probably not work as an array, more like a simple variable being
overwritten every time through the loop.

Hope that helps. Anyway, it would help if you could point us at more
specific problems :-)

Re: Classes, don't follow.

Kimmo Laine wrote:
Quoted text here. Click to load it

Unless next_page.php generates PHP, the script with this include will
only get HTML.

Quoted text here. Click to load it


    if (isset($_GET['foo'])) {
      echo '<?php echo $_GET[\'foo\']; ?>';
    } else {
      echo '<?php echo \'Not available\'; ?>';

File not found: (R)esume, (R)etry, (R)erun, (R)eturn, (R)eboot

Re: Classes, don't follow.

Jace Benson wrote:
Quoted text here. Click to load it

I don't understand in detail what you're trying to do, but if you have a  
class called 'Create<anything>', the chances are you've not understood  

A class (or rather, an object of a particular class) represents a thing  
- in your application probably a pack of cards, maybe an individual  
card, maybe a set (alpha, beta), maybe a rarity (though that might be a  
single value, in which case there's probably no point in having a class  
for it).

Create would then be a method (function belonging to a class) - perhaps  
the constructor that every class must have, perhaps a different method.

If you declare a function inside a class as you have for  
SelectRandomCard, it is a method, so when it is called it will be called  
to operate on a particular object (instance of the class), and you need  
to refer to the properties of the particular object with the 'this'  
pointer: $this->rarity.

Don't use classes because you think they're cool: use them if you're  
prepared to think of your program in terms of creating and operating on  
objects (that know how they should be operated on).

I now usually approach any programming question in terms of objects, but  
it did take some work to get there!


Re: Classes, don't follow.

Hi Jace,

If you are used to procedural programming OOP can be hard to grasp in  
the beginning. The problem is that you see your computer as a single  
entity with a single processor and memory space. Your procedural program  
is essentially a list of instructions for this processor, referring to  
variables in this memory. You need to let go of that idea. Objects are  
more like the those beasts/puppets that run across your screen in a  
computer game like boulderdash: a whole bunch of entities that seem to  
live inside your computer, each doing its own things, remembering for  
itself what happend and what it is doing in its own private memory  
space, and interacting with one another.

With OOP, objects are things you can call methods on. If you call a  
method on an object, the object may do somthing. It may also remember  
somthing. What is does may depend on the things it has previously  
remembered. It is like a little home computer: you can type a command,  
it will print a reaction (or trigger an error if it does not know the  
command). You don't need to know how it works internally. You just need  
to know what will happen for each command.

But there's more. Objects are networked. When you call a method on one  
object, it may ask other objects to do things by calling more methods on  
them. If you call a function in procedural programming, you know what  
code will be executed. If you call a method on an object, you don't,  
unless you know what object you are calling the method on. But for  
making the method call you will probably use a variable in which you  
have put a reference to the object. So if at some point your code puts a  
different object in that variable, all method calls on that object may  
end up executing different code... Yes, object references are much like  
function pointers. Those objects can hold other objects in their member  
variables and make more method calls on those objects, and so on. This  
easily leads to a magnitude of spaghetty you can not even dream of with  
procedural code, even if you are using GOTO's! This spaghetty even  
changes dynamicly as the program changes the contents of variables! New  
objects may be created. References to objects may be returned and stored  

This is what classes are made for: To create some structure in the  
object spaghetty. Firs we classify all objects. Then we only define  
methods in the classes. So if you have a variable referencing an object,  
and you know the class of the object in advance, you know what code will  
be executed if you call a method on that object. Becuase most  
programmers somehow tend to know the type (class with subclasses) of  
what is in each variable, they can find their way in the spaghetty.  
Formally it's still very messy, but who cares, programming IS a matter  
of psychology after all ;-)


Henk Verhoeven,

Jace Benson wrote:

Quoted text here. Click to load it

Re: Classes, don't follow.

(I posted this also a few months ago in the XP yahoo group) When I  
explain object-oriented programming, I usually draw the parallel
to electronic devices.

When I was young, I had a tape recorder dating from about 1965. It came  
with a _huge_ electrical scheme that contained everything. You could  
look at it for hours and still discover new parts of that same tape  
recorder. For programmers, it looked a lot like an old BASIC program.

We don't build tape recorders like that anymore. Factories make not one  
tape recorder, but a whole line of them. With different size, colour,  
power, with an equalizer, with extra engine speed, etc.
If you open a modern tape recorder, you see that it is built up of  
sub-assemblies that are plugged together. You can easily change the tone  
control for an equalizer, or repair the left preamplifier by simply  
replacing it for a new one.
These are, for me, objects. They are separately testable (with unit  
tests), allow reuse (the line of tape recorders, but the preamplifier is  
also used in an MP3-player) and have a small task.
A plug is the object's interface. Circumvening the plug (exposing  
internal details or using global variables or singletons) is the same as  
hard-wiring a point on one circuit board to another. You can even SEE it  
is bad in electronics, because hard-wired objects are not separate  
anymore, cannot be separately tested, etc.

Best regards

Re: Classes, don't follow.

Well... I am trying to understand here.  Before I start, thanks for all
the information you've given me.

So please correct me if I am wrong.

Classes are a container.. if you will something to put what a <thing>
if for instance I was making a program on a pet.  I would want to label
it Class Pet
(dont be so tight on the gramatical errors, I am just trying to figure
this out).. Anyways In the class Pet I would put in it the
methods?(these are also the functions)? that the pet would do.  So say
I wanted to call the class pet and make a new instance of a dog and i
wanted that dog to poop.
 Would this be how i should look at that in OO programming?
//make this class
//classes dont create things methods do
Class Pet {
var $pets_name;
    function ChooseAPet() {
    //some function pulling data from an array printing
    //it to a form to select it and send it back with a name
Class Action {
var $action;
    function Action(){
    //this will be called whenever the class is caled
    //some thing like before but pulling data for what an animal can
    function Stop(){
    //something to stop an action for instance
    //a pet might take a long time to sleep but not long to jump
    function Create(){
    //when some actions happen things are created like stools

not the best example but this would be a valid theroized Class

I feel like i dont' get it.  I under stand to seperate is good, but I
am lost.

Re: Classes, don't follow.

In general, OOP is more or less what your example shows. The class
defines what the object is and can do, while the object actually *is*
something (an instance of the class) and *does* something. See if this
pseudocode helps...

Class Dog
var race;
var food_it_likes;

function Bark

function Poop

} //End Dog Class

//You have just defined what a dog is and can do, so that you can have
multiple dogs doing stuff. Then, in your program...

Dog Vincent;
Dog Toby;

Toby.race = "Scottish Terrier";
Toby.food_it_likes = "Tasty Chicken";
Vincent.race = "Chiuaua";
Vincent.food_it_likes = "Human Flesh";


//You now *actually* have two dogs who can bark and poop. One is
barking (Vincent the scary assasin little chiuaua), and the other is
pooping (Toby the elegant black Scottish).


Re: Classes, don't follow.

Samuel wrote:
Quoted text here. Click to load it
This is obviously not PHP syntax (Samuel even says it's pseudocode), but  
it could easily mislead people into a mistake that I kept making when I  

The PHP for some of those lines might be

$Vincent->race = "Chihuahua";



If you leave out the parens, it's an (undeclared) property (variable)  
not a method (function).


Re: Classes, don't follow.

Jace Benson wrote:
Quoted text here. Click to load it

Hi, Jace,

Samuel has given you an excellent example.  I'll try another (in a sec.).

The whole idea of object oriented programming is to bring "real world"  
objects into the "programming world".  That is, to create something in  
the programming world which mimics what we're already familiar with.

If you had a real world pet, would you think of it as performing  
"Action", "Stop" and "Create"?  Or would you think of it as performing  
"Bark", "Eat", "Sit", "Poop"?

The other example I've used in a lot of classes - an automobile.  Take  
some basic actions - start, stop, change gear, accelerate and stop.

The car itself keeps track of basic things like its running status, the  
gear it's in, its speed, and how much gas is in the tank.

When you "start" the car, some things must be in place.  The car must  
not already be started, there must be gas in the tank and the gear must  
be in park or neutral (assuming an automatic transmission).

To accelerate, the engine must be running, the brake off and the  
transmission in gear.

The beauty here is - you, as a user of the car class, don't have to  
worry about testing the various states - the car class will do it for  
you (for instance - lets say you add a new status "Battery Charged").  
You change the "Start" method to test for this - but don't need to  
change anything else in your program.

OO programming is a completely different way of thinking.  Interestingly  
enough, in my classes I've found the people with the least programming  
experience typically have the least trouble making the switch.  Those  
with lots of programming experience have the most trouble.  It's quite  
difficult to "unlearn" years of learning!

Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.

Re: Classes, don't follow.

I may be one of those people that have problems converting to the OOP way of  
thinking.  I understand the car example and understand the idea of objects  
doing things.  Where I seem to be having the problem is in trying to convert  
an exsisting Structured Programming style program into OOP.  My program  
basically allows users to upload files and manage them.  I have created  
files as an object and this seems to be OK, my problem is dealing with the  
display of the files.  This requires SQL queries and HTML tables.  How  
should I be thinking of these items in terms of OOP?

Am I causing myself more problems by trying to convert from an existing  
program?  Is there a good way to get started on determining which objects to  



Quoted text here. Click to load it

Re: Classes, don't follow.

Mark ??;-) wrote:
Quoted text here. Click to load it

One quick way to think about conversion is that objects are all the  
nouns and methods are all the verbs. This is somewhat simplistic but  
often is a good way to start.

When you say you have encapsulated the files as an object, does this  
mean that you have a file object or that you have objects that access  
files? In the first example, you would have generic methods (read,  
write, delete, create) that concerned all files as a generic type. In  
the second example, file access would simply be a product of satisfying  
a method on an object.

Put another way - are you sure that 'file' is an appropriate object when  
talking about 'display' methods? I think it is more likely that you want  
to display a specific instance of a file or some object that simply uses  
a 'file' to satisfy some of its methods.

For example: The 'car' object may use a file object, a database object  
and an HTML object to assist in the implementation of certain methods,  
but the real object (noun) used by the system is 'car'. We would want to  
have methods like 'save', 'load' and 'toHTML' as file, database and  
display methods of the object 'car'.

// instantiate a new car object
$car = new Car();

// read in the data for an Acura 3.2 TL
$car->load('Acura 3.2 TL');

// make the car red

// display all the data including the color as HTML

Now the 'load' method may actually use the File object to read in the data.


function load($model) {
    $file = new File();
    try {
        $this->carData = $file->read($model);
    } catch( Exception $e ) {

As for conversion of structured code, it really comes down to how well  
you can divorce the intent of the code from the implementation of the  
code. What is the code really trying to achieve? What objects is it  
really dealing with? How may these be implemented in an object model and  
what methods does each object then need to support?

Try taking one path through the existing code and seeing which objects  
and methods would make sense. Now add another path. Does your model  
change and how?


Re: Classes, don't follow.

Quoted text here. Click to load it

I have file objects.  Basically I have a form that gets input from a user  
including things like date, time, section, and the selected file.  I am  
considering this my file object, which I will then upload, display, or  
delete.  Maybe I need to create different objects to deal with the display  
portion, I don't know.

On a slight tangent..the file information form consists of several <select>  
lists which allow users to select the day, month, year, etc.  I've have  
tried turning this group of selects into a class, but I am having problems  
with the array of values.  If I post the code would someone be able to guide  
me through the process of converting this group of functions into a class?



Re: Classes, don't follow.

Mark ??;-) wrote:
Quoted text here. Click to load it

I think you are confusing the file object concept with the file instance  
concept. When the user fills in your object - either via the constructor  
or via setter methods on it - it is dealing with an instance of the  
object. The instance should be able to produce an HTML representation of  
itself in just the same way it could product a regular text  
representation of itself with, say, var_dump().

So, let's say your file uses setter methods. Your code for file would  
look something like this when used as an instance:

$file = new File();

Then when you wanted to express this instance of the object File as  
HTML, you would use the toHTML() method (or build the HTML via getter  
methods). For example:

<h1>Your File</h1>
<?php $file->toHTML() ?>

In your File object, you would have something like the following:

class File {
    private $date = null;
    private $time = null;
    private $path = null;

    function setDate($date) {
        $this->date = $date;
    // other setters

    function toHTML() {
        return "<table border=\"0\">"

Note: I would probably add $date, $time and $path to the constructor  
since that information seems to always be required for an instance of File.

Quoted text here. Click to load it

Email me a copy and I'll take a look. (davidDOThaynes2ATsympaticoDOTca)


Re: Classes, don't follow.

Quoted text here. Click to load it

Thanks for all your help.  I am working on understanding the class.  I did  
make a little bit of a change and modeled this method on yours.  I had to  
add the str_pad, because I just can't stand the leading zeros dropping off.  
I will work with your class some more tomorrow and try and make it work with  
my form.


function printMinute() {
      echo "<select name=\"Minute\">\n";
      foreach ( range(0,55,5) as $option) {
            if ( $option == $this->minute) {
              echo "<option selected>" . str_pad($option, 2, 0,  
STR_PAD_LEFT) . "</option>\n";
            }else {
              echo "<option>" . str_pad($option, 2, 0, STR_PAD_LEFT) .  
        echo "</select>\n";

Re: Classes, don't follow.

Mark ??;-) wrote:
Quoted text here. Click to load it
You could use printf('%02d', $option) instead of str_pad if you wanted to.


Site Timeline