StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
16700833
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
7
CommunityOwnedDate
CreationDate
2013-05-22T20:16:20.347
FavoriteCount
0
LastActivityDate
2016-07-13T09:42:02.747
LastEditDate
2016-07-13T09:42:02.747
LastEditorUserId
240812
OwnerUserId
1230836
ParentId
16700375
PostTypeId
2
Score
4
ViewCount
0
LastEditorDisplayName
text
Body
In response to Sébastien Renauld's comments: <a href="http://phpmaster.com/inversion-of-control-the-hollywood-principle/" rel="nofollow">here's an article on Dependency Injection (DI) and Inversion of Control (IoC)</a> with some examples, and a few extra words on the Hollywood principle (quite important when working on a framework). Saying your classes won't ever need more than a single instance doesn't mean that statics are a must. Far from it, actually. If you browse this site, and read through PHP questions that deal with the singleton "pattern", you'll soon find out why singletons are a bit of a no-no. I won't go into the details, but testing and singletons don't mix. Dependency injection is definitely worth a closer look. I'll leave it at that for now. To answer your question: Your exaple (<code>Config::get('test')</code>) implies you have a static property in the <code>Config</code> class somewhere. Now if you've done this, as you say, to facilitate access to given data, imagine what a nightmare it would be to debug your code, if that value were to change somewhere... It's a static, so change it once, and it's changed everywhere. Finding out where it was changed might be harder than you anticipated. Even so, that's nothing compared to the issues someone who uses your code will have in the same situation. And yet, the real problems will only start when that person using your code wants to test whatever it is he/she made: If you want to have access to an instance in a given object, that has been instantiated in some class, there are plenty of ways to do so (especially in a framework): <pre><code>class Application {//base class of your framework private $defaulDB = null; public $env = null; public function __construct($env = 'test') { $this->env = $env; } private function connectDB(PDO $connection = null) { if ($connection === null) { $connection = new PDO();//you know the deal... } $this->defaultDB = $connection; } public function getDB(PDO $conn = null) {//get connection if ($this->defaultDB === null) { $this->connectDB($conn); } return $this->defaultDB; } public function registerController(MyConstroller $controller) {//<== magic! $controller->registerApplication($this); return $this; } } </code></pre> As you can see, the <code>Application</code> class has a method that passes the <code>Application</code> instance to your controller, or whatever part of your framework you want to grant access to scope of the <code>Application</code> class. Note that I've declared the <code>defaultDB</code> property as a private property, so I'm using a getter. I can, if I wanted to, pass a connection to that getter. There's a lot more you can do with that connection, of course, but I can't be bothered writing a full framework to show you everything you can do here :). Basically, all your controllers will extend the <code>MyController</code> class, which could be an abstract class that looks like this: <pre><code>abstract class MyController { private $app = null; protected $db = null; public function __construct(Application $app = null) { if ($app !== null) { return $this->registerApplication($app); } } public function registerApplication(Application $app) { $this->app = $app; return $this; } public function getApplication() { return $this->app; } } </code></pre> So in your code, you can easily do something along the lines of: <pre><code>$controller = new MyController($this);//assuming the instance is created in the Application class $controller = new MyController(); $controller->registerApplication($appInstance); </code></pre> In both cases, you can get that single DB instance like so: <pre><code>$controller->getApplication()->getDB(); </code></pre> You can test your framework with easily by passing a different DB connection to the <code>getDB</code> method, if the <code>defaultDB</code> property hasn't been set in this case. With some extra work you can register multiple DB connections at the same time and access those at will, too: <pre><code>$controller->getApplication->getDB(new PDO());//pass test connection here... </code></pre> This is, by no means, the full explanation, but I wanted to get this answer in quite quickly before you end up with a huge static (and thus useless) codebase. In response to comments from OP: On how I'd tackle the <code>Config</code> class. Honestly, I'd pretty much do the same thing as I'd do with the <code>defaultDB</code> property as shown above. But I'd probably allow for more targeted control on what class gets access to what part of the config: <pre><code>class Application { private $config = null; public function __construct($env = 'test', $config = null) {//get default config path or use path passed as argument $this->config = new Config(parse_ini_file($config)); } public function registerController(MyController $controller) { $controller->setApplication($this); } public function registerDB(MyDB $wrapper, $connect = true) {//assume MyDB is a wrapper class, that gets the connection data from the config $wrapper->setConfig(new Config($this->config->getSection('DB'))); $this->defaultDB = $wrapper; return $this; } } class MyController { private $app = null; public function getApplication() { return $this->app; } public function setApplication(Application $app) { $this->app = $app; return $this; } //Optional: public function getConfig() { return $this->app->getConfig(); } public function getDB() { return $this->app->getDB(); } } </code></pre> Those last two methods aren't really required, you could just as well write something like: <pre><code>$controller->getApplication()->getConfig(); </code></pre> Again, this snippet is all a bit messy and incomplete, but it does go to show you that you can "expose" certain properties of one class, by passing a reference to that class to another. Even if the properties are private, you can use getters to access them all the same. You can also use various register-methods to control what it is the registered object is allowed to see, as I've done with the DB-wrapper in my snippet. A DB class shouldn't deal with viewscripts and namespaces, or autoloaders. That's why I'm only registering the DB section of the config. Basically, a lot of your main components will end up sharing a number of methods. In other words, they'll end up implementing a given interface. For each main component (assuming the classic MVC pattern), you'll have one abstract base-class, and an inheritance chain of 1 or 2 levels of child classes: <code>Abstract Controller</code> > <code>DefaultController</code> > <code>ProjectSpecificController</code>. At the same time, all of these classes will probably expect another instance to be passed to them when constructed. Just look at the <code>index.php</code> of any ZendFW project: <pre><code>$application = new Zend_Application(APPLICATION_ENV); $application->bootstrap()->run(); </code></pre> That's all you can see, but inside the application, all other classes are being instantiated. That's why you can access neigh on everything from anywhere: all classes have been instantiated inside another class along these lines: <pre><code>public function initController(Request $request) { $this->currentController = $request->getController(); $this->currentController = new $this->currentController($this); return $this->currentController->init($request) ->{$request->getAction().'Action'}(); } </code></pre> By passing <code>$this</code> to the constructor of a controller class, that class can use various getters and setters to get to whatever it needs... Look at the examples above, it could use <code>getDB</code>, or <code>getConfig</code> and use that data if that's what it needs. That's how most frameworks I've tinkered or worked with function: The application is kicks into action and determines what needs to be done. That's the Hollywood-principle, or Inversion of Control: the Application is started, and the application determines what classes it needs when. In the link I provided I believe this is compared to a store creating its own customers: the store is built, and decides what it wants to sell. In order to sell it, it will create the clients it wants, and provide them with the means they need to purchase the goods... And, before I forget: Yes, all this can be done without a single static variable, let alone function, coming into play. I've built my own framework, and I've never felt there was no other way than to "go static". I did use the Factory pattern at first, but ditched it pretty quickly. IMHO, a good framework is modular: you should be able to use bits of it (like Symfony's components), without issues. Using the Factory pattern makes you assume too much. You assume class X will be available, which isn't a given. Registering those classes that are available makes for far more portable components. Consider this: <pre><code>class AssumeFactory { private $db = null; public function getDB(PDO $db = null) { if ($db === null) { $config = Factory::getConfig();//assumes Config class $db = new PDO($config->getDBString()); } $this->db = $db; return $this->db; } } </code></pre> As opposed to: <pre><code>class RegisteredApplication {//assume this is registered to current Application public function getDB(PDO $fallback = null, $setToApplication = false) { if ($this->getApplication()->getDB() === null) {//defensive if ($setToApplication === true && $fallback !== null) { $this->getApplication()->setDB($fallback); return $fallback;//this is current connection } if ($fallback === null && $this->getApplication()->getConfig() !== null) {//if DB is not set @app, check config: $fallback = $this->getApplication()->getConfig()->getSection('DB'); $fallback = new PDO($fallback->connString, $fallback->user, $fallback->pass); return $fallback; } throw new RuntimeException('No DB connection set @app, no fallback'); } if ($setToApplication === true && $fallback !== null) { $this->getApplication()->setDB($fallback); } return $this->getApplication()->getDB(); } } </code></pre> Though the latter version is slightly more work to write, it's quite clear which of the two is the better bet. The first version just assumes too much, and doesn't allow for safety-nets. It's also quite dictatorial: suppose I've written a test, and I need the results to go to another DB. I therefore need to change the DB connection, for the entire application (user input, errors, stats... they're all likely to be stored in a DB). For those two reasons alone, the second snippet is the better candidate: I can pass another DB connection, that overwrites the application default, or, if I don't want to do that, I can either use the default connection, or attempt to create the default connection. Store the connection I just made, or not... the choice is entirely mine. If nothing works, I just get a <code>RuntimeException</code> thrown at me, but that's not the point.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POAlternatives to static methods in a framework PHP
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USBenjamin Delichere
UserOwnerUserId
1. USElias Van Ootegem
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POAlternatives to static methods in a framework PHP
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.