I'm trying to get some service (e.g. session) from outside of controller.
Please, explain how to do this right-way.
There are many different ways, all having pros and cons.
First, every service is some kind of object, so you can always just create the object in question yourself. You may be forced to deal with many references, but it's possible. This undermines the idea of Dependency Injection, so it's not what you should do!
The second way is inject the service into your class:
class MyClass{
public function __construct($session){
// ...
}
}
class MyContainer extends Controller{
public function SomeKindOfAction(){
$myClass = new MyClass($this->get('session'));
}
}
This might be ok if you only use the class within your Controller. If you have more nested relations, like in MyClass, you create another class where you need the session, you might run into tight coupling (which is to avoid) as well as complexity issues.
The best way is to create your own service and injecting the things you need there. There are many documentations out there, so I'll just give a short example using MyClass above.
services.yml:
services:
my.myClass:
class: /Acme/DefaultBundle/MyStuff/MyClass
arguments: ["#session"]
Now your Class is as service (who would guess it's that easy!) and you can use it within your controller:
class MyContainer extends Controller{
public function SomeKindOfAction(){
$myClass = $this->get('my.myClass');
}
}
Now you don't have to think about constructor and how to get your objects, the DI-Container will do it for you. If you want to know more, read here.
Related
Sorry if this is a duplicate question or a common design principle, I have searched around but was unable to find any answers to this question. I'm probably just searching with the wrong keywords.
I have been looking at a popular library Sabre/Event (https://sabre.io/event/) and in the code there is a simple class/inheritance model that I am trying to understand:
The class EventEmitter implements EventEmitterInterface and uses EventEmitterTrait (see below for code).
There is a comment in EventEmitterTrait above the class which says:
* Using the trait + interface allows you to add EventEmitter capabilities
* without having to change your base-class.
I am trying to understand why this comment says this, and why it allows adding capabilities without changing the base class, and how that is different from just putting the routines into EventEmitter itself.
Couldn't you just extend EventEmitter and add capabilities in the derived class?
Simplified code:
// EventEmitter.php
class EventEmitter implements EventEmitterInterface {
use EventEmitterTrait;
}
// EventEmitterInterface.php
interface EventEmitterInterface {
// ... declares several function prototypes
}
// EventEmitterTrait.php
trait EventEmitterTrait {
// ... implements the routines declared in EventEmitterInterface
}
You're basically asking two questions here.
What are interfaces and why are they useful?
What are traits and why are they useful?
To understand why interfaces are useful you have to know a little about inheritance and OOP in general. If you've ever heard the term spaghetti code before (it's when you tend to write imperative code that's so tangled together you can hardly make sense of it) then you should liken that to the term lasagna code for OOP (that's when you extend a class to so many layers that it becomes difficult to understand which layer is doing what).
1. Interfaces
Interfaces diffuse some of this confusion by allow a class to implement a common set of methods without having to restrict the hierarchy of that class. we do not derive interfaces from a base class. We merely implement them into a given class.
A very clear and obvious example of that in PHP is DateTimeInterface. It provides a common set of methods which both DateTime and DateTimeImmutable will implement. It does not, however, tell those classes what the implementation is. A class is an implementation. An interface is just methods of a class sans implementation. However, since both things implement the same interface it's easy to test any class that implements that interface, since you know they will always have the same methods. So I know that both DateTime and DateTimeImmutable will implement the method format, which will accept a String as input and return a String, regardless of which class is implementing it. I could even write my own implementation of DateTime that implements DateTimeInterface and it is guaranteed to have that method with that same signature.
So imagine I wrote a method that accepts a DateTime object, and the method expects to run the format method on that object. If it doesn't care which class, specifically, is given to it, then that method could simply typehint its prototype as DateTimeInterface instead. Now anyone is free to implement DateTimeInterface in their own class, without having to extend from some base class, and provide my method with an object that's guaranteed to work the same way.
So in relation to your EventEmitter example, you can add the same capabilities of a class (like DateTime) to any class that might not even extend from DateTime, but as long as we know it implements the same interface, we know for sure it has the same methods with the same signatures. This would mean the same thing for EventEmitter.
2. Traits
Traits, unlike interfaces, actually can provide an implementation. They are also a form of horizontal inheritance, unlike the vertical inheritance of extending classes. Because two completely different class that do not derive from the same base class can use the same Trait. This is possible, because in PHP traits are basically just compiler-assisted copy and paste. Imagine, you literally copied the code inside of a trait and just pasted it into each class that uses it right before compile time. You'd get the same result. You're just injecting code into unrelated classes.
This is useful, because sometimes you have a method or set of methods that prove reusable in two distinct classes even though the rest of those classes have nothing else in common.
For example, imagine you are writing a CMS, where there is a Document class and a User class. Neither of these two classes are related in any meaningful way. They do very different things and it makes no sense for one of them to extend the other. However, they both share a particular behavior in common: flag() method that indicates the object has been flagged by a user for purposes of violating the Terms of Service.
trait FlagContent {
public function flag(Int $userId, String $reason): bool {
$this->flagged = true;
$this->byUserId = $userId;
$this->flagReason = $reason;
return $this->updateDatabase();
}
}
Now consider that perhaps your CMS has other content that's subject to being flagged, like a Image class, or a Video class, or even a Comment class. These classes are all typically unrelated. It probably wouldn't make much sense just to have a specific class for flagging content, especially if the properties of the relevant objects have to be passed around to this class to update the database, for example. It also doesn't make sense for them to derive from a base class (they're all completely unrelated to each other). It also doesn't make sense to rewrite this same code in every class, since it would easier to change it in one place instead of many.
So what seems to be most sensible here is to use a Trait.
So again, in relation to your EventEmitter example, they're giving you some traits you can reuse in your implementing class to basically make it easier to reuse the code without having to extend from a base class (horizontal inheritance).
Per Sabre's Event Emitter's docs on "Integration into other objects":
To add Emitter capabilities to any class, you can simply extend it.
If you cannot extend, because the class is already part of an existing
class hierarchy you can use the supplied trait.
So in this case, the idea is if you're using your own objects that already are part of a class hierarchy, you may simply implement the interface + use the trait, instead of extending the Emitter class (which you won't be able to).
The Integration into other objects documentation says:
If you cannot extend, because the class is already part of an existing class hierarchy you can use the supplied trait".
I understand it's a workaround when you already have an OOP design you don't want to alter and you want to add event capabilities. For example:
Model -> AppModel -> Customer
PHP doesn't have multiple inheritance so Customer can extend AppModel or Emitter but not both. If you implement the interface in Customer the code is not reusable elsewhere; if you implement in e.g. AppModel it's available everywhere, which might not be desirable.
With traits, you can write custom event code and cherry-pick where you reuse it.
This is an interesting question and I will try to give my take on it. As you asked,
What is the purpose of using traits to define functions for an interface ?
Traits basically gives you the ability to create some reusable code or functionality which can then be used any where in your code base. Now as it stands, PHP doesn't support multiple inheritance therefore traits and interfaces are there to solve that issue. The question here is why traits though ?? Well imagine a scenario like below,
class User
{
public function hasRatings()
{
// some how we want users to have ratings
}
public function hasBeenFavorited()
{
// other users can follow
}
public function name(){}
public function friends(){}
// and a few other methods
}
Now lets say that we have a post class which has the same logic as user and that can be achieved by having hasRatings() and hasBeenFavorited() methods. Now, one way would be to simply inherit from User Class.
class Post extends User
{
// Now we have access to the mentioned methods but we have inherited
// methods and properties which is not really needed here
}
Therefore, to solve this issue we can use traits.
trait UserActions
{
public function hasRatings()
{
// some how we want users to have ratings
}
public function hasBeenFavorited()
{
// other users can follow
}
}
Having that bit of logic we can now just use it any where in the code where ever it is required.
class User
{
use UserActions;
}
class Post
{
use UserActions;
}
Now lets say we have a report class where we want to generate certain report on the basis of user actions.
class Report
{
protected $user;
public function __construct(User $user)
{
$this->user = $user
}
public function generate()
{
return $this->user->hasRatings();
}
}
Now, what happens if i want to generate report for Post. The only way to achieve that would be to new up another report class i.e. maybe PostReport.. Can you see where I am getting at. Surely there could be another way, where i dont have to repeat myself. Thats where, interfaces or contracts come to place. Keeping that in mind, lets redefine our reports class and make it to accept a contract rather than concrete class which will always ensure that we have access to UserActions.
interface UserActionable
{
public function hasRatings();
public function hasBeenFavorited();
}
class Report
{
protected $actionable;
public function __construct(UserActionable $actionable)
{
$this->actionable = $actionable;
}
public function generate()
{
return $this->actionable->hasRatings();
}
}
//lets make our post and user implement the contract so we can pass them
// to report
class User implements UserActionable
{
uses UserActions;
}
class Post implements UserActionable
{
uses UserActions;
}
// Great now we can switch between user and post during run time to generate
// reports without changing the code base
$userReport = (new Report(new User))->generate();
$postReport = (new Report(new Post))->generate();
So in nutshell, interfaces and traits helps us to achieve design based on SOLID principles, much decoupled code and better composition. Hope that helps
Doctrine examples usually make use of Doctrine's $entityManager. Hence, whenever I need to do anything in my app with Doctrine, I need to get the entity manager into my code. But how? .... I can inject it into my class, but still I need to create manager somewhere first. I can also make it use PHP's trait which I put into my class to make it Doctrine-enabled.
What I have done in my OOP code is something like this -- I defined a class DoctrineConnector in its own namespace of DoctrineConnector, and inside the class I have a static function getEntityManager. Inside, I read Doctrine configuration, paths, parameters, and create an $entityManager, and then I return it to the caller.
Whenever I need to read or persist something in my Doctrine-unaware code, I do this:
//Pricing.php
use DoctrineConnector\DoctrineConnector;
class Pricing
{
public function getPricing()
{
$entityManager = DoctrineConnector::getEntityManager();
//further Doctrine code to read DB
}
}
DoctrineConnector is now a dependency of Pricing. Obvious answer may be "inject $entityManager into Pricing". But Pricing is called from another class, and that other class is called from another class, etc so I will have to make essentially every class I call be aware of the ORM variable. I want to avoid that.
Is what I currently have just fine or is there a better way?
How ZF2 module system does it
Out of curiosity I looked into how ZF2 manages Doctrine module and from DoctrineORMModule, it uses ServiceLocator pattern to call the inside of controller. So one of the leading framework module systems is not that far off from my implementation.
Singleton Pattern
Adapted from http://www.phptherightway.com/pages/Design-Patterns.html
namespace ABC;
use Doctrine\ORM\Tools\Setup;
use Doctrine\ORM\EntityManager;
class DoctrineConnector
{
private static $instance;
public static function getEntityManager()
{
if (null === static::$instance)
{
// Doctrine Config (from Docs)
include 'config/doctrine-config.php';
$config = Setup::createAnnotationMetadataConfiguration($paths, $isDevMode);
static::$instance = EntityManager::create($dbParams, $config);
}
return static::$instance;
}
protected function __construct()
{}
private function __clone()
{}
private function __wakeup()
{}
}
//to call
$em = DoctrineConnector::getEntityManager();
//if used later in the code - calls same instance
$em = DoctrineConnector::getEntityManager();
There are a couple of popular ways to get a dependency inside the class.
make the class aware of project environment and let the class locate the dependency (what you did with DoctrineConnector)
use dependency injection (what you are trying to achieve)
In your case, your class now depends on DoctrineConnector and is going to work as long as it can find DoctrineConnector. If you port your class to another project where DoctrineConnector isn't defined, your code isn't going to work.
Normally dependency injection is a decision you make when you start your new project. If you already have a large hierarchy of classes, the injection code will bubble up your hierarchy and there is going to be a lot of work refactoring your code. You might want to think wether you really need that and wether it's going to be worth your time.
If you are writing code for one particular app and have no plans to migrate it to other projects, then you probably don't care about dependency injection. Actually, without injection your code is going to be shorter and easier (faster) to write and understand. On the other hand if you have pieces of code that you want to be independent of the app, you might use dependency injection only for those code segments.
If you haven't injected ORM yet, chances are that the rest of the code is tightly coupled with your app as well, and injecting entityManager isn't going to make your code much more portable.
I've been changing my Controllers and helper classes to use dependency injection, and it seems I've got my helper classes stuck in an infinite loop.
Below is my custom ServiceProvider and the two sample helper classes. As you can see, they inject each other, so they keep going back and forth.
What's the solution to this issue? What mistake do I seem to be making? What can I do so that I can run tests on helper classes like General and Person, while mocking the helper classes that are called from inside of them?
One way that I guess could work is in my ServiceProvider, do the following:
if (isset($appmade->General)) {
// inject the General app that's already instantiated
} else {
$abc = app::make('\Lib\MyOrg\General');
$appmade->General = $abc;
}
Is that the correct way?
// /app/providers/myorg/MyOrgServiceProvider.php
namespace MyOrg\ServiceProvider;
use Illuminate\Support\ServiceProvider;
class MyOrgServiceProvider extends ServiceProvider
{
public function register()
{
$this->app->bind('\Lib\MyOrg\General', function ($app) {
return new \Lib\MyOrg\General(
$app->make('\Lib\MyOrg\Person'),
$app->make('\App\Models\User')
);
});
$this->app->bind('\Lib\MyOrg\Person', function ($app) {
return new \Lib\MyOrg\Person(
$app->make('\Lib\MyOrg\General'),
$app->make('\App\Models\Device')
);
});
}
}
// /app/libraries/myorg/general.php
namespace Lib\MyOrg;
use App\Models\User;
use Lib\MyOrg\Person;
class General
{
protected $model;
protected $class;
public function __construct(Person $personclass, User $user)
{
}
}
// /app/libraries/myorg/person.php
namespace Lib\MyOrg;
use App\Models\Device;
use Lib\MyOrg\General;
class Person
{
protected $model;
protected $class;
public function __construct(General $generalclass, Device $device)
{
}
}
Your helper classes have a case of circular dependency which, when mixed with dependency injection, make them un-instantiable...and there's no good way to get them to work and be easily testable.
There are some hack-y ways to get this to work:
You could use setter injection, injecting the dependency in a
setter method when the helper is used, rather than in the constructor
when it is instantiated. This has many disadvantages, poor
testability being chief among them. (See
http://symfony.com/doc/current/components/dependency_injection/types.html)
In Laravel 5, you could use method injection, particularly if the
dependency is only pertinent to one or two methods. (See
http://mattstauffer.co/blog/laravel-5.0-method-injection)
You could do an existence check like you propose above, or something
with an event listener. But all of this is masking the fact that...
A circular dependency usually indicates that a design change is in order, and is best solved by reconsidering how your classes interact with each other.
If your Person and General classes depend fully on each other, then
it's possible they share a single responsibility and should be
combined into a single class.
If, however, they rely on a subset of each other's functionality,
then there's probably a separate class with its own responsibility
hiding in there somewhere, and then the best solution would be
extract the common functionality into a 3rd class. That way, rather
than having Class A rely on Class B and Class B rely on Class A, both
Classes A and B would instead rely on Class C. You can safely
instantiate them all, and they all remain easily testable.
How can you easily figure out what your new Class C should contain? A great rule of thumb comes from http://misko.hevery.com/2008/08/01/circular-dependency-in-constructors-and-dependency-injection/... "List all of the methods in your class A used by class B, and all the methods in your class B used by class A. The shorter of the two lists is your hidden Class C."
I have a custom framework where i have a class/method which uses my own Cache class.
Currently it is tightly coupled. So a method instantiates the Cache class like this:
public function someMethod ( )
{
$cache = new Cache\HHCache();
}
I want ro remove the tight coupling but that's actually where i'm a bit stuck.
I thought it would be a good idea to create some sort of ServiceProvider class. But i'm not sure if this is really the right approach.
To start i have HHConfig file which has a static property in which a cache class is defined. In short:
class HHConfig
{
static $_cacheClass = '\Core\Cache\HHCache';
}
So basically i have a class like this, which is part of the Core functionality of my framework:
interface IHHServiceProvider
{
public function getService ( );
}
Then i have another class which implements this interface.
class HHCacheProvider implements IHHServiceProvider
{
public static function getService ( )
{
$class = HHConfig::$_cacheClass;
return new $class();
}
}
So now someMethod can use the HHCacheProvider class to get an instance of a Cache class.
public function someMethod ( )
{
$cache = HHCacheProvider::getService ( );
}
My IHHServiceProvider isn't really like the typical Provider class since you can't really register any Services to it. It simply looks in the HHConfig class what "class" to load and returns in instance of that.
So somehow this method doesn't feel right to me, but i do think it shows what i want to achieve. In what ways can i improve this?
Please note that i'm not looking for a simple Dependency Injection pattern for this. Because i don't want to inject my Cache class to every constructors class. I need a non tight coupling way of getting an instance of the HHCache class somehow from within a method.
Some sort of provider class that can be part of my framework seems like the right direction.
Note: "provider" means nothing. There is not pattern by that name.
Instead of making some magical "privider", you should take a look at factory pattern. Basically the idea is a follows:
You inject a factory in classes that will use some services (assuming that Cache is not the only form of service that you aim for).
The class request from factory the service that it needs:
if service has been already initialized once, it just returns an instance to your
else it creates new instance, stores it and returns you to "consumer"
The simplest code example would be something like this:
class ServiceFactory
{
private $storage = [];
public function create( $name )
{
if ( false === array_key_exists( $name, $this->storage ))
{
$instance = new $name;
$this->storage[$name] = $instance;
}
return $this->storage[$name];
}
}
This is an extremely simplified example, but even in this case, if you inject an instance of this factory in any number of objects, they all will have access to same pool of instances.
If you ever decide to look into concept of DI Containers, then factories are also the place where it is appropriate to utilize them, without degrading them to as service locator anti-pattern.
.. and few lectures that you might find valuable:
The Clean Code Talks - Don't Look For Things!
The Clean Code Talks - Global State and Singletons
As per OP request
Especially since it will be part of the framework, you should inject the Cache. A DI Container is the best solution here, you can config the actually Cache implementation as a singleton. Your proposed solution is tightly coupled to some service and hard to test in isolation. Actually it looks more of a service locator pattern rather than provider.
If you're using a Factory that won't replace the DI Container. THe point of DI is that the code shouldn't be coupled to an outside static service. Unless you have a very good reason, any object should use only the injected (via constructor or as method argument) dependencies.
I've defined a hash salt in my config.yml and would like to get this in my User class, any ideas about how to do this? I've seen loads of examples about how to use this in the controller class, but not in the model?
Thanks
I've had the same question. It'd be nice if there was something similar to sfConfig::get() from symfony 1. Anyway, I think this may actually be a case of "there's a better way to do this". What if you just use setter injection when you instantiate your User class (ie use a setHashSalt() method)? If you're instantiating from a controller you can use $this->container->parameters['hash_salt'].
AFAIK, there's no way to access config.yml parameters without using the container object. I'm very curious to see if anyone has an easier way.
See my answer here:
How do I read configuration settings from Symfony2 config.yml?
with
FIRST APPROACH: Separated config block, getting it as a parameter
SECOND APPROACH: Separated config block, injecting the config into a service
Answering to you, if you want to inject that in the Model, the best approach is to have a Manager that acts as a factory of the model, then the manager can inject itself into the model, so the model can get access it and therefore, get access to the configuration.
Say, your model has a Car and a House if they are related you could have a CityManager with a getAllCars() or getCarById() or similar, as well as a getAllHouses() or a getHouseById() or so.
Then in the CityManager either pass the config to the Model class:
class CityManager()
{
private $myConfigValue;
public getCarById( $id )
{
return new Car( $id, $this->myConfigValue );
}
}
either pass yourself, and let the Model get the config only if it needs it:
class CityManager()
{
private $myConfigValue;
public getCarById( $id )
{
return new Car( $id, $this );
}
public getConfig()
{
return $this->myConfigValue;
}
}
Fill the value as in the article linked.