Moving forward: patterns to applications (a.k.a. what I don't get about design)

[KevinM1]

The title of this post basically sums it up -- I'm in the process of understanding the common patterns (I'm up to Front Controller, yay!), but I still don't see how they combine to form a true web application.

 

I think my main problem is envisioning how these patterns work within an environment that necessarily serves different pages to the user.  Most of the PHP applications I've seen use a host of files that deal with their own little slice of the project -- a file named login.php to handle user logins, a file named upload.php to handle file uploads, etc.  Admittedly, these have all been procedural designs, but I fail to see how an OOP design would be very different.  Is there a difference?

 

In my mind, I keep going over how I would construct a simple CMS.  While I would use objects to represent the vital parts of the system (a login class here, a getnews class there), I can't see how that would combine to become a unified whole that would be any different than a procedural design under the surface.  I keep thinking that I would have to fall back into the file-itis mentioned above, with classes taking the place of library functions.  A lateral move.

 

Forms are another issue that I'm having trouble including into an OOP mindset.  In my 'Case study' thread in the OOP section of the forum, I'm trying to transform two messy procedural scripts into OOP scripts.  The first, which retrieves a list of event registrations based on a user's id and access level and generates a form from that list, giving the user the ability to choose which event(s) they want to edit, works great.  I'm having trouble, however, using the info from those objects in another form which actually handles event editing and deletion.  I just can't see how to do it in any other way but procedural code, which defeats the purpose of that project.  In particular, I want to keep the second form's action as $_SERVER['PHP_SELF'], and I can't see a way to do that in an object.

 

So what am I not getting?  Is there something fundamental I'm missing?  Is it just a matter of me not getting through the enterprise patterns yet, which tie together all of my 'big picture' concerns?

[Buyocat]

Well the first thing you may be "missing" is that there are a number of patterns available for many common problems.  The one I'm hearing you keep mentioning is related to serving pages, so it might roughly fall under the problem of controllers, and how to map user input (the get and post) to some application action.  You've named one pattern, the front controller, but in addition to that there exists the page and application controller patterns.  I bring these up because I think that the page controller is something that most people implement already.  Following the page controller pattern means having a controller class for each individual page (i.e. login, index, news).  Now setting aside the issue of OO I believe that you'd probably say that you're already implementing something along those lines.

 

The real question then isn't what pattern should I use, but what code am I repeating, and how can I consolidate it?  Consolidating repeated code can be acheived by making procedural libraries or through inheritance and delegation; what's important isn't that your code base is purely OO, but that you can easily swap parts of your code base for new parts.  For instance, how difficult would it be to change from a session based system to a database based system for user state?

 

You can use OO techniques, and established patterns, to acheive loose coupling between components.  For instance, let's imagine your form based web application.  The first thing many people would do is create a distinction between model, view, and controller.  I personally would go with a page controller, which might have common functionality in a base class.  The view would be php templates with a utility class to load and compile them.  The controllers would delegate responsibility for managing views to the utility.  Finally the model would most likely consist of two layers.  First there would be a database abstraction layer.  It might even have a data mapping layer thrown in to move between "plain old objects" and relational databases.  On top of that I would build my domain models (i.e. user, news, etc).  These classes would do things like hash passwords, verify that usernames are unique, and other higher level operations.

 

That would be the application at a high level.  I've left out some potential pitfalls such as input validation, output validation, state, etc.

 

I hope that was helpful, feel free to ask some questions and we can continue the discussion.