Instance Configuration in Object Oriented PHP

Question

I am looking for the most efficient way to apply a set of properties (configuration) to a newly created instance. My first goal is to support the object orientation of the application, the second is the ability to work with the DI container. This is the sample that I have come up with so far:

class ViewLogin { public $msgLoginGranted; public $msgLoginFailed; public function __construct(){ } protected function onSuccess() { return $this->msgLoginGranted; } protected function onFailure() { return $this->msgLoginFailed; } } class ControllerLogin { public function __construct(ModelLogin $model, ViewLogin $view) { } } 

To keep ViewLogin clean and separate configuration data from the code, what is best to do:

Create a new ViewLogin1 class

 class ViewLogin1 extends ViewLogin { public function __construct() { $this->msgLoginGranted = 'Welcome!'; $this->msgLoginFailed = 'Login Failed!'; } } 

CONS: static class content, no new features, polluting class space

Pass the configuration object to ViewLogin

 class ViewLogin { public function __construct(Config1 $config) { $this->msgLoginGranted = $config->msgLoginGranted; $this->msgLoginFailed = $config->msgLoginFailed; } } 

Create a decorator for ViewLogin?

Move configuration to XML / JSON / YAML ...

Answer 1

I do not understand why you need ViewLogin1 . If you want to prepare it in your structure and immediately use it in the application, I would include ViewLoginAbstract in the framework and ViewLogin in the application, even if new functions are not introduced (remember that you will want to replace the redirect with die('What the hack are you trying to do?') or something like that).

On the other hand, when you have several forms of entering the application, I would go in a way like the Zend Framework .

When you look at how they use the *Controller class , they use one class for each controller and one common ViewModel class for views.

More details on the default indexAction :

 public function indexAction() { return new ViewModel(array( 'content' => 'Placeholder page' )); } 

So, I would reuse ViewLogin and just go through the setup, as new functionality is not introduced (just make sure in the future you don’t want to add a record or other function to the log).

Hover in my opinion, page redirection after logging in should be responsible for the uncontrolled controller (the view should only be responsible for displaying html + other front-end material), so I'm not sure why you put redirect in the view.