Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am currently building a web app in php using Laravel-4, however, I suspect that this question is applicable to other languages and frameworks as well.
I have read about dependency injection and Facades and understand the necessary coding in each case. What I am not clear on is when you should use one over the other?
What the advantages/disadvantages or simply the reasons for using either dependency injection over the Facade design pattern?
Many thanks
Facades are used to make interactions with classes easier to read and use. It makes the code appear that you're using a bunch of static methods to interact with a class without instantiating it when in actuality you are calling methods on an existing object.
Dependency injection is used to, as the name implies, inject the dependencies of a class into the class. This is done through the constructor. You inject classes into another class to allow the class to use the functionality from the injected classes. This becomes powerful when you start injecting an interface into a class. Then you can create a class based on the interface and inject it into the class. This way, if you need to change the way the injected class works, you can create a new class based on the interface and inject it. Since you code is based on the injected interface, it will ensure that the class the received the injections will continue to work without needing to be changed.
This is most notable in Laravel 4 if you create a repository which is based on an interface for the Eloquent engine. You can inject that repository into a controller and use the methods on the interface to get the info you need. then if you ever want to switch to something like Redis, all you have to do is make a new class based on that interface that uses the Redis engine instead and then inject that class. The controller will never need to be changed.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Since Symfony 5.1 injecting the Container by autowiring the Psr\Container\ContainerInterface is deprecated see https://symfony.com/doc/current/service_container.html#public-versus-private-services
In case a service still needs access to the Container, does it needs to be injected by hand for the future, or is there another, more convenient, way to inject it?
One option would be to use Autowiring by Name and inject it, whenever there's a variable called $container, however that feels like a hack.
Question: What is the best practice of giving a service access to the container, if it still depends on it in Symfony 5.1+?
Making your services container-aware has been discouraged for quite a while.
As a general rule, you should avoid making your services container-aware and instead directly pass in the required services in the constructor or via setter-injection. In some cases using a container as a service locator can be useful though. For example when you use the AbstractController or when you have a service that takes in a lot of "registered" services, e.g. for handlers/senders in a Message Bus. For those cases Symfony provides a Service Locator/Subscriber: https://symfony.com/doc/current/service_container/service_subscribers_locators.html
The major difference is, that you have to define the services for the locator/subscriber instead of having all services available, like in Symfony's internal container. You can however tag services that should go into your service locator/subscriber and then collect these tagged services, so they will be passed automatically. See: https://symfony.com/doc/current/service_container/tags.html#reference-tagged-services
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
How to make PDO instance available throughout entire application in PHP ?
I'm using autoload from PS4 allowing to access any class in the application by using :
use Namespace\ClassName;
In the case the class has static method, I can use this very handful way to call the method :
Class::method();
I would like to be able to initiate a PDO connection once in the application and be able to use it everywhere.
I already have a PDO class with all the convenient methods to request the database. When this class is instanciated, it connects to the database and store the connection in a class attribute.
Some solutions are available but it has some drawbacks :
1) Instanciate the PDO once and pass it to the constructor of classes.
I'm not a big fan of this strategy because it forces me to instanciate classes using
$instance = new Class($pdo);
Class->method();
Which is less pretty than Class::method();
2) Make pdo instance Global
I don't know why but I saw everywhere it was a bad idea. Instinctively I'm not a fan of it too.
3) Pass it to methods while using them.
It looks very dirty to me and not convenient at all.
Do you have any idea on how to achieve it ?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I just learned about Laravel Service Containers and it seems like a great functionality.
as I understood it prevents us from rewriting 50 controllers when we should modify a commonly used entity or variable throughout the project.
the problem being is that I don't see a proper Use case for this feature, I mean if you have a piece of data or an entity that you're repeatedly using: this can be customized through a model
so when should I use service containers in laravel ?
what are the Pros and cons of this functionality ?
as I understood it prevents us from rewriting 50 controllers when we should modify a commonly used entity or variable throughout the project.
I do not believe you understand it correctly.
Service Containers are just a fancy term that Laravel came up with to describe dependency injection. The major benefit is for unit testing and its biggest competitor is the facade pattern that Laravel also uses. The biggest benefit of dependency injection is that you can mock expectations without requiring additional "scaffolding" code that bootstraps the test. More information about using dependency injection for unit testing: https://medium.com/philipobenito/dependency-injection-as-a-tool-for-testing-902c21c147f1
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am building a MVC application in PHP, and am creating a Form class to generate a form that you can add elements to. Should I use static methods to generate the form, such as Form::generate(...) or in my view class where I declare variables to be used in a view file, should I instantiate the class and use it like $form->generate(...)? I have heard using static methods are bad because of testing, but I don't know. Thanks!
Beside the problem that PHPUnit doesn't support static mocks, the more obvious problem is that of loose coupling and dependency injection. It's completely fine if you have state-independent methods, but to strictly define those methods with the static keyword creates a hard dependency on the classname behind the double colon operator. (In fact, it's that hard dependency that makes the PHPUnit problem so tricky.)
I would agree that static methods have rather fallen out of favour except in certain applications such as:
Facade pattern, where the static methods hide a more complex API http://en.wikipedia.org/wiki/Facade_pattern
Factory pattern, where the static methods are responsible for creating and configuring object instances http://en.wikipedia.org/wiki/Factory_method_pattern
Utility type functions where the class is used almost like a namespace to group together related functions, but the functions themselves are basically procedural (examples could include string, date or price formatting functions)
I would start by creating one Form class that represents your form, and if necessary adding a factory helper which generates an instance of your form.
You might like to take a look at the Symfony form builder, their approach is elegant:
http://symfony.com/doc/current/book/forms.html#building-the-form
That depends, generally static methods wont maintain state, or in other words, you can't use dynamic properties within that class, or instantiate the class ( obviously ).
If you are using them as an OOP way of doing functions it should be fine, in fact I think Laravel uses a lot of them.
http://laravel.com/docs/quick
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
When using Object-Oriented programming in PHP is there a simple rule of thumb on what should be made into an object or should you try to make the entire program using object-oriented code. I know this is quite opinion based but I can't seem to find any resources that could answer it for me.
Thanks.
I would suggest to read general oop concepts to get grip on that: http://oopsconcepts.blogspot.de/
What an object should be is largely language independent and whether your function should be an object or not fully depends on the context in what it is used.
Trivial code is usually not improved by making it object oriented.
In a scenario where your function is injected into something and must be replaceable it might make sense to make an object that implements an interface out of it.
Objects (or rather classes) should relate to a specific noun. For example, you might have a class called User, or Product. Functions generally are verbs. So you might have something like Product->Update().
Simple having a collection of unrelated functions in a generic Class does not constitute good OOP design. If the function is simply doing as you've advised, then it shouldn't have its own class.
A fairly standard pattern to follow with the kind of trivial, but global function your are discussing is to add it to a Utilty class.
In principle that is simply a class with public static member methods, that would normally be grouped by relation - exactly as you would a file of functions.
class MyFileUtility
{
public static function FileToArray($filePath) { // do stuff }
public static function ArrayToFile($array, $filePath { //do stuff }
...
}
$array = MyFileUtility::FileToArray('somefile');
Now you will use the methods of the Utility exactly as you would a function, but they are in a class, if it makes you feel better.
There are a couple of benefits:
Auto-loading will work, so long as you have configured it.
IMO You will generally be in a better / safer namespace situation.
If you like typing "::" You are well in :)
_____________ Edit _________________
Here is an explanation of a static Utility class added for clarity.
http://en.wikipedia.org/wiki/Utility_pattern