# Plugin Components

While the main plugin instance class of your project should implement the `PluginInterface` interface, the other classes should implement the [`PluginComponentInterface`](https://github.com/deep-web-solutions/wordpress-framework-foundations/blob/master/src/includes/PluginComponent/PluginComponentInterface.php) interface. Obvious exceptions are classes designed to be [utilities](https://framework.deep-web-solutions.com/foundations-module/utilities) -- and anything else that you think shouldn't (we don't know your project!). 

Plugin components are simple though. They simple posses an ID, a name, and a means to get the main plugin instance. For example, our [Locked Payment Methods plugin](https://www.deep-web-solutions.com/plugins/locked-payment-methods-for-woocommerce/) has a class for each unlock strategy and each of those classes is a plugin component. The name of the user profile unlock strategy is simply *User Meta Unlock Strategy* and its ID is an autogenerated hash.

{% hint style="info" %}
The ID of a plugin component can be anything that identifies it uniquely, whereas the name is designed to be spelled out in plain English for human understanding.
{% endhint %}

{% hint style="warning" %}
As a rule of thumb, plugin components are singletons. This is not enforced, but be sure to know what you're doing if you instantiate the same component multiple times.
{% endhint %}

As you probably expected by now, there is a [`PluginComponentTrait`](https://github.com/deep-web-solutions/wordpress-framework-foundations/blob/master/src/includes/PluginComponent/PluginComponentTrait.php) trait offered that provides a basic implementation of the interface methods. Moreover, the [`AbstractPluginComponent`](https://github.com/deep-web-solutions/wordpress-framework-foundations/blob/master/src/includes/PluginComponent/AbstractPluginComponent.php) class also provides sensible defaults and magic use of your getters and setters.