[pgo]

I'm going to be developing a small internal project management application for our team. I want to use OOP with PHP because I can see the benefits of an OO approach. However, I'm new at OOP, so I'm not really sure where to begin scheming out the classes I'll need for the application. This is where I'm struggling to get started.

How does one determine a strategy of classes? What should be a class and what shouldn't?

Here's a breakdown of the functionality:

• Project request submissions are written into database from the form on intranet.
  • A file up to 10MB may be attached and uploaded.
  • An email is dispatched to Managers and submitter.
• Manager logs in and accepts and assigns the project.
  • If the project is rejected...
    • An explanation text box is available and emailed along with a notification to the submitter that the project (as submitted) was rejected.
  • If the project is accepted...
    • The submitter receives an email saying the project was accepted and assigned to Production user(s) (and includes their email, so they know who to contact regarding the project).
    • An email is dispatched to the assigned user(s), who can then log in and manage the project.
• Production users log in and manage their projects (or re-assign them to an intern) and can refer to other users’ projects. Managers have full control over all projects.
  • Can update their projects’ status.
    • Not Started
    • In progress
    • Waiting on Client Content
    • Waiting on Client Review
    • Completed
  • Each project has an associated task list.
  • Each project has an associated discussion thread.

Please Note: Don't say, "Use Basecamp." (Unless my boss wants to create projects manually - in which case I'll recommend we just use Basecamp). Because we want automated project requests from clients (who are all internal corporate clients, so spam/security isn't as much of a concern).

[freelancr]

I bought 2 O'Reilly books, advertised as updated for PHP5:
Programming PHP
PHP and MySQL

They are good, but the OOP section is one page, and the information isn't enough. I was hoping to take an OOP approach to my current project, but I have had to fall back to making good use of reusable functions instead as I can't get it to work.

So if you buy a book, avoid these, and try to find a recently written one that specifically targets PHP5 OOP. Sorry I can't be of any more help. I am not too clued up on OOP, but I just see it as a way of grouping functions logically.

[pgo]

I have a copy of Object-Oriented PHP which is helpful, but I still have difficulty with project planning.

[freelancr]

Have a play around with a flow chart program if you find it helps you plan it, I usually just get stuck in though.

[bluesage]

generally, I would imagine if you have certain functionalities you will be reusing throughout your application then you should create a Class.

Typically things like, Database connection, querying, emailing.

In your case, I could see a class "Project" with methods like "set_status()", "related_tasks".

[pgo]

Projects class. Interesting.

Yeah, the other problem is I (a very amateur programmer) will probably have to tie the user authentication into a system already in place.

[erik.silkensen]

I'll describe how I try to think about things, but I should point out that I've only been programming for about a year now.

I think you're off to a good start -- the first thing you want to do is describe what your application needs to do using use cases. Use cases are step-by-step descriptions of the process your system goes through to accomplish a particular task.

For example, you've described a use case for the process of creating a new project. Once you have done this, look for nouns and verbs in your description. Nouns (Project, Manager, User, Request) become candidates for classes, and verbs (submit, accept, reject) become candidates for methods of those classes.

Not every noun has to be a class and not every verb has to be a method, but you can still start to get a basic idea using this process. Don't go overboard -- create classes where you need them. If you start coding and find out down the road you don't need a certain class or abstraction, refactor and get rid of it.

Encapsulate what varies and try to avoid duplicate code. If you start seeing a bunch of similarities this is probably an opportunity to abstract some code into an inheritance hierarchy.

Try to keep everything as simple as possible. Each class should be REALLY good at doing ONE thing. It is easy to build up huge complicated classes that are really tough to manage and a pain to use.

Hopefully I've been able to give you some ideas... anyway, good luck!

You might also want to eventually start looking at design patterns and seeing if you can naturally apply any of them to your application. Something jumping out at me a little initially might be the Observer pattern...

[pgo]

Originally Posted by erik.silkensen

Hopefully I've been able to give you some ideas... anyway, good luck!

Definitely. Thanks a lot.

[proc355]

have a look @ one of the frameworks, a lot of the grunt oop work is done for you - at least you'd get a good illustration of the structure

CodeIgniter has become pretty popular but i've not used it, theres also cakephp, symfony, etc etc

[Snowshiro]

Although its a fine design methodology OOP in PHP is of limited practical use compared to other programming environments due to the relatively stateless, atomic structure of the web. That's not to say it shouldn't be used though (indeed a single web transaction these days can involve a fairly lengthy and complex sequence of events, which is a jusitification in itself).

One tip which a lot of people hold to, is that any variables within the scope of the class, should only be accessible through the class's interface and should not be directly modified (although, for my sins, I tend to break this one from time to time). It often means writing a lot of tedious functions such as "increment_x()" but makes for more logical code and easier debugging in the long run.

[proc355]

Originally Posted by Snowshiro

Although its a fine design methodology OOP in PHP is of limited practical use compared to other programming environments due to the relatively stateless, atomic structure of the web.

I would say it's more a limitation of the general way PHP is used rather than the stateless nature of HTTP - i.e. a script is called, it runs and exits (à la CGI); compare this to a daemonized web app. where the app. remains resident in memory and objects can be reused (e.g. the models in a rails app are instantiated @ app. startup and hang around waiting for messages from the controllers); that said, you can daemonize a php script/app and run a rails app as CGI (if you're fucking bananas) so... whatever floats your bloat.