What is the best time to add plugins?
If you predict that certain features are interesting to your system, but that they would be better off your "core", then it helps you to design it from the beginning to wait for plugins.
An example would be a program that handles a variety of file formats, but does not want to be "tied" to natively supported formats. In that case, it is best to abstract the handling of these files, and write a plugin for each format you want. Making it easier, of course, to develop and deploy new plugins, including third-party plugins.
What is the purpose of a plugin?
A plugin is a plug-in for your system, a way to extend its basic functionality. Thus, a plugin only does what the system "lets" it do, it can not solve any possible and imaginary problem in this way (unless the plugin uses monkey patch or even modify the sources of the original system and recompile them - in which case it is more called "mod" than that of "plugin" ). >
Some people try to design entire systems as a small generic foundation and a large set of plugins. This type of architecture is complicated because you need to carefully manage dependencies between plugins, but the end result is a system with more flexibility. At first you could substitute any plugin for another to change the functionality of the system, but in practice the dependency chain makes it difficult to modify the "base" of the system, so even this model has limitations.
Apparently many projects see plugins as the basic functionality of their systems, when in my understanding, plugins should be just "extras".
Not necessarily, see the first example of the file formats, this can be a "basic" functionality (ie you need at least 1 file type supported by the system to do anything useful) but still be better modeled of plugins. The key point is to identify which areas of the system require high customization, and prepare to meet them accordingly.
In case I resolve to add plugins to an application, is there any ready-made methodology for me to base and avoid making design mistakes?
There is no one-size-fits-all solution, but I'd recommend taking a look at the Dependency Inversion Principle , and their related standards (in particular the Dependency Injection and < a href="http://en.wikipedia.org/wiki/Inversion_of_control"> Inversion of Control , among others). The key point is to enable your system to receive extensions without having to recompile it, or better yet without having to stop the same when adding / removing a plugin (more difficult but very useful during development and also convenient for the end user).
Finally, if you already have a system ready and realize the need to customize it (either with plugins or in some other way), it can often be necessary to refactor it, so the interface between the components (eg how your system communicates with library A) and then perform this abstraction through two concrete implementations (one communicating with A, another communicates with B). In that case, dependency inversion can help, but you do not have to go all the way to make your system "pluggable" to reap the benefits of this abstraction (you can keep everything internal even with just one line in the settings indicating which strategy follow).
