What is correct way to select interface implementation according to passed parameter?
Let's have following code:
interface PaymentProcessor {
public function process(Order $order): void;
}
class CardPayment implements PaymentProcessor {}
class BankTransfer implements PaymentProcessor {}
class OrderService {
public function __construct( // Load payment processors from DI
private CardPayment $cardPayment,
private BankTransfer $bankTransfer,
) {}
// This is what is not clear to me
private function getPaymentProcessor(string $paymentMethod): PaymentProcessor
{
return match ($paymentMethod) {
'card' => $this->cardPayment,
'bank' => $this->bankTransfer,
}
}
public function payOrder(Order $order): void
{
$processor = $this->getPaymentProcessor($order->getPaymentMethod());
$processor->process($order);
}
}
What is not clear to me is how can I get PaymentProcessor by payment method name.
I would use code above, probably extracted to some "Factory". But according to answer at PHP - Using Interfaces, Strategy Pattern and Optional Method Parameters I am probably breaking open/close principle. Then what should be correct way?
The correct way to do this could be combination of Strategy pattern and Dependency Injection.
Solution posted in reffered answer is correct, but is missing one important point - the trick is that all the mapping can be done via Dependency Injection.
So you can have
interface PaymentStrategy {
public function process(): void;
}
class CardPayment implements PaymentStrategy {
public function process(): void;
}
class BankTransfer implements PaymentStrategy {
public function process(): void;
}
class PaymentService {
private PaymentStrategy $strategy;
/** #var array<string, PaymentStrategy> $processors */
public function __construct(private array $processors) {
}
public function setStrategy(string $paymentMethod): void {
if (!array_key_exists($paymentMethod, $this->processors)) {
throw new \InvalidArgumentException('Processor not found');
}
$this->strategy = $this->processors[$paymentMethod];
}
public function process(): void {
$this->strategy->process();
}
}
So all you need to do is convince your DI container to give you all of PaymentStrategy implementations. Ideally in paymentMethodName - strategy format. Alternatively you can add some function to interface and class which return it's payment method name - and then run foreach - if - return.
Related
I'm wondering if this is the correct way to extend and use classes with Symfonies autowiring.
For example, I have a BaseClass that instantiates and auto wires the entity manager.
class BaseClass
{
protected $entityManager;
public function __construct(EntityManagerInterface $entityManager)
{
$this->entityManager = $entityManager;
}
protected function someMethodIWantToUse(Entity $something)
{
// Do something there
$this->entityManager->persist($something);
$this->entityManager->flush();
}
}
Then I have a subclass that extends the BaseClass and needs access that method. So I let it autowire again and pass it to the parent constructor.
class SubClass extends BaseClass
{
private $handler;
public function __construct(EntityManagerInterface $em, SomeHandler $handler)
{
parent::__construct($em);
$this->handler = $handler;
}
public function SubClassMethod()
{
// Get some data or do something
$entity = SomeEntityIGot();
$this->someMethodIWantToUse($entity);
}
}
Now I'm wondering if this is actually the correct way to do this or there's something I'm missing and the parent class should be able to autowire the entitymanager by itself?
To summarize the comments, yes your way is correct. Depending on your use case there are alternatives.
This are the ways you can go about it:
1. Extending Class and using Constructor Injection (what you do)
class BaseClass {
protected $some;
public function __construct(SomeInterface $some)
{
$this->some = $some;
}
}
class SubClass extends BaseClass {
private $other;
public function __construct(SomeInterface $some, OtherInterface $other)
{
parent::__construct($some);
$this->other = $other;
}
}
2. Setter Injection
class BaseClass {
protected $some;
public function __construct(SomeInterface $some)
{
$this->some = $some;
}
}
class SubClass extends BaseClass {
private $other;
public function setOther(OtherInterface $other)
{
$this->other = $other;
}
}
Now setOther won't automatically be called, you have to "manually" call it by either specifying a calls property in your services.yaml file, as described here: https://symfony.com/doc/current/service_container/calls.html. This would then look something like this:
// services.yaml
App\SubClass:
calls:
- [setOther, ['#other']]
Or
// services.yaml
app.sub_class:
class: App\SubClass
calls:
- [setOther, ['#other']]
assuming, an implementation of OtherInterface is available as #other in the service container.
A more elegant solution if you're using autowiring, simply add a #required annotation to the function as described here: https://symfony.com/doc/current/service_container/autowiring.html#autowiring-calls, which would look like this:
/**
* #required
*/
public function setOther(OtherInterface $other)
{
$this->other = $other;
}
3. Property Injection
class BaseClass {
protected $some;
public function __construct(SomeInterface $some)
{
$this->some = $some;
}
}
class SubClass extends BaseClass {
public $other;
}
As with the Setter Injection, you'll need to tell Symfony to populate this property, by specifying it in your services.yaml file like this:
// services.yaml
App\SubClass:
properties:
other: '#other'
Or
// services.yaml
app.sub_class:
class: App\SubClass
properties:
other: '#other'
assuming, an implementation of OtherInterface is available as #other in the service container.
Conclusion:
Since there are different ways to solve this, it's up to you to determine the correct way for your use case. I personally go with either option 1 (Constructor Injection) or option 2 (Setter Injection) using the annotation. Both of them allow you to use typehints and thus allowing your IDE to help you write clean code.
In 90% of cases, I'd go with option 1, as then it's clear for every one reading your code, what services are available with one glance at the __constructor function.
One use case for Setter Injection would be a base class offering all the setXXX functions but then sub classes not needing all of them. You could have a constructor in each sub class, requesting the needed services and then calling the setXXX methods of the base class.
Note: this is kind of an edge case and you probably won't run into this.
You can find a list of advantages and disadvantages of each method directly in the Symfony documentation about the Service Container -> Types of Injection
This way too :
class BaseClass
{
protected Environment $twig;
#[Required]
public function setTwig(Environment $twig): void
{ $this->twig = $twig; }
}
class ChildClass extends BaseClass
{
public function __construct(
private EntityManagerInterface $entityManager
) { }
public function test()
{
$this->twig->render(......);
}
}
Unfortunately I'm stuck here.
Consider the following rudimentary examples:
interface ChargeInterface
{
public function charge($amount);
}
class BraintreeCharge implements ChargeInterface
{
public function charge($amount)
{
// braintree logic here
}
}
class StripeCharge implements ChargeInterface
{
public function charge($amount)
{
// stripe logic here
}
}
So there's an interface for charging a payment method, and there are, in this example, two concrete classes which implement the interface.
I'd like to be able to decide on runtime which implementation should be used. So I thought I'd achieve this with custom factory classes:
class PaymentFactory
{
public static $implementation;
public static function charge()
{
return $implementation::charge();
}
}
class StripeFactory
{
public static function charge()
{
return new StripeCharge();
}
}
class BraintreeFactory
{
public static function charge()
{
return new BraintreeCharge();
}
}
Than I could just use the factories:
PaymentFactory::$implemention = StripeFactory::class;
$payments = PaymentFactory::charge();
$payments->charge(100);
Another idea was to use a singleton based logic:
class PaymentFactory extends Singleton
{
protected $implementation;
// Singleton logic missing in this example
public function useImplementation($class)
{
$this->implementation = $class;
}
public function getImplementation()
{
return $this->implementation;
}
public static function charge()
{
$instance = self::getInstance();
return new $instance->getImplementation();
}
}
Later ...
PaymentFactory::getInstance()->useImplementation(StripeCharge::class);
$payments = PaymentFactory::charge();
$payments->charge(100);
Do you've any suggestions regarding best practices here?
I think I'd favour the first one, since the real implementation consists of more than just one class per package, as outlined in the example.
Also it seems to me, this would be the more cleaner way.
I have these two interfaces:
interface Observer
{
public function notify(Observable $observable, ...$args);
}
interface Observable
{
public static function register(Observer $observer);
public function notifyObservers();
}
And here is what I am trying to implement:
abstract class EventHandler implements Observer
{
abstract public function notify(Event $event, ...$args);
}
abstract class Event implements Observable
{
private static $handlers = [];
public static function register(EventHandler $handler)
{
self::$handlers []= $handler;
}
public function notifyObservers()
{
//notify loop here...
}
}
Event is an Observable and EventHandler is an Observer, right?
So why php considers these implementation incompatible with their respective interfaces?
A simple test of what I meant by "compatible":
class CreateEvent extends Event {}
$createEventObj = new CreateEvent();
if ($createEventObj instanceof Observable) {
echo 'Compatible';
} else {
echo 'Incompatible';
}
This is because of type hinting. If your typehint is (Observable $observable) you should use exactly the same typehint in all implementation of this method in all sub-classes. Read more here http://php.net/manual/de/language.oop5.typehinting.php.
I'm having some confusion with the adapter pattern and am wondering if it is the right tool for what I'm trying to accomplish.
Basically, I'm trying to get a class written by another developer to conform to an interface that I've written while also retaining the other methods from that class.
So I've written the following interface for a container object:
interface MyContainerInterface
{
public function has($key);
public function get($key);
public function add($key, $value);
public function remove($key);
}
I've also written an adapter that implements that interface:
class OtherContainerAdapter implements MyContainerInterface
{
protected $container;
public function __construct(ContainerInteface $container) {
$this->container = $container;
}
public function has($key) {
$this->container->isRegistered($key);
}
...
}
And am using it in my class as follows:
class MyClass implements \ArrayAccess
{
protected $container;
public function __construct(MyContainerInterface $container) {
$this->setContainer($container);
}
public function offsetExists($key) {
$this->container->has($key);
}
...
}
Then my application uses the class as so:
$myClass = new MyClass(new OtherContainerAdapter(new OtherContainer));
The issue I'm having is that in order to use the methods from the adapter I have to write the following:
$myClass->getContainer()->getContainer()->has('some_key');
When ideally it would just be:
$myClass->getContainer()->has('some_key');
$myClass->getContainer()
should return an instance of MyContainerInterface and that has a has() function. It shouldn't have a getContainer() function.
I don't think you need the Adapter Pattern for this. It looks to me like you're after a polymorphic solution, which can be accomplished by simply using an abstract class. No adapter needed.
The interface
interface MyContainerInterface
{
public function has($key);
public function get($key);
public function add($key, $value);
public function remove($key);
}
Then the abstract base class:
class MyContainerBaseClass implements MyContainerInterface, \ArrayAccess
{
public function offsetExists($key) {
$this->has($key);
}
...
}
Then, the sub-class from the other developer:
class ClassByOtherDeveloper extends MyContainerBaseClass
{
public function has($key) {
$this->isRegistered($key);
}
//you also need to implement get(), add(), and remove() since they are still abstract.
...
}
You can use it in your application like this:
$object = new ClassByOtherDeveloper();
$x = $object->has('some_key');
I'm assuming the isRegistered method lives in the implementation from the other developer.
To make it truly polymorphic you wouldn't hard-code the class name, but you'd use a variable that could come from a config file, database, or a Factory.
For example:
$className = "ClassByOtherDeveloper"; //this could be read from a database or some other dynamic source
$object = new $className();
$x = $object->has('some_key');
I have some abstract class MyClass with foo method. It is important to call this method from child class when someone iherits from this class and override this methods. So I want to show warning when this situation will happen. But I can't modify child class, because it isn't designed by me. In addition foo method can be overriden but not have to.
In code, calling FirstClass::foo() should cause warning, but SecondClass::foo() not. How can I do this?
abstract class MyClass {
public function foo() {
// do something important
}
}
class FirstClass extends MyClass {
public function foo() {
// do something special
}
}
class SecondClass extends MyClass {
public function foo() {
parent::foo ();
// do something special
}
}
You cannot do this right. You could add to your abstract class some flag and check it, but it would be wrong.
I propose you to use Template method pattern instead.
abstract class MyClass {
final public function foo() {
// do something important
$this->_overridableMethod();
}
abstract protected function _overridableMethod();
}
class FirstClass extends MyClass {
protected function _overridableMethod(){
// do something special
}
}
Here is skeleton example of how I would do this:
interface VehicleInterface
{
public function move($x, $y);
public function refuel($station);
}
interface FlyableInterface
{
public function takeoff();
public function land();
}
abstract class AbstractVehicle implements VehicleInterface
{
/**
* Implementation to refuel at station
*/
public function refuel($station)
{
}
}
class Car extends AbstractVehicle
{
/**
* Implementation to move by following a road.
*/
public function move($x, $y)
{
}
}
class Plane extends AbstractVehicle implements FlyableInterface
{
/**
* Implementation to move by means of flying.
*/
public function move($x, $y)
{
}
/**
* Override of AbstractVehicle::refuel, landing required first.
*/
public function refuel($station)
{
$this->land();
parent::refuel($station);
}
/**
* Implementation for plane to take off.
*/
public function takeoff()
{
}
/**
* Implementation to land the plane.
*/
public function land()
{
}
}
$vehicles = array(new Car(), new Plane());
$x = '145';
$y = '751';
foreach($vehicles as $vehicle) {
if($vehicle instanceof FlyableInterface) {
$vehicle->takeoff();
$vehicle->move($x, $y);
$vehicle->land();
} else {
$vehicle->move($x, $y);
}
}
The executing script at the end intends to perform the same task for each vehicle differently depending on the methods each class implements. Both the plane and the car implement the same move method, and they both inherit the the same refuel method, however the plane is required to land first.
The executing script will detect what methods are supported by checking if it is an instance of a particular interface.
For an example in practice, Symfony2 class Command has a variant called ContainerAwareCommand. By extending this, the framework knows to inject the service container because the supported methods to do so are either inherited or implemented by the child class.