Responsibilities of index.php and what to do about it

[logmanoriginal]

index.php has grown quite complex with the addition of new features and continuous effort of the community for improvement. From my point of view it has reached a point where it makes sense to re-factor it into smaller pieces. A task I'm currently working on.

This issue is about making the process transparent for everyone and to get some feedback before investing too much of my precious spare time. It also serves as a TODO list for all the things that should be done.

But going into that, find below my summary for the current responsibilities of index.php (basically a human friendly interpretation of the file):

Show responsibilities of `index.php`

• Set default time zone to UTC
• Append CLI arguments to the $_GET array
• Define the user agent
• Specify the default whitelist
• Handle actions
  • Handle the list action
    • Calculate output data
    • Collect output data
    • Set the Content-Type header
    • Send output data to the user
  • Handle the detect action
    • Find target bridge
    • Run the operation
    • Build output data
    • Set the Location header
    • Send output data to the user
  • Handle the display action
    • Cleanup format input
    • Check if the bridge is whitelisted
    • Set the proxy flags
    • Handle custom cache timeout
    • Redirect if custom cache timeout is disabled
    • Filter cache timeout value
    • Filter bridge parameters
    • Filter cache parameters
    • Initialize cache
    • Handle cache timeout
      • If it's not a timeout load cached data
        • Check Http-If-Modified-Since header
        • Interpret header data
        • Send Last-Modified header
        • Load cached data
      • If it's a timeout load new data
        • Handle errors and exceptions
          • If its' an error
            • Generate a feed item to return as error item
            • Collect additional data
            • Add additional data to the error item
            • Add the item to the items list
          • If its' an exception
            • Generate a feed item to return as error item
            • Collect additional data
            • Add additional data to the error item
            • Add the item to the items list
        • Initialize the bridge
        • Handle legacy items
        • Collect bridge information
        • Build cache storage data
      • Transform data
        • Handle errors and exceptions
          • If it's an error
            • Write error message to error_log
            • Send Content-Type header
            • Kill the process, sending error data to the user
          • If it's an exception
            • Write error message to error_log
            • Send Content-Type header
            • Kill the process, sending error data to the user
  • Echo the bridge list to the user
• Handle exceptions
  • Write error message to error_log
  • Send Content-Type header
  • Kill the process, sending error data to the user

Based on the list of responsibilities I came up with a list of tasks that take the SOLID approach a little more serious.

The SOLID approach

S = Single responsibility principle
O = Open/closed principle
L = Liskov substitution principle
I = Interface segregation principle
D = Dependency inversion principle

=> Google it
=> Don't take it too seriously 😉

Single responsibility principle

• Setting the time zone is responsibility of the Configuration class. References Time stamp #956
• Loading CLI and GET arguments should be handled by a UserInput class.
• Setting the user agent is responsibility of the Configuration class.
• The default whitelist is responsibility of the Configuration class.
• index.php should work as a controller, as in MVC.
• Actions should be handled by specialized *Action classes.
• *Action classes should be initialized by a ActionFactory class.
• Exceptions should be handled inside the implementing codes.
• User input data should be cleaned up by the UserInput class.
• Factory classes are responsible for taking any supported name.
• Proxy flags are responsibility of the Configuration class.
• Custom cache timeout is responsibility of the Cache class.
• Cache initialization is responsibility of the CacheAbstract class.
• The cache type is responsibility of the Configuration class.

Open/closed principle

// Mostly covered by previous points

• Link actions in a factory class instead of using a case structure
• Implement a base class for factory classes
• Add separate classes for each action
  • Display
  • List
  • Detect

Liskov substitution principle

• Each element that can be changed by the user should implement an interface.
  • Bridges
  • Caches
  • Formats
  • Actions
• Refactor existing factories

Interface segregation principle

// Mostly covered by previous points

Dependency inversion principle

// Mostly covered by previous points

Testing

• It must be possible to test the (each) API in isolation.
  • Bridges
  • Caches
  • Formats
  • Actions

---

Let me know if you have further suggestions or want to work on any of the points listed above.

[logmanoriginal]

All done.