Chris W. Parker wrote: > Let's take for example a class called 'Customer' that (obviously) > manipulates customers in the database. Here is a very basic Customer > class. (Data validation and the like are left out for brevity.) [snip] > Where I get tripped up is when I realize I'll need to at some point > get more than one customer at a time and thus I want to add a method > called 'get_customers()'. > > Since an object should be a single instance of something (e.g. ONE > customer) how do I justify adding the method 'get_customers()'? Or > better yer, how do I properly add a method like that? (A method where > instead of using a SQL statement to return ONE customer's data I > instead return a record set with more than one customer.) [snip] Basically you're implementing DAO's (Data Access Objects), similar to what an ORM (Object Relational Mapper) tool would do for you. There are lots of different approaches for implementing DAO's, but personally I prefer to use a DAO class that represents one entity in my database (in your example, the Customer), and then have another separate class which is responsible for data operations on my DAO (the peer class). (This is the approach that many existing ORM tools use, both in the PHP and Java worlds.) In other words, Customer is only used to access the data that has been retrieved, but Customer itself doesn't have any methods for retrieving, updating, deleting, or saving. The CustomerPeer class handles all the data operations on Customer. If you want a particular Customer instance, you ask the peer to retrieve it for you, and it returns the appropriate object. If you want to save changes to a Customer, you retrieve the right instance, set its attributes, then give it back to the peer class which handles the database interaction. So, the Customer class is completely ignorant of the database, and is only concerned with giving you access to the data that is related to that Customer (and any other app specific methods that it makes since for the Customer class to handle). The advantage to using this approach is that you can easily have your peer class return an array of Customer objects, each one representing only one customer. Chris W. Parker wrote: > Well, yes I think it does, but what I'm missing is how this new object > interacts with the original one if it does at all. And what would I > call it? 'Multiple_Customers'? Or.. perhaps just 'Customers'! :) > > Do I extend the Customer class or is it a stand alone class? As stated, I wouldn't recommend creating a new class to hold the Customers. Just use a normal PHP array of Customer objects. In your spare time, take a look at Propel (http://propel.phpdb.org/), an ORM for PHP5. I wouldn't suggest trying to introduce something like this in the middle of an existing project, but consider toying around with it for a future project. I used this for my last application with great success. It used 20 DAO's, similar to your Customer object, and Propel saved me a lot of tedious work in implementing all of the data-related methods+getters/setters for these 20 objects. If you have any questions about it feel free to drop me a line or check out the Propel mailing list which is very helpful. HTH... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
