Most complex plugins do that in one form or another. Unfortunately, many plugins start with a god class and don’t use a clean OOP approach. WooCommerce is a popular example.

Plugins cannot provide a real front controller, because they are loaded after WordPress has set up most of its environment. And all plugins are almost equal: If two plugins try to handle the same request, the first one wins probably. You never know which plugins might compete with yours.

For a very basic example see my plugin [T5 Public Preview][1] (from [this answer][2]).

- The front controller is the class [T5_Public_Preview][3] it loads the needed classes and creates the objects depending on the request (admin or front-end).
- There are three models: `T5_Post_Meta`, `T5_Public_Preview_Language` and `T5_Endpoint`.
- And two views handle the output: `T5_Publish_Box_View` and `T5_Render_Endpoint`. The latter doesn’t actually show something, but it changes WordPress to show a different output in some cases.

------

OOP is about [communication between objects and components][4]. So the real problem is not the pattern, it is the **communication**. WordPress core is not OOP, everything is lumped together; the code was and is growing organically. Without a clear inner structure, WP solved the communication problem with **actions and filters (hooks)**: predefined events, allowing any plugin to change or replace output and application logic.

Your plugin has to operate within this given structure. There are some interesting communication problems to solve:

- Make it possible to change or to deactivate your plugin temporary. Avoid [anonymous objects][5] or [offer a configuration object][6].
- But don’t provide [too many custom hooks too early][7].
- Try to control the [order of execution][8] when multiple plugins act on the same hooks.
- Make sure callbacks that depend on a specific order are [chained][9].

These are the most important responsibilities for a plugin front controller. You can delegate some to subsequent controllers, but the front controller has to know how they work. In my opinion, a front controller in a WP plugin has to know too much too often. But I’m still learning. :)

Oh, and [separate the main plugin file from the class declarations][10].


  [1]: https://github.com/toscho/T5-Public-Preview
  [2]: http://wordpress.stackexchange.com/a/116659/73 "How do I make a draft post accessible to everyone?"
  [3]: https://github.com/toscho/T5-Public-Preview/blob/master/php/T5_Public_Preview.php
  [4]: http://blog.ircmaxell.com/2013/09/beyond-design-patterns.html "Beyond Design Patterns"
  [5]: http://wordpress.stackexchange.com/a/57088/73
  [6]: http://wpkrauts.com/2013/initialize-a-plugin-with-a-configuration-object/
  [7]: http://wordpress.stackexchange.com/a/98783/73
  [8]: http://wordpress.stackexchange.com/a/116303/73
  [9]: http://wordpress.stackexchange.com/a/80271/73
  [10]: http://wptip.me/files-with-a-single-consequence