To Static, or Not To Static

there is a package called SublimeCodeIntel, that does that.

Because the module that does the database query also needs information stored in 3 other objects. Otherwise, how would I access that information from within another object unless I pass those objects to it?

$db = new Database;
$config = new SiteConfig; 
$prefs = new UserPrefs; 

$page = new WebPage($db, $config, $prefs, 'homepage'); 

The database query to load data for a page, for example, also needs some information from the SiteConfig and UserPrefs classes, and needs the Database class the actually run the query.

$query = "SELECT ... WHERE site_status = ".$config->status." AND page_status = ".$prefs->homepage; 

I don’t see how to avoid this without combining those classes into one, larger class.

I see, that makes sense. Thanks!

Thanks! I did install that package, but it’s not working very well for me. The auto-complete only works when triggered manually with Command-Space (on a Mac). And it only seems to know function parameters from within the same script, not from other included scripts. On the GitHub page for that package, this bug has been documented, but there have been no updates for the past two years, unfortunately.

Can you post an example of the whole class? I think we might be getting on to something but it’s important that we know where these pieces of code you presented are located. Also, it would be good to see where you are using this object and how - for example, another class that executes a method on this object.

The actual code that puts all these pieces together hasn’t been completed yet, the things I posted above are just hypothetical right now based on what I think I’m going to need to do. But once I do have some real code, I’ll post it here for your input.

I do have a question about the DI Factory object. Is this supposed to be passed into another object as a dependency if that object may need an instance of another object? I’m not really sure how this is to be implemented in actual code because I’m not yet at that stage in my project. But it seems wrong to pass the factory to another object as a dependency even though that object may need to use a method in the factory.

From everything I’ve watched and read recently, I’m guessing that if my object needs the factory, then the class isn’t written properly.

Also, what controls all this, the index.php file? Where do I do all the actual work of building these objects with their dependencies? This is what I find so strange about OOP, procedural programming is still needed in places to put it all together, it seems. Thanks!

Actual code is not needed, the important thing is how you imagine it to be as a whole class and how it’s going to be used.

And so you answered your own question :smiley: If you pass a factory to an object then that object can pull anything from the factory and it is not clear what exactly it will pull without examining the whole class - the dependencies become fuzzy and you give the object too much power than it needs. It is better to pass only the specific dependencies the object needs, not a whole bag of dependencies to choose from at will.

This is why Yegor was saying that DI containers are bad except his terminology is a bit different from what is used among PHP programmers. He assumed that when someone uses a DIC then he will pass it around to other objects - and this is bad. However, when you use a DIC only in the outer layer of your application to construct objects then you don’t need to pass the container anywhere. So yes, the objects should not depend on the container nor should they be aware of its existence.

We could say it’s index.php but it doesn’t have to be this one file. Rather than restrict this to one file I would call it an entry point or an entry layer to the application - it can be composed of different classes in separate files depending on how complex this entry layer is.

Well, I think we can’t escape procedural programming altogether because computers are designed to execute procedures - one after another so inherently they are procedural and not object oriented. As I understand it object oriented programming runs on top of procedural execution. Even when we deal with objects they are always constructed by a procedural architecture underneath.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.