smsiebe

The theory of OOP is not to just make it easier for code reuse. This is one of the benefits, certainly not the sole purpose behind it. OOP methodology came to be as an evolution in complex software design. Yes, one of the things they were try to manage was the massive amount of code going into these complex systems, but just as much so to manage the complexity through encapsulation. There were many other reasons and gains from OOP. Anyway, to the question: You're correct in thinking that your approach in wrapping procedural code doesn't really give you much, however, it is a good start. I see you mixing some parts of code that should typically be separated out when using an OOP approach. Try separating out all your DB calls to a DB class, each basic request being a method. Than, in your page_information class, initialize the DB object in your __constructor() method and call your requests from there. So your request for category information may look like: $category_information = $this->db->findCategoryInfo($pageId); Right now, focus on abstracting out these main parts and using it from your other objects. Get comfortable with the structure and the syntax, than you can tackle more OOP concepts. As the previous poster stated, code reuse is one of the benefits you'll get out of OOP - focus on this when initially refactoring your code when learning OOP. I would suggest getting a book or two on object oriented design, there are good ones out there that are specifically about OOP in PHP5. They can go into better detail about the advantages and methods to implement OOP than I can in a forum post =). Keep at it! Learn to code clean OOP code is a present to yourself and your fellow programmers having to come behind you! I assure you that the investment in learning the new methodology with the language you are already comfortable with will pay off in very little time. Regards, Steve

Hello Matthew, I know this is the default answer - but it depends on the program you are writing. To answer the question, though, I'll assume you're writing an application that requires user authentication and authorization - with role-based access security just for fun. This application warrants the overhead of maintaining user authorization and state information in session, as it is required on every request. If you are going to build the user object on each page request, it doesn't make sense storing the user data in raw format and manually building the user object on each page request. Store the object directly in the session...but that requires a little planning: When objects are serialized in session you must tell PHP which object parameters you wish to preserve. Upon serialization, the __sleep() magic method is called on the object in question. This method is expected to return an array of scaler parameter names that exists in the object that will be restored on unserialization. These parameters will "magically" be restored when the session is started on the next page request. Object parameters that hold special references to things like resources will not be preserved, however. To restore these resources (db links, for example), you can restore them in the __wake() magic method, which is called when the object initialized from session. To things to note: First - If your class aggregates other objects (an object is set as a parameter within the first), that class must also have a __sleep() method specified if you wish to restore the parameters. You must manually serialize this object within the __sleep() method, and unserialize in the __wake() method, in order to handle this situation. Second - In order to restore the object(s) you are serializing, the class must be defined prior to the session start. This makes sense, of course, because if PHP doesn't know how to build the object, how can it restore it? So, you need to include/require the class file prior to session start. An example of what I mean: The user object, that you will directly store in the session. <?php /** * @see Role */ require_once "Role.php"; class user { /** * username * @var string */ protected $_username; /** * userid * @var int */ protected $_userId; /** * collection of user roles * @var Roles */ protected $_roles; //getter, setter, and logic methods excluded /** * prepare for serialization * * this is the magic method we define which object parameters we want to preserve * * note the aggregate object Roles * * @return array */ public function __sleep () { //we have to serialize the object $this->_roles = serialize($this->_roles); $save = array ( '_username', '_userId', '_roles' ); return $save; } /** * restore from serialization * * @return void */ public function __wake () { //restore the roles object //the roles class is included at the top of the User class $this->_roles = unserialize($this->_roles); } } ?> The roles class that will be aggregated within the user object: <?php class Roles { /** * role names - lets keep it simple * @var array of role names */ protected $_roles = array(); //getter, setter, and logic methods not included /** * prepare for serialization * * no need for a wake() method * * @return array */ public function __sleep() { return array ('_roles'); } } ?> Finally, the simple storage of the user object: <?php //be sure to require the user class BEFORE session start require_once "User.php"; session_start(); if (!isset($_SESSION['auth_user'])) { //redirect to login, do logic, etc } if (!$_SESSION['auth_user']->hasRole('administrator')) { //fake method on the User object demonstrates the operation on the object //after session start } ?> Add some business logic to your User and/or role classes and your in business for a quick and dirty user object. As a rule of thumb, keep your 'model' operations separate from your business logic. In other words, keep persistent storage mechanics out of the domain model objects - pass the object to the object mapper for operations on the database, or to a session handler to handle thing like managing namespace of the session superglobal (again, if the situation dictates). Hope this helps, Steve