10 replies to this topic

[zeroradius]

Hey guys. I was wondering is function lists still an acceptable practice even if you are using OOP? I ask because as I have been working in OOP I have found in many places were I may need a custom function but it is used in so many places it would seem more benificial just to include a list of custom functions. But I am trying to stick to todays standards so i don't want to do necisarily what is conveniant but what is accepted in the work place.

[Rutek]

Maybe will you just use classes with static methods? This type of classes is often called 'Helper'.

[zeroradius]

I could but i was hopeing to not have to make an instance to use it. I want to use my functions much like the built in functions in php. so i want using these custome functions to be as simple as using is_set() in php now. But if it is not common practice to do it that way now days than i will turn it into a class

[John]

If you use static methods, you don't instantiate an object - you simply access the classes member functions using the scope resolution operator.
See PHP: Static Keyword - Manual

You might be able to use namespaces to resolve the scope to a class and use functions in the manner you wish. But they are new as of PHP 5.3 and I haven't had the time to play with them.
See PHP: Namespaces - Manual

However, generally speaking, if you are creating a class to act as a library, you are using OOP incorrectly.

Edited by John, 22 March 2010 - 09:51 PM.

[zeroradius]

I don't want to use a class but when i went to just make a list of functions i was told not to do that, and no matter how i go to use classes either a book or a person tells me its the wrong way and gives me contradictory views on the subject to the previous refrence i used! Is there anyone at all that agrees on how to use OO? I'm so lost, there should be a list of standards for this stuff :crying:. I'm going to go check out those two links now....

Edit: Static will work.

[John]

It is because most people fail to understand what an object actually is (despite its name). An object in code should be built and used just as any tangible object. An object in code models something (and saying an object models a code library is cheating) that has attributes and functions. If you have a class with just random functions/methods, what are you actually modeling?

[zeroradius]

thats what i thought in the begining. If I am understanding what you are saying I think i was doing it right at first. I originally built classes that were things i could use repeatedly . such as a guest book (i use a LOT of guestbooks on my sites) which in turn i planned to make a sub class (correct word?) that extended the diaplay() method and the user() method to include a sig and turn into a forum (with a little help from another class). I also did a login class and things of that nature. I had the display method except paramaters that kept the designer from going in to my code and figured if the display was completly wrong i could always redo display() via a subclass(?) I was told that this was incorect that you never put any display code in the class. This left me with things such as making classes that did nothing more than read a directory and output a list of files. I thought the point of a class was i could just create an instance pass in the values for the constructor and it would do ALL the logic. The way people have me doing it now i have so much code that has to be done outside the object that it dosent seem anybetter than doing it all out on one page. Could you explain to me your views on creating object/classes? or if not that point me to a good article. I have to many people views in my head and i need to purge them and start new.

[John]

Once you understand the idea that an object represents a functional entity, then you need to learn design patterns. So instead of Googling on "how to program using OOP" search for design patterns in PHP instead. The most common "design pattern" (its actually an architectural pattern) in PHP is the Model-View-Controller. You probably already partially implement (a front controller functionally) it if you do something like:

switch($_GET["page"]); {
    case "bar":
        require_once("bar.php")
    ...
}

A guest book is actually a collection of objects (this is where design patterns come in). Try creating a MySQL. First just encapsulate the basic mysql functions, but then try adding some methods of your own. For example you might have:

class MySQL {

    public function connect($server, $user, $pass) {
        return mysql_connect($server, $user, $pass);
    }

    public function query($query) {
        return mysql_query($query);
    }

}

Now, perhaps you might have the MySQL object keep track of all its queries, or write all bad queries to a log, or add a function called insert($table, array(col1, col2, col3), array(val1, val2, val3)) and insert(...) would do a mysql_real_escape_string on val1, val2, val3 and then insert those values into the proper columns so you don't have to manually write all the queries and escape all your values manually.

Then if you were to make a SQLite class that has the _same_exact_ functions you are on your way to the factory pattern. All you would have to do is make a DataBase object that creates either SQLite objects or MySQL objects. This is how PDO works.

Now I would use the MVC pattern to create the GuestBook, and the GuestBook object would use a DataBase object and perhaps some other objects. Then you might consider the GuestBook object a "module" which is part of a larger system. A Login might also be a module that has a DataBase object. And the larger system has a GuestBook object and a Login object.

When I was learning OOP, I just read all about design patterns in PHP. Once I had a solid grasp of the most popular design patterns, I implemented a completely object oriented CMS. Getting a decent architecture and design was the fun part, and that is where I learned all about OOP.

I probably confused you. :)

[zeroradius]

Yes confused me a bit but it at least put me on the path I need to be on. I think this is simular to what Orjan showed me. He showed me a class that handeled DB queries. Later on I tried to imulate it and it works but it seems a bit draged out. I have tried creating a function for each type of query i might want to use but I seem to have a LOT of select queries that are not suited for many tasks. I have been looking at MVC sence you mentioned it and I understand in theory what it does but do nto understand how to implement it programicly. The Model just handels the logic right? That would be the classes themselves? the View is simple enouph that is were my xhtml goes along with were i create instances of my object? is that right? I don't understand the controller, what i read says it is how users interact with the program, but in web Dev it dosent seem like somthing you need, if i am understanding it right wouldn't that be like onClick(runBlah) but that is inside the view in the program?

[John]

Most explanations of MVC are oriented toward programming languages such as Java where you have a real user interface. You need to find a PHP specific explanation to get a good understanding. But essentially, the controller controls the flow of the program. It is what responds to $_GET requests and then performs the needed actions. The model is what actually does
those actions, and the view is your basic html interface. So for example, using a little OOP you might have something like:

controller.php

<?php

//I'm too lazy to implement this using objects

switch($_GET['page']) {

    case "guestbook":

        $model = new GuestbookModel();

        $comments = $model->getComments();

        require_once("GuestbookView.php");

        break;

    ....

}

GuestbookModel

class GuestBookModel {


        public function getComments() {

            $comments = $db->query("SELECT * FROM comments");

            $commentsArray = $this->toArray($comments); //converts your resource into an actual array

            return $commentsArray;

       }


       private function toArray(array $arr) {

                 //bleh

        }

}

GuestbookView.php

<p>Hello, Here is my guest book</p>

<?php

foreach($comments as $comment) {

    echo $comment . "<br />";

}

Try playing with CodeIgniter or some other framework (CI is pretty simple). This is where I finally realized how the MVC work together.

[zeroradius]

ok so in php for most things the controller is already done for us, gotcha. I will play with a framework as you sugested. Thanks for the help ^_^

Edit: I just watched the code igniter vid tutorials it had some stuff about MVC i think i understand a bit better, Im going to see if i can find some more

Edit2: Ok I think i got it. Tell me if this is right:

Model - Contains the logic, this would be were the classes/objects are stored.

View - Represents the presentation layer, it contains css , XHTML, and so on.

Controller - is the browser

is that right? and where would XML, Javascript, and Database (asuming you have to have it in the sites directory) go?

Edited by zeroradius, 25 March 2010 - 02:25 PM.