Rewriting a medium sized application in OO

What are some apraoches I can take to rewrite a fairly large procedural php with about 2000 lines of application to code as an oo application. And should I even try to do this, or do I need to build on top of an existing application? I wrote this when I was learning programming and now I want to expand on it.

+1


a source to share


4 answers


No silver bullet. However, you could do much worse than putting together this book: http://www.amazon.co.uk/Working-Effectively-Legacy-Robert-Martin/dp/0131177052



+2


a source


I would probably do the following while converting my application to MVC:

  • Determine the purpose of each function (processes query parameters, outputs data, queries the database?)
  • Try refactoring the functions that do all of the above, breaking them down into functions that do nothing more than one of these things.
  • For each function, try to find a suitable top object / class that can contain that function as a method

    function addUserRecord($dbHandle, $userData) {[...]} 
    // Becomes
    class User {
        private $db;
        public function addUser($data) {
            [...]
        }
    }
    
          

  • For every single * .php file accessible from the outside, turn it into an action of the corresponding controller:

    http://foo.bar.com/user/addUser.php // becomes
    http://foo.bar.com/user/add-user

    Relevant controller using Zend_Framework

    class UserController extends Zend_Controller_Action {
        public function addUserAction () {
           [...]
        }
    }
    
          

  • Move all output, such as echo, into views.



The hardest part will probably be creating the right models, but this is very important and will become the foundation of your application.

+2


a source


If you want to add new features or expand your application significantly, then enhance your existing codebase as you go. Always test your code better than you test it. But it would be nice to use the time for a big rewrite.

Written tests that prove important business requirements are met by your existing codebase will also help you. You can then change the legacy code knowing that you are not breaking the application. If you break something, you will know what it is and can quickly fix it.

+1


a source


The advantages of well thought out OOP are that your components are easy to recycle and that it just helps the team. Ant, it is again easier to maintain code where you know where what is, and in OO you can simply find it by classes. So you decide if you need it. Sometimes more is less ...

0


a source







All Articles