sybrew/the-seo-framework

Group classes by feature instead of programming function

Closed this issue · 0 comments

sybrew commented

Currently, we map the classes by programming function:

  • Bridges: These classes form a bridge between TSF's facade object and other objects (or data).
  • Builders: These classes create data.
  • Internal: These classes are meant for development only.
  • Interpreters: These classes read or output data from various languages.

These names stem from fundamental object patterns, but since ours don't always adhere to those (due to code debt), this is becoming confusing and is making the path to 4.3.0 difficult.

I propose to group the classes by feature:

  • Sitemap...
  • Metadata\
    • Title
    • Description
  • Admin\
    • SEOBar
    • Editor
      • Post
      • Term
    • Settings
  • Query
  • Data\
    • Network(?)
    • Site
    • Post
    • Term
    • User
    • Cache
    • Security/Validation
      • Sanitize
      • Escape
      • Filter
  • etc.

By extracting all the methods from the facade object, we can finally start exploiting true OOP instead of just using classes for grouping functional programming.

We can easily deprecate all old classes and repurpose them via Class Alias. See, for an example, this file:

\tsf()->_deprecated_function( 'The_SEO_Framework\Builders\Sitemap', '4.2.0', 'The_SEO_Framework\Builders\Sitemap\Main' );
/**
* Generates the sitemap.
*
* @since 4.0.0
* @since 4.2.0 1. Moved to \The_SEO_Framework\Builders\Sitemap\Main
* 2. Deprecated.
* @abstract
* @deprecated
* @ignore
*
* @access protected
* Use \The_SEO_Framework\Builders\Sitemap\Main instead.
*/
class_alias( 'The_SEO_Framework\Builders\Sitemap\Main', 'The_SEO_Framework\Builders\Sitemap', true );