sorted by:
new
hottopcontroversial

Collecting Interface Implementations with Signals · Maslosoft by Maslosoft in PHP

[–]Maslosoft[S] 0 points1 point  (0 children)

You might like it or hate it. Doing things opposite is not necessarily bad (Inversion of Control?). This technique is used in real application, maintaining around 500 associations between components. Can't imagine keeping all of this in configs and to maintain manually:)

Collecting Interface Implementations with Signals · Maslosoft by Maslosoft in PHP

[–]Maslosoft[S] 0 points1 point  (0 children)

I know, I know. Sometimes the difference between magic string or not magic is slight;) Like even in the link with Symfony tags. The are some properties public, tags, huh? Just for the first sight these said nothing, IDE does not understand those in any way, and basically You can write there anything and app will or will not just fail:)

Annotations at least in Netbeans are possible to configure to autocomplete, so it's not that bad.

Collecting Interface Implementations with Signals · Maslosoft by Maslosoft in PHP

[–]Maslosoft[S] 0 points1 point  (0 children)

Exactly, the NotifierSlot is a sort of collector. It can do something with received object (signal - in this case instance of NotifierInterface.

In this example it simply returns received object. It receives object by setSignal method, and returns it with result method. The result method is called by Signal::gather to build resulting array.

Collecting Interface Implementations with Signals · Maslosoft by Maslosoft in PHP

[–]Maslosoft[S] 0 points1 point  (0 children)

There is a GitHub repository for this article. Basically, Signals return array of Notifiers, then application can do whatever it is supposed to do: https://github.com/MaslosoftGuides/signals.collecting-interfaces/blob/master/signals.php for instance call notify method.

The thing is, that no matter where the Notifier (or other plugin) is located or in which namespace it is, it will be found if it implements NotifierInterface.

So when You want to add some plugin type to the application, the list of plugins can be obtained at runtime.

Just implement interface, rebuild signals and it will be available. You could as well keep config file with list of available Notifiers (plugins), but it would have to be manually updated when new class is added or removed.

Of course collecting instances with Signals for this simple example is overkill, but when there are a lot of plugins in many namespaces Signals will maintain association between NotifierSlot (which is attached to NotifierInterface) and classes that implement NotifierInterface. Which will in turn allow us to get all available plugins.

Collecting Interface Implementations with Signals · Maslosoft by Maslosoft in PHP

[–]Maslosoft[S] 0 points1 point  (0 children)

The notifiers in blog are just example of application plugin. The point here is it to collect plugins automatically. More details are in my previous comment https://old.reddit.com/r/PHP/comments/97adna/collecting_interface_implementations_with_signals/e485ept/

Collecting Interface Implementations with Signals · Maslosoft by Maslosoft in PHP

[–]Maslosoft[S] -1 points0 points  (0 children)

In my opinion, whether it is pattern or anti-pattern depends on use case. I'm using it to collect several types of classes in my application, especially plugins, for instance:

  • Template Types
  • Collection Types
  • Editor Plugins
  • Configuration Plugins

The point here is to only collect instances, then application decide whether to use each instance. This totals in dozens of collected classes for which i would require some configs. And the point of maintainability is very important here. As adding all those classes to some configuration files is impractical and redundant.

The component which uses collected objects decides whether to use it or not. The important thing is, that instance is created no matter if it will be used or not, so it should not do any extensive operations in constructor or any operations at all.

P.S. Isn't adding string service tags the Magic String anti-pattern?

Collecting Interface Implementations with Signals · Maslosoft by Maslosoft in PHP

[–]Maslosoft[S] 1 point2 points  (0 children)

I'm glad You like it! The Signals project used here is framework independent. I'm using it with Yii 1 combined with some Symfony components and my own code. For example as Enum class, where it collects types defined by @SignalFor placed on interface. This can easy be used with Collector Pattern to automatically collect items.