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.
I'm trying to design an object oriented member system for my site. I'm hoping if I tell you guys what i've done so far you can critique my process and maybe give me some ideas as to ways I can improve things.
First thing I did was come up with a list of what this system should let me do in the end. These things are:
Find out if a member exists - used when logging members in
Update a members settings (i.e. password, email, etc)
Add/Drop members
All member data will be stored in a MySQL database so I know that in the end each one of these operations is going to result in a query to the database. Because of this I know that i'll need at least one object that the other objects can use for interacting with the database. Furthermore, I don't want each object to worry about the specific syntax for querying a database. The reason for this is if later on I decide to store all my member data in an xml file I don't want to have to go through and update a ton of code.
Basically this is where i'm stuck. So far I think I need at least one object for use when interacting directly with the member settings, which in this case is the equivilant of performing mysql queries. But then I think I might need another object that will hold methods for taking a syntax-independent request (i.e. Get user 231s name) and turning it into a syntax-dependent call for use by the mysql object (i.e. select name from members where id='231').
Any ideas on where I could improve my thought process?
Database Abstraction Layer for interacting with a specific database.
"Generic" Storage Layer for making calls to the database abstraction layer.
Member Class for modeling an actual member.
But i'm a little confused as to why you would use a factory for the storage systme?
Sorry Nigma I meant to post something but I haven't been very busy at work. You're question cuts across several application layers: there's a lot to consider.
The starting point for me in application design is always the standard presentation / domain / data source layering. Fowler's PoEEA is an essential text on this and various enterprise patterns which you commonly come across in OOP applications. The pattern catalogue can be found here (the book goes into more detail). It sounds like an ActiveRecord could be useful for a Member object. That takes care of all access to a member table (or xml file etc) and some simple domain logic.
Deciding what response to make to a request out of a range of possible responses would be the job of an ApplicationController. There's some discussion about that here. On page two Selkirk explains a bit about the WACT controller system. WACT is worth a look as one of the very few fully unit-tested php apps around.
Yea, I figured I could count on some advice from you on the subject. I'll have to look over the book and read the links and possibly do more to completely understand what you were suggesting. I'm not well versed with object-oriented programming in general. I figured if I knew what the goal of oop was and asked the right questions class design would be somewhat intuitive from there.
It takes a while to learn all this stuff - a year or two. Be prepared to regularly tear up your work and start again en route. It's a bit like climbing a hill with lots of false summits: you keep thinking you're almost there and then another one rears up ahead. Also, don't be put off if something doesn't make sense at the first read. I don't think I ever got my head around anything OOP-ish on the first attempt.
The good thing about it is that you swap lots of niggling detail for interesting design problems. It's fun. If you plan to make a career out of programming you've got to do it. OOP skills will translate to other languages.
I'd strongly recommend learning how to unit test as soon as possible. It's got almost too many benefits to mention including use as a design tool. If you're building (and later maintaining) a complex OOP application life is a thousand times easier with tests to back you up. I made the mistake of putting it off for a while because there was so much else to learn about but testing will be the corner stone of all your work.