@nash-ye This plugin's options API is maybe called 100 times. There would be negligible difference in performance in this case. (If `apply_filters` or `do_action` became static methods, then we may see a performance hit.) Besides, static methods are used on many highly reputable projects, such as WP-CLI. If we're going to sacrifice code organization for the sake of performance, then we might as well rewrite everything in assembly language :wink: 

And actually, instead of static classes, I'd actually like to move toward using regular instantiated classes. So then there could be a `Depenency_Minification_Options` class which is instantiated inside the main `Dependency_Minification` plugin class, passing along the plugin's main instance for context. For example:

```php
class Dependency_Minification {
    function __constructor() {
        // ...
        $this->options = new Dependency_Minification_Options( $this );
        // ...
    }

    function do_something() {
        // get an option
        $this->options->get( 'foo' );
        // ...
    }
}
```

We took this approach with Settings Revisions: https://github.com/x-team/wp-settings-revisions/blob/master/php/plugin.php#L25-L29

So I'm saying that for this plugin, it's gotta be OOP.