Hey all, I just got my hands on the excellent books PHP Anthology 1 & 2 and am wanting to start playing around with classes. My question to the list is, what, in your opinion, constitutes good class/api design? Is it better to design several smaller classes that each focus on one task and do that task well, or to build more general classes that handle a number of related tasks?
Also, when you are beginning a new project, what methods do you find helpful to follow in taking your project from concept to finished?
Do as much of the design away from the keyboard as you can. Use prose, questions like "what do the users of this program need?" are a good starting point, or "what is the problem that needs solving?" Draw pictures and flowcharts for complex things you want to do (you don't have to use UML, but its methodology is helpful). There are several excellent and free UML modelling programs out there.
The books also mention ways to use phpDocumentor to document your code and SimpleTest to test your code as it is written. These along with some XP techniques I read about seem like good practices to follow. Does anyone have any other ideas/practices that it would be good for a new oop developer like myself to make a habit it of?
The main advice I can offer as one of the primary authors of phpDocumentor, the next incarnation of the PEAR installer (not out yet), and a few other small packages is to start small, and use code that others have written wherever possible.
When code I've written gets old, the first thing I notice is that the best code has been split up so that methods are no longer than a page, and classes don't try to group more than one thing. A great rule of thumb for all functions is to ask yourself
"What is the one thing I want this to do?"
If your function starts doing more than one thing, split it up. It will also get to be much longer than a page, so that's a good warning sign.
I've also gone the other route, which is to say I tried to over-OO things with my defunct first attempt at the PEAR package Games_Chess. Initially, each piece was an object, and so was each square on the chessboard.
Calculation is virtually impossible in this situation. Then, I realized that pieces don't need to do any actions, and only possess two properties, their color and their name. Changing the design to use properties of a chess object to represent the board as an array and each piece as an index in this array suddenly made it possible to do very fast calculations using the array functions built into PHP, and suddenly it took only a week to come up with a working first draft.
The other thing I've learned the hard way is for God's sake, don't write code like this:
class Common
{
function utilitythingo()
{
}
}and extend every other class from Common. This instantly cuts down on future expandability options. It means when you realize that you've designed the application to solve the X problem, and the more important problem was Y, modifications will take you forever. Or, when you find code that someone else has written, you won't be able to easily integrate it into your own code.
The single most important design decision is not just how you split up the tasks, but how you design the communication between them. You can have methods instantiate objects directly, pass in objects, use a proxy/router object to communicate between classes using messages or simply call methods directly - the choices are endless.
For instance, logging is a common idea for most web applications. If you design all classes that do logging so that they simply accept an instantiated logging object, this will allow you to plug and play ANY object that has the same API as your preferred logging object. The same is true of database access, or other critical design choices. Patterns can often be useful in deciding how to do things, such as the faddish MVC (model-view-controller) or singleton, factory, observer patterns. Go to http://www.phppatterns.com to see Harry Fuecks's excellent site devoted to these subjects.
However, most important is to simply try it out, make mistakes and have fun trying to fix them (or get an ulcer, but that's how we look at things, isn't it :)
Greg
-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
