VE280 - LAB 6 - Solved

Topic: Class Inheritance 
Only one exercise. It will take most of your time exploring and understanding what needs to be done. The code you need to write is quite simple. 
In addition of working on class inheritance, you will also practice code reading and learn about the plugin architecture. 
Click here to  jump to what  you should do 
1 Plugin based software development  
Most of you use Visual Studio Code or CLion for this course. Both IDEs have a lot of powerful or interesting plugins or gadgets, like Rainbow Bracket on CLion, or Bracket Pair Colorizer on Visual Studio Code. Another example is Google Chrome, with some useful extensions like SwitchyOmega or Tampermonkey. They are all examples of a plugin. 
From a simplified informal point of view a plugin can be seen as a small piece of software that can be loaded to extend or bring in new features to a host application. For this to work, the host software must expose a plugin API. Then plugins can be developed independently from each others or the main application, i.e., the core software does not need them to compile and run properly. Plugins can hence be implemented following the plugin API, be compiled as shared libraries, and loaded at startup or even at run-time by the host software. 
API, Application Programming Interface, of an application defines how other applications can access data from this application. 
For instance when developing a music player one might want to introduce plugins to play various file types such as mp3, wav, and flac. In such a case one will want to have a generic play_file() function which would redirect the job to an appropriate function, for example play_mp3(), or play_wav()depending on the fle type. Of course if a fle type is not supported, e.g., play_fac() does not exist, the program should not crash but simply report that this file type is not supported. In particular this shows the necessity for each plugin to register itself and present some meta-information about itself to the main program. 
In a slightly more formal way the plugin architecture is split into four sub-concepts: 




Discovering: mechanism allowing the host application to discover available plugins. Usually plugins are found in a specific folders. In this lab, the folder is ./plugins  . This concept is implemented in P l u g i n M a n a g e r : : d i s c o v e r P l u g i n  . Registering: mechanism allowing the host application to potentially accept and register the discovered plugins; At this stage a plugin announces ts features, version, and any other information necessary to the well functioning of the application. In this lab, it is PluginManager: : registerPlugin. Hooking: sometimes called mount points or extension points, application hooks can be seen as the core of the plugin manager; They allow the plugin to “attach”itself to the application; Hence the core application can get control over the plugin. In this lab, all the plugins are stored in a vector P l u g i n M a n a g e r : : p l u g i nLi s t so that the host application can access and control them. Exposing: the core application should also expose an API to plugins such that they can call some of its functions; Evidently, not all functions from the core application should bebe