Efficient OOP

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

waskelton4
Forum Contributor
Posts: 132
Joined: Mon Sep 09, 2002 6:42 pm

Efficient OOP

Post by waskelton4 »

Hello group..

I'm pretty much new to OOP and now that i'm starting to get it I'm pretty excited about the time and energy it will hopefully save me..

Here is some background about my project..

It's really pretty simple. ..

My database only has two tables currently..

Individuals and Groups...

The individuals may or may not be part of a group..

Most of what i'm doing right now with the one class i have is returning information about the individual.

my class right now querys the database and creates properties for all of the fields in teh DB with the constructor.

such as...


Code: Select all

class ind() {
      function ind($id) {
             dbconnect();
              $sql = "select * from ind where id = $id";
              $set = mysql_query($sql);
               $row = mysql_fetch_array($set);

         //here i basically go and set all the object properties...
         $this->firstName = $rowї'fname'];
         $this->lastName = $rowї'lname'];
         // and so on.....

          // this happens for address1, address2, city, state, zip, phone, fax, email.. and some other group items as well..

        }




}
My question is.. what would the best way to go about using methods (methods are get and set functions right??) to get this info from the class?

or would that be the best way?

I don't want my object to take up as much memory as i feel it is..

any help is greatly appreciated..

thanks
Will
User avatar
pickle
Briney Mod
Posts: 6445
Joined: Mon Jan 19, 2004 6:11 pm
Location: 53.01N x 112.48W
Contact:

Post by pickle »

Well, the easiest way would be to have get and set functions like you said. Store the info as object variables, then have a get_address1(), etc... function to extract the information.
Real programmers don't comment their code. If it was hard to write, it should be hard to understand.
waskelton4
Forum Contributor
Posts: 132
Joined: Mon Sep 09, 2002 6:42 pm

Post by waskelton4 »

cool..
I figure i'm gonna set those up pretty soon..

i'll probably first end up drawing up a diagram for my potential objects.

I have a feeling that these objects will end up saving me lots of time..

thanks

will
User avatar
patrikG
DevNet Master
Posts: 4235
Joined: Thu Aug 15, 2002 5:53 am
Location: Sussex, UK

Post by patrikG »

Regarding OOP, have a look at things like http://www.php-mag.net/itr/online_artik ... nodeid=114

and http://phppatterns.com/ is an invaluable resource for OOP and design patterns, especially this page ( http://phppatterns.com/index.php/link/category/11/ ) have plenty of links to OOP tutorials. Zend also has a couple of nice OOP tutorials in their tutorial section, but I don't have the link handy atm.
Last edited by patrikG on Tue Nov 02, 2004 3:34 pm, edited 1 time in total.
waskelton4
Forum Contributor
Posts: 132
Joined: Mon Sep 09, 2002 6:42 pm

Post by waskelton4 »

oh.. another thought i just had.. :idea:

would it be a better idea, instead of writing a get function for every value, to write a function called getData().. ?

something like this..

Code: Select all

function getData($fieldName)  { 
  $sql = "select $fieldName from ind where id = $this->id";
              $set = mysql_query($sql);
               $row = mysql_fetch_array($set); 

return $rowї$fieldName];
}
would probably work for set function too.. what do you think?

that make any sense??
ws
User avatar
patrikG
DevNet Master
Posts: 4235
Joined: Thu Aug 15, 2002 5:53 am
Location: Sussex, UK

Post by patrikG »

It depends on the scope of your API and how concrete you want/need it. For good API design I can really recommend this: http://phppatterns.com/index.php/articl ... ew/31/1/1/
User avatar
pickle
Briney Mod
Posts: 6445
Joined: Mon Jan 19, 2004 6:11 pm
Location: 53.01N x 112.48W
Contact:

Post by pickle »

2 things:
1) It's almost "6 of 1, 1/2 dozen of the other" (if you're familiar with that phrase) with regards to having 1 or multiple retrieval functions. I have noticed that most if not all open source projects I've looked at, have had 1 retrieval function for each variable. I think the reason for this is that it's easier to go back through the code and see what it does.
Imagine coming back to this project 6 months after completion. If you make 1 retrieval function for all variables, then when you're trying to find out what you can retrieve, you'll check the code out, only to find you need to look in the database to see all possible uses of the function. On the other hand, if you make 1 retrieval function for each variable, you just have to look at the function declarations to see what's possible. Retrieval functions are usually quite small as well, which leads me to my next point...

2) I wouldn't suggest you pull the data from the database with each retrieval function. Rather, I'd suggest you retrieve and store the whole database row in the object, then use the retrieval functions to get retrieve the data from the object. This will result in only 1 database call and speed up the page load, albeit a miniscule amount.
Real programmers don't comment their code. If it was hard to write, it should be hard to understand.
User avatar
patrikG
DevNet Master
Posts: 4235
Joined: Thu Aug 15, 2002 5:53 am
Location: Sussex, UK

Post by patrikG »

pickle wrote:2 things:
1) Imagine coming back to this project 6 months after completion. If you make 1 retrieval function for all variables, then when you're trying to find out what you can retrieve, you'll check the code out, only to find you need to look in the database to see all possible uses of the function. On the other hand, if you make 1 retrieval function for each variable, you just have to look at the function declarations to see what's possible. Retrieval functions are usually quite small as well, which leads me to my next point...
That is entirely the opposite of why would use OOP. The strength of OOP lies in its re-usability, i.e. you abstract logic. Most Open Source projects in PHP (including phpBB) and every OS shopping cart etc. I've looked at are horrendously coded from an OOP point of view. Classes are, unfortunately, used in those projects like big function includes with no inherent class-logic.
Despite the benefit that the authors are offering it for free and its working more or less, its nigh unmaintainable. Classes with over a 1000 lines of code are simply silly. Minimize!

Keep your code simple, create the API first before you even start coding one line of PHP (which requires you to think what you will need, then digest it, then think about it again, then digest it again... etc.) until you've come up with the minimal amount of functions which are as flexible as possible and have as little code as possible.
Why a function for each variable? That's totally unnecessary bloat, imho.
pickle wrote: 2) I wouldn't recommend you pull the data from the database with each retrieval function. Rather, I'd suggest you retrieve and store the whole database row in the object, then use the retrieval functions to get retrieve the data from the object. This will result in only 1 database call and speed up the page load, albeit a miniscule amount.
NEVER(!!!) do that. Only retrieve what you have to from the database - you save yourself a lot of coding if you start optimising your SQL statements. SQL is a powerful tool, learn how to use it.

Also if you'd be working with larger tables, you'll have tons of data to process which has go from the database to PHP which then processes 100,000 fields. Databases are much faster at that by their very nature.

Optimise your SQL first, then optimised the logic of PHP, then let it work together.
User avatar
Weirdan
Moderator
Posts: 5978
Joined: Mon Nov 03, 2003 6:13 pm
Location: Odessa, Ukraine

Post by Weirdan »

patrikG wrote:
pickle wrote: 2) I wouldn't recommend you pull the data from the database with each retrieval function. Rather, I'd suggest you retrieve and store the whole database row in the object, then use the retrieval functions to get retrieve the data from the object. This will result in only 1 database call and speed up the page load, albeit a miniscule amount.
NEVER(!!!) do that. Only retrieve what you have to from the database - you save yourself a lot of coding if you start optimising your SQL statements.
Sometimes direct mapping between db rows and class objects is really useful. Sometimes.
Also if you'd be working with larger tables, you'll have tons of data to process which has go from the database to PHP which then processes 100,000 fields.
Is there any particular reason to have the db that much denormilized? 8O
User avatar
patrikG
DevNet Master
Posts: 4235
Joined: Thu Aug 15, 2002 5:53 am
Location: Sussex, UK

Post by patrikG »

Weirdan wrote:
patrikG wrote:
pickle wrote: 2) I wouldn't recommend you pull the data from the database with each retrieval function. Rather, I'd suggest you retrieve and store the whole database row in the object, then use the retrieval functions to get retrieve the data from the object. This will result in only 1 database call and speed up the page load, albeit a miniscule amount.
NEVER(!!!) do that. Only retrieve what you have to from the database - you save yourself a lot of coding if you start optimising your SQL statements.
Sometimes direct mapping between db rows and class objects is really useful. Sometimes.
That is much more the exception than the rule, Weirdan.
Weirdan wrote:
Also if you'd be working with larger tables, you'll have tons of data to process which has go from the database to PHP which then processes 100,000 fields.
Is there any particular reason to have the db that much denormilized? 8O
I was obviously exaggerating. The point is: if you fetch entire rows, to simply retrieve the value of one cell, its pointless and a waste of processing time - simply unoptimised. Example: I've just looked at a plugin for php-shop and wondered why it was slowing down page loading times so much. Turns out the guy did a "SELECT * FROM products WHERE..." while he only needed the id of the row which he passed to a function. That's plain silly and wasteful.

Yes, there are occassions where fetching entire rows and keeping them in the memory make sense, but as a rule of thumb it simply encourages bloat.
waskelton4
Forum Contributor
Posts: 132
Joined: Mon Sep 09, 2002 6:42 pm

Post by waskelton4 »

Thanks for all the replys..

it's good to hear everyones opinions..
patrikG wrote:Regarding OOP, have a look at things like http://www.php-mag.net/itr/online_artik ... nodeid=114
fantastic article.. have it bookmarked and will likely refer to it often.


It appears that my next step needs to be to get my program to a fairly stable stopping point and then start the re-write OOP style.

It seems to me that my getData function idea(wait.. accessor.. right? :)) might be really nice.. but i'll just have to make sure to comment it well so 6 months later i'll know what i'm dealing with.

anyway.. off to diagram..

thanks for everyone's help.. i'd love to keep the conversation going..

ws
timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post by timvw »

for my Database Table class I ended up with following methods:
- create // accepts array with key=value pairs
- read // accepts sql where clause, offset and limit
- update // accepts array with key=value pairs (need the primary key)
- delete // accepts array with key=value pairs (need the primary key)

then i also have:
- getDataDictionary // returns a hash with the fields in the db table
- getValidator // returns an instance of a class that does validation
- getFormatter // returns an instance of a class that does formatting


validator has methods:
- validate_create
- validate_read
- validate_update
- validate_delete

formatter has methods:
- pre_create
- post_create
- pre_read
- post_read
- pre_update
- post_update
- pre_delete
- post_delete
Last edited by timvw on Tue Nov 02, 2004 4:58 pm, edited 1 time in total.
User avatar
pickle
Briney Mod
Posts: 6445
Joined: Mon Jan 19, 2004 6:11 pm
Location: 53.01N x 112.48W
Contact:

Post by pickle »

patrikG wrote:That is entirely the opposite of why would use OOP. The strength of OOP lies in its re-usability, i.e. you abstract logic.
True, but OOP is also useful for extending functionality and human understanding of code (at least that's how I use it). I've come into many completed projects and found it much easier to extend/debug programs that have individual retrieval functions, than ones that have a blanket function - it just means I've got to dig through fewer files and db's. Ease of returning to code was my motivation for suggesting that. I guess it's like you said, it depends on the situation.
patrikG wrote:Why a function for each variable? That's totally unnecessary bloat, imho.
I agree it's bloat, but it MAY not be unnecessary if you've only got a few variables to return.
patrikG wrote:NEVER(!!!) do that. Only retrieve what you have to from the database - you save yourself a lot of coding if you start optimising your SQL statements. SQL is a powerful tool, learn how to use it.

Also if you'd be working with larger tables, you'll have tons of data to process which has go from the database to PHP which then processes 100,000 fields. Databases are much faster at that by their very nature.

Optimise your SQL first, then optimised the logic of PHP, then let it work together.
I think perhaps we come from different coding backgrounds. Most of the programming I do is intra-departmental webapps for a medium sized university. My mindset wasn't one that included tables with dozens of fields. I was thinking that if you've got a table with 5 fields (for example) and you need all 5 fields to generate the page, then it would be easier to just retrieve them all at once. Of course, as you said, with many more fields, the advantage of this would disappear.
Real programmers don't comment their code. If it was hard to write, it should be hard to understand.
User avatar
patrikG
DevNet Master
Posts: 4235
Joined: Thu Aug 15, 2002 5:53 am
Location: Sussex, UK

Post by patrikG »

pickle wrote: I think perhaps we come from different coding backgrounds. Most of the programming I do is intra-departmental webapps for a medium sized university. My mindset wasn't one that included tables with dozens of fields. I was thinking that if you've got a table with 5 fields (for example) and you need all 5 fields to generate the page, then it would be easier to just retrieve them all at once. Of course, as you said, with many more fields, the advantage of this would disappear.
I agree - I've started off with coding a couple of projects from scratch which, unbeknown to me at the time, was a big bonus. At a recent job (some years later) I've was asked to take over a project on which three developers had tried their skills - none of them went about it in a methodological way (which I try, at least). It was probably every developer's nightmare and my frustration was enormous. The projects after that I could develop to my hearts content and started from scratch (mostly). The database behind them was quite big and, alas, most tables were not normalized. Only two tables with about 40 columns each with highly cryptic, and partly redundant values containing roughly 400.000 rows. Working for that company taught me a lot about how not to do things and hence my sharp reaction to your initial suggestion.
User avatar
pickle
Briney Mod
Posts: 6445
Joined: Mon Jan 19, 2004 6:11 pm
Location: 53.01N x 112.48W
Contact:

Post by pickle »

patrikG wrote:It was probably every developer's nightmare and my frustration was enormous.
PREACH IT BROTHER!!!!
Real programmers don't comment their code. If it was hard to write, it should be hard to understand.
Post Reply