Slim ramy: currying vs Dependency Injection

Question

W pewnych ram jak kątowe, można wstrzyknąć usług i kontrolerów do jednego innego jak ten

App.controller('exampleController', function($scope, ajaxService){ 

    ajaxService.getData().then(function(data) { 

     //do something with the data 

    }); 

}); 

To się nazywa Dependency Injectionaccording kątowym docs

You można zrobić coś takiego w Slim Framwork też, tak jak ten

$app->get('/example', function() use ($app, $db) { 

    $data = $db->getData(); 

    //do something with the data 

} 

To jest calle d Currying zgodnie z Slim docs.

O ile widzę, są to dokładnie to samo? Dlaczego są wywoływane przez różne imiona?

Answer 1

kilka interesujących czytania tutaj: What is currying What is dependency injection

Bez względu na język programowania lub ramy, moglibyśmy powiedzieć „Dependency Injection” (DI) jest coś takiego jak delegacji w definicji OOP klasy (patrz przykład) i currying jest czymś zupełnie innym, powiedzmy uproszczeniem funkcji.

DI pozwala na łatwe prowadzenie zajęć i rozłączenie. Jeśli znasz Laravel, ServiceProvider to dobry przykład. W skrócie twoja klasa ma właściwość, która zostanie ustawiona na instancję innej klasy (zwykle implementującej interfejs), abyś mógł delegować niektóre funkcje. Typowy przykład:

interface LogInterface { 
    public function write(); 
} 

class LogToFile implements LogInterface { 
    public function write() 
    { 
     //Do something 
    } 
} 

class LogToFileDB implements LogInterface { 
    public function write() 
    { 
     //Do something 
    } 
} 

class MyDIClass { 
    private $log; 

    public function __construct(LogInterface $log){ 
     $this->log = $log; 
    } 

    public function writeLog(){ 
     $this->log->write(); 
    } 
} 

//You can do 
$myobj = new MyDIClass(new LogToFile); 
//or you can do 
//$myobj = new MyDIClass(new LogToDB); 

//this will work, no worries about "write()" you are delegating through DI 
$myobj->writeLog(); 

Właśnie napisałem ten kod powyżej (prawdopodobnie nie działa), aby zilustrować DI. Za pomocą interfejsu zapewniamy, że metoda "write()" zostanie zaimplementowana w dowolnej klasie implementującej LogInterface. Następnie klasa wymusza uzyskanie obiektu LogInterface po utworzeniu obiektów. Zapomnij, jak działa "write()", to nie jest twoja firma.

W odniesieniu do curry, technika jest inna, po prostu upraszczamy params w funkcji. Podczas korzystania ze Slim Framework faceci mówią "możesz curry swoje trasy za pomocą $ app". Użyłem Slim dużo, a moje zrozumienie w ten sposób jest, ok, sprytniejsze niż przekazanie kilku zmiennych do zamkniętej trasy tylko wzbogacić zmienną $ app i przekazać 1 pojedynczy var: $ app

$app = new \Slim\Slim(); 
//Rather than 
//$app->get('/foo', function() use ($app, $log, $store, ...) { 

$app->get('/foo', function() use ($app) { 
    $app->render('foo.php'); // <-- SUCCESS 
    $app->log->write(); 
    $app->db->store(); 
});