Should I remove static function from my code?

Question

My code is located here: https://github.com/maniator/SmallFry

Should I make it so that that the App class does not have to use static functions but at the same time be able to set and set variables for the app from anywhere?

Or should I keep it how it is now with App::get and App::set methods?

What are the advantages and disadvantages of both?
How would I accomplish that 1st task if I was to undertake it?

Related Question

Sample code:

//DEFAULT TEMPLATE
App::set('APP_NAME', 'SmallVC');
//END DEFAULT TEMPLAT
//
//DEFAULT TEMPLATE
App::set('DEFAULT_TEMPLATE', 'default');
//END DEFAULT TEMPLATE

//DEFAULT TITLE
App::set('DEFAULT_TITLE', 'Small-VC');
//END DEFAULT TITLE

//LOGIN SEED
App::set('LOGIN_SEED', "lijfg98u5;jfd7hyf");
//END LOGIN SEED

App::set('DEFAULT_CONTROLLER', 'AppController');

---

       if(App::get('view')){
            $template_file = $cwd.'/../view/'.App::get('view').'/'.App::get('method').'.stp';
            if(is_file($template_file)){
                include $template_file;
            }
            else {
                include $cwd.'/../view/missingview.stp'; //no such view error
            }
        }
        else {
            App::set('template', 'blank');
            include $cwd.'/../view/missingfunction.stp'; //no such function error
        }

Answer 1

I think you have a feeling that static is bad. What I am posting may seem fairly crazy as it is a massive change. At the very least hopefully it presents a different idea of the world.

Miško Hevery wrote static methods are a death to testability.

I like testing, so for that reason I don't use them. So, how else can we solve the problem? I like to solve it using what I think is a type of dependency injection. Martin Fowler has a good but complicated article on it here.

For each object at construction I pass the objects that are required for them to operate. From your code I would make AppController become:

class AppController
{
  protected $setup;

  public function __construct(array $setup = array())
  {
     $setup += array('App' => NULL, 'Database' => NULL);

     if (!$setup['App'] instanceof App)
     {
         if (NULL !== $setup['App'])
         {
             throw new InvalidArgumentException('Not an App.');
         }
         $setup['App'] = new App();
     }

     // Same for Database.

     // Avoid doing any more in the constructor if possible.

     $this->setup = $setup;
  }

   public function otherFunction()
   {
      echo $this->setup['App']->get('view');
   }
}

The dependancies default to values that are most likely (your default constructions in the if statements). So, normally you don't need to pass a setup. However, when you are testing or want different functionality you can pass in mocks or different classes (that derive from the right base class). You can use interfaces as an option too.

Edit The more pure form of dependency injection involves further change. It requires that you pass always pass required objects rather than letting the class default one when the object isn't passed. I have been through a similar change in my codebase of +20K LOC. Having implemented it, I see many benefits to going the whole way. Objects encapsulation is greatly improved. It makes you feel like you have real objects rather than every bit of code relying on something else.

Throwing exceptions when you don't inject all of the dependencies causes you to fix things quickly. With a good system wide exception handler set with set_exception_handler in some bootstrap code you will easily see your exceptions and can fix each one quickly. The code then becomes simpler in the AppController with the check in the constructor becoming:

     if (!$setup['App'] instanceof App)
     {
        throw new InvalidArgumentException('Not an App.');
     }

With every class you then write all objects would be constructed upon initialisation. Also, with each construction of an object you would pass down the dependencies that are required (or let the default ones you provide) be instantiated. (You will notice when you forget to do this because you will have to rewrite your code to take out dependencies before you can test it.)

It seems like a lot of work, but the classes reflect the real world closer and testing becomes a breeze. You can also see the dependencies you have in your code easily in the constructor.